4 ms·

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 im

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.

pron 3y ago
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 reach into its internals (that can change at any time, BTW) to turn it into a compiler for your new language. Their choices are fine; telling users they've chosen something else is not.