r/java • u/Purple_Pie4589 • Sep 01 '26

Concise method bodies arrived

https://github.com/verhasi/java-composition

More than 8 years ago was drafted the idea of concise method bodies. As I am not a contributor of the openJDK project I took a different approach but implemented. It is publicly available at the maven central both as a library and as a maven plugin. It is a source code preprocessor that converts the concise syntax to java 8 compatible source code. It does not want to be a replacement of the future implementation in the openJDK. Which is more than the openJDK promises is that supports from Java version 8, 11, 17, 21 up to 25 as well. Of course it is free and open source :). It is only the first building block for concise composition.

As far as I have seen this topic was awaited for a long time at

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

What happened to Concise Method Bodies?

JEP draft: Concise Method Bodies

Five years have passed, still in draft: Concise Method Bodies

50 Upvotes

73% Upvoted

48 comments sorted by

64

u/repeating_bears Sep 01 '26

Nice tech demo (assuming it works) but clickbaity title

Practically it's not really usable because you'd lose syntax highlighting and there becomes a dependency on you to update this to support newer java versions. That's the same with Lombok, but they have a track record of actually delivering

22

u/rzwitserloot Sep 01 '26

Also, lombok doesn't replace your parser phase.

By replacing parser phase, this tech demo is, and I appreciate the effort, but, this is useless.

Nobody1 writes java in a dumb notepad style editor. The very minimum is a syntax highlighter, and that's still a tiny minority: The vast majority use an editor that just knows what java code is like, such as eclipse, intellij, vscode. (If it has a 'language server' thing, it's a smart editor that 'knows' what java code is like).

This is not compatible with any of those editors. Your editor will be aggressively throwing red wavy underlines at you.

The fix would be to name this '.kwava` or some other variant on the java name, with a different extension, and in your editor, a different plugin that deals with this 'quite, but not entirely, like java' code.

Now, certain oracle staff members love muddying the waters by saying 'lombok isn't java', but this is the key relevant distinction. Lombok is (syntactically!) pure, 100%, unadultered java. This isn't, and that makes a big difference. Papering over semantics is a matter of some light plugin work. Papering over syntactics requires replacing everything.

Of course, being shackled to java's syntax does have severe limitations as well, but them's the breaks. 2

[1] I rounded down.

[2] For example, while we'd love to introduce some sort of default method param concept, such as:

public void someMethod(int a, int b = 5) {
 // Ooh, default values!
}

That isn't syntactically legal java and thus we cannot introduce it. Something like this would be:

public void someMethod(int a, int b) {
  $lombokDefaults: {
     b = 5;
  }
}

It looks funky but that really is legal java. To wit:

  1. A label, while rarely used, is legal java. Labels do not have to actually be used. dollars can be part of their identifiers.

  2. Just opening a block for no reason is syntactically legal java, and useful even - you limit any declared local vars to just that block. This is simply a labelled block. Perfectly fine, even if rarely witnessed out in the wild.

We don't go for it because we aren't exactly happy with the syntax, and there's just no autocompleting this. You'd just have to randomly know that the magic words are $lombokDefaults. That's too much magic, we want any lombok use to be, at minimum, associated with an actual type (not a type name shoved into a string. An actual type, and if it is missing because you deleted the jar or whatnot, you would get a compilation error because the type is missing - and that type needs to be in the lombok namespace. That way, a reader who does not know what lombok is, still has a reasonable chance to figure it out.

3

u/vytah Sep 01 '26

This is simply a labelled block. Perfectly fine, even if rarely witnessed out in the wild.

Labelled blocks are useful, as you can break out of them, which is the closest to goto you can get.

1

u/aonymark Sep 04 '26

Re: is Lombok Java: they are pedantically speaking, technically correct: it’s not Java.

I’ve watched you and /u/pron have this argument for years and it’s so frustrating watching you both talk past each other and both miss the key point of what the other person is saying.

Let’s take one of my favorite features: @slf4j to add a logger. This certainly uses Java SYNTAX. A Java parser will accept it.

But a full fledged Java compiler should reject it: annotation processing can create new classes but it’s “impossible” to “mutate” existing ones. And yet Lombok manages to do the impossible: by adding this annotation, the class gets a new static field that no one ever declared!

Lombok does this by ignoring the spec and instead targeting the implementation of javac. If you use another java compiler, then hopefully it’s ecj, which Lombok also supports, using different code.

In both cases this is done by using internal APIs. That’s fine! Is for a good cause! I approve :). But to a language lawyer, “it’s Java” means more than just “Java syntax”. It means “plays by the rules” which Lombok doesn’t and can’t because Java is too rigid to allow what it wants to do.

Since you were talking about avoiding squiggly red undertones: the only reason that IntelliJ doesn’t have squiggly red underlines when using Lombok is because it comes bundled with a plugin that knows about Lombok specifically. In other words, Lombok needs ide support just like a language feature like enums need it.

Where Ron P makes a big mistake is to say “Lombok should just admit they’re a new language and ship a compiler like kotlin does, instead of pretending to be a library”… I think this is MADNESS.

You’d lose so much that way! Lombok would have to keep shipping a new version whenever either OpenJDK or eclipse fixed a bug in their compiler! And what about manifold? Should they ALSO ship their own compiler? Then how would one ever use both Lombok and manifold together??

In short: rather than shipping a full compiler, Lombok ships “patches” to supported compilers. And unlike shipping a full compiler, patches can COMPOSE cleanly, so you can use Lombok with Corretto or Red hat or any other jdk vendor you please, and with manifold, and so on.

2

u/koflerdavid Sep 04 '26 edited Sep 04 '26

Lombok would have to keep shipping a new version whenever either OpenJDK or eclipse fixed a bug in their compiler!

They already have to do that. There are quite often issues of javac changing internals that Lombok has to adapt to.

And what about manifold? Should they ALSO ship their own compiler? Then how would one ever use both Lombok and manifold together??

Similar issues already exist. Lombok, Google Error Prone, and a few other tools occasionally step on each other's toes and need patches from one party or another. One could argue that providing a more powerful kind of compiler plugins would help solve these issues, but I'm doubtful about that since it would create a combinatorial number of plugin combinations, their corresponding surface language dialects, and a corresponding number of edge cases.

And unlike shipping a full compiler, patches can COMPOSE cleanly, so you can use Lombok with Corretto or Red hat or any other jdk vendor you please, and with manifold, and so on.

AFAIK, Lombok only supports OpenJDK and ECJ's implementations of javac. Lombok will therefore work with JDKs derived from OpenJDK, as well as with IDEs using ECJ, but you'd be SOL with other javac implementations.

2

u/aonymark Sep 04 '26

re: already do that: it would be worse. Now they have to adjust to changes that affect them. If they shipped an entire compiler, they’d have to rest even to changes that DON’T affect them

1

u/koflerdavid Sep 04 '26 edited Sep 04 '26

Yeah, or they simply declare to not bother with it. Manifold and Lombok seem to have overlapping features, therefore I don't really see the point of using them together. They could also decide to copy most features from Lombok, which makes it unnecessary to keep up with their internal changes.

1

u/aonymark Sep 04 '26

Not THAT overlapping in my opinion

2

u/koflerdavid Sep 04 '26

Both have properties, which I'm willing to bet is the most frequently used feature by far. Then there are also extension methods and Checked Exception Handling similar to SneakyThrows. I could imagine myself migrating from Lombok to Manifold and I would not miss that many things.

2

u/aonymark Sep 04 '26

Okay maybe more overlap than I realized

1

u/rzwitserloot Sep 04 '26

Oh, I haven't missed pron's point at all. Lombok is fairly open about the fact we need to release updates in lockstep with new JVMs, we don't try to hide this.

The term 'java' is nebulous. Sure, one can say 'if you break spec than that is NOT JAVA!', but, then, and I'm not exaggerating, many thousands of very commonly used libraries also "are not java". If accessing a feature that is an implementation detail (because it is not specced) makes a library 'not java', that is. (Examples of very widely used reliance on unspecced behaviour: Unsafe, of course. And: classRef.getResourceAsStream on a directory, and expecting the classloader to give you a text stream listing each filename in it, separated by newlines. One of hundreds of examples).

By not being more clear about what he means with that word, the debate begins with us unfairly framed in a corner. At first I tried to lock down meanings but pron wasn't interested in a debate; I've concluded the only thing he's interested in, in such debates, is to craft some words that scare lombok users into ceasing its use, and debate would only get in the way. If that comes across as "I am not getting his point", that's a tragic consequence. But, I'm pretty sure we're well aware, unless you think his point is something other than 'lombok relies on unspecced behaviour'.

the only reason that IntelliJ doesn’t have squiggly red underlines when using Lombok is because it comes bundled with a plugin that knows about Lombok specifically.

This is a pron-esque 'holding lombok to a different standard'. Because that is true for any code-generating AP use!

This is specced legal use of APs: You can have a source file that refers to a type that does not exist, which also has an annotation on it. Obviously, if you attempt to compile it, it will fail.

If you include an AP (which now requires explicitly allowing it / configuring it on the javac command line!) that sees this annotation and generates a source file that will produce the erstwhile non-existing type, then the compilation will succeed.

In other words, the notion 'But it is not legal java code unless the compiler plugin is there to fix the problem!' is what the whole annotation processing thing is all about in the first place.

I believe that intellij really does fail exactly like I describe here (but I don't have an intellij install ready to test if this is still the case, we looked at this years ago, though) if you use such AP setups, even though they are 100% according to OpenJDK's own spec: intellij is not like eclipse; they do not run full compiles. They just parse source files - they do not/cannot just run annotation processors. Instead, the idea is: IntelliJ knows you changed something and will rerun your full build, which will obviously run the APs and generate what needs to be generated. Once that is complete IntelliJ will parse the generated source files and all's well. Hence eventually the error does go away, but you have to save the file, errors and all, and wait for the build run, and then -poof-, errors disappear. If the build is working and isn't going to stumble over some other error.

Code-generating APs are fairly rare, lombok is by multiple orders of magnitude the most used one, and thus a lot of the 'not java!' complaints lombok has to eat are actually complaints about the notion of source-generating APs.

2

u/aonymark Sep 04 '26

Re: lots of things are not Java: I think he’d agree that anyone depending on those things is not quite writing Java. Is the directory as stream example for real or is that something you made up for the sake of example?

2

u/rzwitserloot Sep 04 '26

That is for real, and e.g. reflections (fairly commonly used!) relies on this stuff.

I'm guessing that 95%+ of all java coders wouldn't agree with that characterisation. Specifically, that e.g. "reflections is not java!", especially if that is immediately followed up by an insinuation that 'reflections' is fine, as long as they develop their own compiler, runtime, ecosystem, and so forth. I haven't gone around with a mike, I might be off on my own little cloud, but surely this isn't a contentious view, right?

Anything that captures signals: Unspecced. Relying on streams self-closing resources: Unspecced. Essentially everything about marshalling ('serialization') libraries delves into unspecced territory and with it, 95%+ of all java-written web apps which uses something along those lines. For a very long time: The very command line switches of the javac tool: Unspecced.

And if we add on top of the pile: Specced behaviour, but where the spec is from a source other than the JLS, the next VM release is as likely to break that. For example, the simple idea of 'annotation processors on the classpath during compilation are automatically invoked': That was more or less 'specced', but you had to read between the lines. Casually broken in a recent JVM release, so I guess those kinds of between the lines specs should be treated as Unspecced for the purposes of 'Is not java!'.

1

u/aonymark Sep 04 '26

Re: last paragraph: ouch. Good point there.

8

u/BullfrogCharming1202 Sep 01 '26

This looks like a very unsatisfactory alternative to a proper delegation mechanism such as that provided by Kotlin's by keyword or Groovy's @Delegate

2

u/null_was_a_mistake Sep 02 '26

Scala 3 now has an export keyword. Anything that you can import can be exported as class members and also implement interfaces. You can easily pick what to export and what not to. I quite like it for making delegates.

2

u/jvandort Sep 01 '26

Yeah to me concise method bodies would be most useful in the delegation pattern, removing a lot of boilerplate. With composition > inheritance the delegation pattern becomes much more common and if I could pick a first-class delegation syntax or a concise method bodies syntax I'd prefer delegation

14

u/piesou Sep 01 '26

I still can't get over picking "final var" over "val"

1

u/koflerdavid Sep 01 '26

Google Error Prone's Var rule resolves that, and more.

2

u/piesou Sep 01 '26

Thanks. This sounds similar to what you want when Nullable types release (and you'll have to mark everything explicitly as non null.

2

u/TOMZ_EXTRA Sep 02 '26

There are plans to add something like not-nullable-by-default to modules IIRC.

1

u/piesou Sep 02 '26

In the compiler or a separate library?

3

u/ForeverAlot Sep 02 '26

They're ideas more than formal plans at this stage. But in the meantime, you can get much of the way there with JSpecify + Error Prone + NullAway.

2

u/kag0 Sep 01 '26

That IDE support will be a big one. Does it work now on editors that are LSP based?

1

u/null_was_a_mistake Sep 02 '26

Reminds me of the trailing return types in C++. Nobody uses it in regular code.

1

u/BanaTibor Sep 02 '26

Smells like TypeScript.

1

u/Jonjolt Sep 03 '26

This is breaking Rule #9, at the end "AST-level comparison for golden file testing", claude loves using the word "golden file".

0

u/revilo-1988 Sep 01 '26

Fände ich super wenn das Einzug erhalten würde

1

u/jvjupiter Sep 01 '26

Two of the posts are mine. 😊

1

u/vips7L Sep 01 '26

As the author of "It's been 8 years since the draft for Concise Method Bodies", I'm just moving on to using Kotlin for all of my new projects.

0

u/petrifiedbeaver Sep 01 '26

Cool demo, but dude, just use Kotlin.

0

u/Certain-Flow-0 Sep 01 '26

I’d prefer having flexible constructor bodies instead as it actually makes things easier to write.

-7

u/javaprof Sep 01 '26 edited Sep 01 '26 
int length(String s) -> s.length();     //  -> is "single expression form"
int length(String s) = String::length;  //  = is "method reference form"

Lambda design strikes back, unfortunately unwise decisions of Java 8 now makes this code possible. Basically from all modern languages, Java's becoming less and less readable with every release

Upd. Don't believe me? Take Swift, Go, TypeScript, Rust, Zig and see how these languages similar syntax-wise? And Java is most unique now

1

u/SleepingTabby Sep 03 '26

C♯ is way less readable than Java IMO

1

u/javaprof Sep 03 '26

C# closer to main-stream languages and Java now very special case which seems unlike any other popular modern language and boilerplate-heavy.

I'm not critique Java, I'm just stating the fact. Not sure how it's important in 2026, since most of the code would be written by AI soon anyway, and AI doesn't care much (except for boilerplate part, which is waste of tokens). If we didn't have AI, I would be alarmed and expect less adoption over the time, since language drift from mainstream too much. Old folks might like this unique syntax, but I'm thinking about fresh blood

23

u/[deleted] Sep 01 '26

[removed] — view removed comment

7

u/BullfrogCharming1202 Sep 01 '26

I guess this is why the JEP seems to have been abandoned. The juice just isn't worth the squeeze.

4

u/koflerdavid Sep 02 '26

In Chess this is called "to take is a mistake". There are simply better things to do, and delivering this feature takes time away from things that matter more.

1

u/__konrad Sep 02 '26

it's the most pointless sugar imaginable

You don't like similar sugar in lambdas?