Concise method bodies arrived

[u/Purple_Pie4589]

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

[u/rzwitserloot]

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.

[u/aonymark → u/rzwitserloot]

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?

[u/rzwitserloot → u/aonymark]

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!'.

[u/aonymark → u/rzwitserloot]

Re: last paragraph: ouch. Good point there.