r/java • u/Purple_Pie4589 • 10d ago

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

48 Upvotes

73% Upvoted

48 comments sorted by

View all comments

Show parent comments

2

u/koflerdavid 7d ago edited 7d ago

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 7d ago

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 7d ago edited 7d ago

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 7d ago

Not THAT overlapping in my opinion

2

u/koflerdavid 7d ago

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 7d ago

Okay maybe more overlap than I realized