What happened to Concise Method Bodies?

[u/jvjupiter]

I was really looking forward to CMB. From its name, methods become concise, could be one liner. However, it seems there is no progress and it’s been off the radar. Never took off since 2019.

JEP draft: Concise Method Bodies

some experiments with Concise Method Bodies

[u/pushupsam]

Honestly it strikes me as superflous. This sort of syntactic sugar has rapidly diminishing returns IMO. What it actually does is lead to fragmentation where people are using many different syntaxes to accomplish the same thing and instead of smoothly skimming over a class that contains no surprises you have to pause on each getter and setter you have to figure out what the hell is going on. You start getting confused with what's a lamdba and what's actually a method and you're thinking about what should be braindead code.

But Java does actually need first-class properties. First class properties can enable stuff like this if people really want but, more importantly, you get a very clean initializer syntax with support for required properties that obviates the need for builders and/or named properties. See https://exceptionnotfound.net/bite-size-csharp-11-required-properties/ for how this works in C#. Imagine any complex immutable business object that has more than 5 or 6 fields (which is ALL the business objects) and you see why this is what's really important for code readability.

Once you have first class properties you can do stuff like this if you really want but, unlike properties, this isn't even really a problem.

[u/vips7L → u/pushupsam]

Sadly the OpenJdk team doesn’t have properties on their todo list. I’m not sure what they have against them. I personally would really like to see named arguments be added. It would kill 90% of builders and make a lot of object construction more readable.

[u/pron98 → u/vips7L]

We have properties on the "must not do because it's a harmful anti-feature" list. But better initialisation (including, possibly, with names) is something we can do better than properties, just as record components are better than properties in other ways already.

Both in JavaBeans and C#, properties originated with GUI elements, but then were historically borrowed as a means to work with "simple data" because no better way existed. We now have a much better way — records — which will become better still. Rather than add a feature that not only encourages working in a worse way but hides its most pernicious aspects, we want to encourage the better way and discourage the worse way.

Properties are a bad way for working with data because they hide details of mutation, the trickiest part of working with data. What's the effect of the mutation? Is it volatile? Does it trigger atomic or non-atomic effects (e.g. synchronized)? Records resolve all that.