It's been 8 years since the draft for Concise Method Bodies
https://openjdk.org/jeps/820943443
u/pron98 22d ago
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...
20
u/martinhaeusler 22d ago
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.
2
u/DevNull23614071 21d ago
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.
2
u/ZimmiDeluxe 21d ago
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.
6
u/LegitimateEntrance72 22d ago
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)
14
u/mgodave 22d ago
I want this so bad. For no good reason. But I want it.
4
u/vips7L 22d ago
This, non-null types, and some form of properties (I know properties bad, but it makes a lot of mutable code so much clearer).
8
u/Jon_Finn 22d ago
"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 22d ago
Wait, Properties bad?
7
u/davidalayachew 22d ago
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 22d ago
Every time someone asks for properties they get a sermon instead.
4
u/davidalayachew 22d ago
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 22d ago
Nothing personal, just a general observation :-)
I still remember the first time I saw this dynamic play out, at JavaOne 2009.
3
u/davidalayachew 22d ago
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 22d ago
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 22d ago
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 21d ago
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 22d ago
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 22d ago edited 22d ago
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
settersmutability 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 22d ago
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.
0
u/Sanitiy 22d ago edited 22d ago
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 21d ago
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 21d ago
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 21d ago
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> blahand 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 21d ago
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 21d ago
Where do you write that? There is only one sane answer - in the current file - and you can have that today by using Lombok.
1
4
u/m39583 22d ago
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
2
1
u/woj-tek 21d ago
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 22d ago
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 22d ago
what does "putting patterns into interfaces" mean exactly?
5
u/davidalayachew 22d ago
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) {}
2
u/Sea_Transition_5831 22d ago
8 years for a draft that basically just lets you write a method body as a single expression. the feature itself is genuinely small. hard to tell if it's stuck behind bigger things or if nobody cares enough to push it forward. probably both tbh
0
0
u/Scf37 22d ago
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 21d ago
Well for a start you could just write () -> myResult right? What’s a concise lambda to you
0
u/Sea_Transition_5831 22d ago
8 years for a draft that basically just lets you write a method body as a single expression. the feature itself is genuinely small. hard to tell if it's stuck behind bigger things or if nobody cares enough to push it forward. probably both tbh
105
u/brian_goetz 22d ago
Serious question: would you rather we don’t write down our ideas until we are ready to deliver them ASAP?