Re:JEP 457: Class-File API for Parsing, generating, transfor...
by alserio on Tuesday September 26, 2023 @11:00PM
(#37669392)
Last time I checked, admittedly several years ago, Lombok was abusing the fact that the AST esposed to the annotation processors was mutable (exposing a deep immutable view over a complex data structure is not something that you do easily nor efficiently in Java to this day, so I'm not blaming javac here). The compiler estensionions were not really forbidden in any meaningful way to do what Lombok is doing, and given the difference in tooling and effort required for a new language I don't really blame them either.
That said, going against the whishes of the JSL has its risks, but I can understand Lombok's choice.
I still push against Lombok in the projects I work on since how it works makes me unconfortable.
[ Parent
| on HN ]
Re:JEP 457: Class-File API for Parsing, generating, transfor...
by pron on Wednesday September 27, 2023 @04:04AM
(#37671570)
There's nothing wrong with offering an alternative language or even with basing another language's compiler on javac. What's wrong is the misrepresentation of what they're doing and how they try to hide the technical risks involved from their users. Don't call yourself a Java library if you're really a different language that's very much not Java; don't say you're a compiler extension if you bypass the compiler extension API and change its internals to turn it into a compiler for your new language. Their choices are fine; telling users you've chosen something else is not.