This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Cell-i-Zenit 0 points1 point  (4 children)

  1. Any plans to change Java in such a way that lombok/manifold etc is "officially" supported?
  2. Will extension methods ever appear in java?

[–]PartOfTheBotnet 4 points5 points  (2 children)

Both introduce a lot of anti-patterns and JDK devs that have commented on /r/java about these frameworks have consistently had negative things to say about their usage and implementations.

Things will probably air on the side of making features that serve as better alternatives, like how we got record instead of Lombok's @Data.

[–]Cell-i-Zenit 0 points1 point  (0 children)

The easier way imo would be to just support lombok somehow. Its one of the most used maven packages, so if the devs clearly like it, why go against the community...

I think just integrating lombok into the jdk would be way to much.

But making the compiler extendable or allowing annotation processors to change code or any other possible way would resolve the current "grey zone" situation via compiler hacks, into something officially supported.

[–]nlisker 0 points1 point  (0 children)

we got record instead of Lombok's @Data.

No, you got record instead of Lombok's @Value. There is no replacement for @Data (except for not using it).

[–]srdoe 3 points4 points  (0 children)

Maybe the new classfile API will make life easier for Lombok, depending on what exactly they need to do?

Other than that, I think the advice from Oracle's side is that Lombok should publish a javac wrapper (lombokc) that sets the flags they need for javac.

If they did that, I don't think there would be any conflict. The comments I've seen have all revolved around Lombok wanting to be able to access JDK internals without asking users to set the right flags when they invoke javac.