3 ms·
Lombok's headaches are because they are touching Java compiler internals to accomplish their magic. This won't fix that. Lombok wouldn't be nearly as troubled
by cogman10 3y ago
Lombok's headaches are because they are touching Java compiler internals to accomplish their magic. This won't fix that.
Lombok wouldn't be nearly as troubled if it was just doing simple bytecode manipulation.
If lombok wants to stop the pain, then they'll need to stop reaching into internal APIs. They'll possibly need to remove a few features (like some of the `private final` work they are doing).
In other words, you can expect lombok to be a headache for years to come. (Maybe consider not using it? That'd be swell. Speaking as someone that curses lombok everytime jdk updates roll around.)
- the-smug-one 3y agoWhy isn't Lombok just written as a pre-javac pass? javac(lombok(srccode)). Just gotta keep that parser alive and up to date, which open source IDEs also must so they're probably available.
- tmccrary55 3y agoIt's easier (read more reliable) to manipulate bytecode or other internal representation than the source.
- aardvark179 3y agoManipulating the AST would be fine, but Lombok pretends to be an annotation processor (which can generate new classes, but not alter the semantics of the class being processed). They could create lombokc and crack open the internals of the Java compiler as much as they like, but this would mean admitting they are really Java, and they don’t seem to want to accept that.