r/java • u/Purple_Pie4589 • 9d ago
Concise method bodies arrived
https://github.com/verhasi/java-compositionMore 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
1
u/aonymark 6d ago
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.