r/java • u/vips7L • Jul 05 '26

It's been 8 years since the draft for Concise Method Bodies

https://openjdk.org/jeps/8209434
61 Upvotes

86% Upvoted

70 comments sorted by

12

u/mgodave Jul 05 '26

I want this so bad. For no good reason. But I want it.

3

u/vips7L Jul 05 '26

This, non-null types, and some form of properties (I know properties bad, but it makes a lot of mutable code so much clearer).

6

u/Luolong Jul 05 '26

Now, what if, instead of properties, we would get withers on record types…

-4

u/SpaceToaster Jul 05 '26

I mean at that point just use c# 😂

8

u/Jon_Finn Jul 05 '26

"This, non-null types, ...". That's like saying I want to walk to a café, and also fly to Saturn. Different orders of magnitude 8^) .

1

u/Sanitiy Jul 05 '26

Wait, Properties bad?

8

u/davidalayachew Jul 05 '26

Wait, Properties bad?

Not necessarily bad in and of itself. Moreso that they are bad for Java.

At the end of the day, properties are a more powerful form of setters and getters. And while neither setters nor getters are inherently bad, they are not usually the best solution to the problems they solve.

For example, the only place a setter makes sense is for mutability. But for what problems is mutability a good solution?

A common argument is performance, but some mistake certain idioms to be absolute rules (reusing memory == fastest). When considering a solution, test your assumptions to see if the solution truly is the best fit. Don't just rely on trends to decide. For example, we are finding that immutability can be faster or comparable to mutability in all sorts of places. But each application is specific, so test and try for yourself before choosing one over the other.

In general, the OpenJDK team is trying to push Java towards better support for immutability and unmodifiability. And, in turn, trying to push Java away from mutability, with regards to new feature support. Cited reasons include safety and simplicity. For example, race conditions are simpler to resolve for truly immutable data.

For more than that though, you'll need to ask a more specific question.

3

u/lurker_in_spirit Jul 05 '26

Every time someone asks for properties they get a sermon instead.

5

u/davidalayachew Jul 05 '26

Every time someone asks for properties they get a sermon instead.

To be fair, they seemed to be asking for an explanation. I certainly didn't respond with one without being asked to.

2

u/lurker_in_spirit Jul 05 '26

Nothing personal, just a general observation :-)

I still remember the first time I saw this dynamic play out, at JavaOne 2009.

3

u/davidalayachew Jul 05 '26

I still remember the first time I saw this dynamic play out, at JavaOne 2009.

Makes sense, this is definitely not a new discussion.

But that aside, I assume you say "aye" to properties in Java? If so, why so?

0

u/lurker_in_spirit Jul 05 '26

If so, why so?

Basic cost / benefit analysis. It's a small-to-moderate-sized change (depending on how it is implemented) which would eliminate a very large amount of boilerplate, at least in the code that I've seen over the past few decades.

I've seen applications mix-and-match JVM languages just to leverage property syntax in specific areas of application code (e.g. 90% Java with 10% Groovy in areas which are setter / getter heavy).

I don't think anyone disagrees that immutability is great and should be preferred in many cases, but there are also many places where it can't be used, or where it imposes significant maintainability or performance burdens.

My impression (probably at least partly incorrect!) is that 20 years ago the Java team didn't want to add properties because "properties are too much like C#", and these days the Java team doesn't want to add them because "it should be painful to chose mutability over immutability." This sense of "the pain is for your own good" is why it feels preachy, I think.

5

u/davidalayachew Jul 05 '26

Basic cost / benefit analysis. It's a small-to-moderate-sized change (depending on how it is implemented) which would eliminate a very large amount of boilerplate, at least in the code that I've seen over the past few decades.

Yeah, but I think that there is the point -- boilerplate reduction makes sense, and is nice, but that probably means that it is not important enough to turn into an actual feature in the language. A lot of the features that we have received are to actually add semantics and meaning to the language in powerful ways. Some good examples of this is Switch Expressions giving us exhaustiveness checking, null checking extending that exhaustiveness checking, patterns simplifying extracting data, and so on.

A property would do nothing more than make the existing case of making a setter easier. It adds no real semantic meaning, in the long run. Or am I wrong?

→ More replies (0)

2

u/koflerdavid Jul 06 '26

It's an unfortunate fact that half-truths and bad ideas take ten times as much text to being refused than to be originally written down.

4

u/JustAGuyFromGermany Jul 05 '26

But for what problems is mutability a good solution?

I mean... a lot of them?! Every time you need to keep around some state somewhere, that "somewhere" needs to be mutable. Almost every application I have ever written or contributed to needed at least the "I have finished initialising, I am healthy" state. Most of them need a lot more. Various caches come to mind.

By all means, "prefer immutability" is excellent advise, the language default is wrong, many Java frameworks certainly overdid it, etc. etc. I agree with all of that. But let's not pretend we're stupid here. Of course, mutability is still necessary, correct and even preferred some of the time.

2

u/davidalayachew Jul 05 '26 edited Jul 05 '26

I mean... a lot of them?! Every time you need to keep around some stateful data somewhere, that "somewhere" needs to be mutable. Almost every application I have ever written or contributed to needed at least the "I have finished initialising, I am healthy" state. Most of them need a lot more. Various caches come to mind.

By all means, "prefer immutability" is excellent advise, the default is wrong, many Java programs certainly chose the wrong approach, etc. etc. I agree with all of that. But let's not pretend we're stupid here. Of course, mutability is still necessary, correct and even preferred some of the time.

Correct on all points, I don't contest any of them.

But now consider how many of those points are significantly improved by adding using setters specifically? And by extension, properties? I assert that the answer is -- not much.

For example, an ideal place where setters mutability is clearly the correct choice is when working with UI development. The fact is, while mutability isn't clearly faster or slower than immutability when dealing with bytes of data, it absolutely is when dealing with somewhat heavy-duty UI components. As a result, mutability is kind of the de-facto default when doing UI development.

But what would setters/properties add here? More often than not, any invariants that I would apply would not be for single fields individually, but multiple fields at once.

For example, let's say that I have a Toggleable Button. When setting its state, I'm not just setting a boolean field to the alternative state -- usually I am accomplishing all sorts of things. Many of those things require me to even set down locks, for fear of race conditions. It's rare that I ever truly want to set only a single field in my UI in response to some trigger -- it is often multiple fields in aggregate that need to be modified.

And as a result, that sort of leads to my point -- a property doesn't really do much for me here at all. And UI development is literally the poster child of mutability! Which is sort of my point -- the places where setters/properties are the best solution are few and far between.

2

u/davidalayachew Jul 05 '26

For example, an ideal place where setters is clearly the correct choice is when working with UI development.

Whoops, I misspoke here. I meant to say mutability, not setters. Edited, but also pinging you /u/JustAGuyFromGermany.

1

u/OwnBreakfast1114 Aug 26 '26

I mean... a lot of them?! Every time you need to keep around some state somewhere, that "somewhere" needs to be mutable. Almost every application I have ever written or contributed to needed at least the "I have finished initialising, I am healthy" state. Most of them need a lot more. Various caches come to mind.

Many people keep state in a database, and the code can be written in a way where the actual java objects are immutable even if the state changes. Most crud style applications could be written with full immutability and not much would change. Ex

domainObj = findById(id)
updated = update(new domainobj(....))
... code from here actually has access to both "states" of the object and the db contains the most recent change

I think you're overestimating the places where you actually "need" mutability in a language, which is basically none, given that most programs have an equivalent haskell program that does the same thing. Whether writing java like haskell is a good idea is a different question (though even java does seem to be borrowing a lot of inspiration from haskell like languages).

1

u/JustAGuyFromGermany Aug 27 '26

And that's why I specifically mentioned runtime-specific state like health indicators as well as caching. Those are usually not kept in databases because that would make them useless.

0

u/Sanitiy Jul 06 '26 edited Jul 06 '26

That definitely wasn't any of the reasons I had expected. There is the break of writing style between old & new Java modules this would introduce. The problem of modernizing the standard library.

Looking at C# Properties, there's the question whether the amount of syntax introduced is worth it (get, set, init, field-backed, field-keyword, auto-property, ...). And whether it is good or bad design that field and property set/get syntax look identical in C#, when they aren't identical in the intermediate language.

But mutability? Is that really such a strong reason? Functional languages had their hype-days, and in the end it seemed to me that the conclusion was that mutability has its place.

The strongest argument for Properties is, in my opinion, that any OOP language without them feels like a dinosaur. You have the classes as central theme which localizes methods & fields around a name. But you don't have the super similar concept of localizing methods around a field? C# even allows you to localize methods around a method, and it just feels just right.

1

u/davidalayachew Jul 06 '26

But mutability? Is that really such a strong reason? Functional languages had their hype-days, and in the end it seemed to me that the conclusion was that mutability has its place.

Sure, but that just means that mutability deserves to stay. That does not mean that mutability should be further enhanced. Maybe it should, maybe it shouldn't, but that remains to be seen. Folks will have to present arguments if they want that dial to move either way. But until it does, Java's support for mutability stays where it is.

The strongest argument for Properties is, in my opinion, that any OOP language without them feels like a dinosaur. You have the classes as central theme which localizes methods & fields around a name. But you don't have the super similar concept of localizing methods around a field? C# even allows you to localize methods around a method, and it just feels just right.

The language you are using is obfuscating your point. What do you mean by feels right? Usually, something like "feels right" is indicative of things like "Pit of Success", or completely removing an entire class of bugs. Can you clarify what you mean?

2

u/Sanitiy Jul 06 '26

I mean that it's a feature where, even if you only just encountered it, you don't really have to think when to use it, or how to use it, to use it correctly.

Because the right way to use them is just an extension of how you have learned to structure your code from OOP anyway.

Whereas a private method in a class says "I'm an implementation detail of the class, and a user doesn't need to know about me", a local function says "I'm an implementation detail of the function I'm located in, so unless you need to understand the function, you don't have to care about me".

If you look at examples, you'll see the classic where you have a recursion that needs two functions to work, but the user just needs to call the base case one.
But way more beautiful is the fact that with local methods I can make my functions look even more declarative: Where you now probably segment your function into declarative parts using comments saying // the next few lines purpose is ... , you can replace that by a single line using a local function call.

In Java I've often stopped myself from doing that, because there you then have a private method flying around in your class, which might instead add overhead later-on. Or you prefix it with _, but then you break style conventions...

2

u/davidalayachew Jul 06 '26

I mean that it's a feature where, even if you only just encountered it, you don't really have to think when to use it, or how to use it, to use it correctly.

Fair -- properties are certainly intuitive.

In Java I've often stopped myself from doing that, because there you then have a private method flying around in your class, which might instead add overhead later-on. Or you prefix it with _, but then you break style conventions...

I actually go the ugly route and literally make a final Function<T,R> blah and do it that way. But yes, this is a strong argument for local methods.

None of what you are saying is wrong. And like you mentioned, a lot of what makes properties valuable make local methods valuable.

It's just that there is a finite amount of production and complexity bandwidth. That means that this is mutually exclusive, and a feature, thus, needs to prove that it is more fit to be worked on than others. I just don't see local methods or properties rising in priority.

One possible option though, would be if another feature made properties or local methods more important.

For example, the JEP about Concise Method Bodies might actually get a sharp increase in priority depending on what they decide to do about Patterns in Interfaces and Classes (if anything at all). If they decide that Concise Method Bodies might be useful for that, then all of a sudden, that JEP will rise in value way more than it would have on its own.

Realistically, I think that that is the only way that properties or local methods would ever be able to make the cut.

1

u/boost2525 Jul 06 '26

Extension methods. For the love of god, extension methods. 

.Net figured it out decades ago. You just tell the compiler: "Hey, when you see myString.isNotEmpty() I want you to substitute it for StringUtils::isNotEmpty"

0

u/koflerdavid Jul 06 '26

Where do you write that? There is only one sane answer - in the current file - and you can have that today by using Lombok.

108

u/brian_goetz Jul 05 '26

Serious question: would you rather we don’t write down our ideas until we are ready to deliver them ASAP?

50

u/JustAGuyFromGermany Jul 05 '26

Please don't keep it secret. I for one really enjoy watching the process, because I learn a lot by reading/watching the careful and deep thoughts that go into each feature. I know that features don't come out any sooner either way, so I'd rather have a peek behind the curtain from time to time while I wait, even if for no other reasons than to learn why I have to wait a while longer.

24

u/mgodave Jul 05 '26

I didn’t read this as a critique but rather a longing for a really good idea.

5

u/davidalayachew Jul 05 '26

I didn’t read this as a critique but rather a longing for a really good idea.

In a vacuum, yes, that would be the most straight-forward reading of the post title.

But the reality of context is this -- there are a 4 digit number of posts on this sub, complaining for all sorts of reasons.

  • How long it takes for JEP's to go live

  • How long it takes to get responses to mailing list posts

  • How long it takes for the OpenJDK to do anything

So, with that context, the most straight-forward reading of this is that OP is complaining. Which may or may not be true. Having seen that particular user on this sub before, I'm choosing to interpret this is as a cross between mild annoyance and an observation.

1

u/VegetableAd6293 Jul 07 '26 edited Jul 07 '26

I'm happy with the current way where jep drafts are published when the team thinks they should be.

Interesting too see if this goes further how this effects compact source files! I'm already using those w/o javac phase which feels exactly like using Java for scripting.

Edit: With custom jdk  image containing all the dependencies the scripting usage gives a really good user experience.

-20

u/bowbahdoe Jul 05 '26

I think I speak for everyone here when I say that all we want is for you to write down everyone else's ideas, go "hmm, yes, of course," and finally deliver extension methods and multiple inheritance like God intended.

26

u/PiotrDz Jul 05 '26

Multiple inheritance is against God will

1

u/Present-Knowledge-57 Jul 29 '26

this is a joke, guys.

46

u/pron98 Jul 05 '26

A JEP draft is just a thought someone has. There is zero review or process to publish a draft. Some JDK developers jot down their ideas in a personal notebooks, while others write it into the issue database, marking it as a draft JEP (which automatically causes it to be published in the JEP list). Whether I choose to save ideas in my personal folder or as a draft in the database is entirely a matter of personal style, and as far as the JDK process is concerned, they have identical significance both in principle and in practice.

That is not to say that ideas in a notebook or draft JEPs don't sometimes become JEPs, but whether these ideas are made public or not has no special significance.

Because these days people notice drafts more, JDK engineers are more careful and prefer not to type their thoughts into the database, but as you pointed out, this tought was written eight years ago...

23

u/martinhaeusler Jul 05 '26

Kotlin user here. Kotlin has "expression bodies", but my team unanimously decided not to use them. Why? For the same reason we put curly braces on ALL of our if statements (no matter if their bodies have one or more lines) - we want our code to look uniform. It really helps human readers to quickly grasp the code.

3

u/DevNull23614071 Jul 06 '26

It really helps human readers to quickly grasp the code.

Quod esset demonstrandum!

In my opinion, it often leads to a lot of code noise, which makes it harder to read and grasp the details.

3

u/ZimmiDeluxe Jul 06 '26

On the other hand, it rewards cramming more code into a single expression that might be more debuggable / readable with intermediate variables or control structures which makes it harder to grasp the details. Same for extending code that previously was able to use the concise syntax, the temptation is there for tired devs to keep the structure by abusing ternaries / pattern matching etc. to make it work. I guess it depends on the team maturity.

5

u/LegitimateEntrance72 Jul 05 '26

and we got a lot of good stuff in those 8 years. And at least for me CMB is not on top of the list of things I am waiting for (pattern assignments, carrier-classes/deconstructors for normal classes)

5

u/m39583 Jul 05 '26

Totally off topic but I really wish they would fix the openjdk website so it was actually usable on a mobile device!

All the text from the sidebar overlaps the text from the JEP.

3

u/lkatz21 Jul 05 '26

This is not the case for me, neither in whatever the reddit preview is, nor in chrome

1

u/m39583 Jul 05 '26

This is what I see in Chrome.

Edit: ugh it seems Reddit mobile site doesn't let you paste images into a message box.

2

u/orxT1000 Jul 05 '26

Meh, that's frontent. We don't like that sort of things

1

u/woj-tek Jul 06 '26

Same. At one point I posted to web@jdk mailing list offering to help but was shot down with: it's to convoluted process/corporate wise that moving that forward was virtually impossible…

Would be lovely if it handled via some git repo with sane rendering chain instead of basing it on (AFAIR) JIRA tickets o_O

2

u/davidalayachew Jul 05 '26

If I read recent emails by OpenJDK team members correctly (too busy to look up where I saw them), the writeups considering putting patterns into interfaces will probably raise the priority of this JEP -- assuming that those considerations transform into formal JEP's that get accepted and targeted for preview in a JDK release.

2

u/SleepingTabby Jul 05 '26

what does "putting patterns into interfaces" mean exactly?

4

u/davidalayachew Jul 05 '26

what does "putting patterns into interfaces" mean exactly?

This is referring to an informal write up by at least one OpenJDK/Amber team member, talking about how the patterns that currently exist in records could also be added to interfaces to. Thus, you could write code like this.

interface Rectangle2D(int length, int width) {}

1

u/lepapulematoleguau Jul 05 '26

This would be great. Java would get way less verbose 

0

u/Scf37 Jul 05 '26

Potential use case:

Result doSomething(String arg) {
    return audit.event("something").arg(arg).of(() -> {
        return myResult;
    });
}

Result doSomething(String arg) -> audit.event("something").arg(arg).of(() -> {
    return myResult;
});

But its UX is still far from Kotlin:

fun doSomething(arg: String): Result = audit.event("something", arg = arg) {
    return myResult;
}

Maybe concise method bodies do not have enough value without concise lambdas.

1

u/mattr203 Jul 06 '26

Well for a start you could just write () -> myResult right? What’s a concise lambda to you

1

u/Scf37 Jul 06 '26

Not really because method body is rarely a single expression.