A DESCRIPTION OF THE PROBLEM :
In short: Since java9, the API available to Annotation Processors give only read-access to the AST, but not the ability to manipulate it. Still, accessing private APIs is (surprisingly) possible, but require complex hacks. Such hacks is for example the way lombok manages to modify the AST.
Details: the classes necessary to manipulate the AST lie in com.sun.tools.javac.tree. Since java 9, this package became inaccessible. The public interfaces that are accessible to Annotation Processors lie in the com.sun.source.tree package, but they only define read operations.
If an annotation processor wants to manipulate the AST (like project lombok does - see link above), it needs to hack its way around the security restrictions and "open" the restricted packages programmatically, using sun.misc.Unsafe or other similar mechanism.
I sense that the current situation keeps us stack between two worlds, while giving us the worst of both. On one side, the AST can be manipulated. If lombok does it, then anyone can do it the same way. On the other side, the way to do it is obscure, complex and cumbersome. It feels more like a hack than proper API design. I can see two solutions that make logical sense.
One. If modifying the AST should be forbidden for security reasons, then it should be clearly stated, documented, and there should be no backdoors. Annotation processors would be then just tools for validating files and generating existing files, but never modifying files. In this scenario, lombok would not exist at all.
I honestly would not recommend this path since lombok is massively popular, and for good reason. This means that modifying the AST is a very poweful feature, and there can be more annotation processors in the future that will be as useful lombok. It seems to me that this makes the java language more dynamic, flexible, expressive and popular.
Two (the solution I ask for). Provide a standardised, straightforward and documented way for annotation processors to modify the AST. Some mechanism that will not require us to hack around with sun.misc.Unsafe, and open packages that are not supposed to be opened. Probably making com.sun.tools.javac.tree public again would be the simplest solution. But any other way is of course welcome.
Last but not least: in case such AST-modifying mechanism already exists, please point it out to me, because the possibility that I am missing something is of course real.
In short: Since java9, the API available to Annotation Processors give only read-access to the AST, but not the ability to manipulate it. Still, accessing private APIs is (surprisingly) possible, but require complex hacks. Such hacks is for example the way lombok manages to modify the AST.
Details: the classes necessary to manipulate the AST lie in com.sun.tools.javac.tree. Since java 9, this package became inaccessible. The public interfaces that are accessible to Annotation Processors lie in the com.sun.source.tree package, but they only define read operations.
If an annotation processor wants to manipulate the AST (like project lombok does - see link above), it needs to hack its way around the security restrictions and "open" the restricted packages programmatically, using sun.misc.Unsafe or other similar mechanism.
I sense that the current situation keeps us stack between two worlds, while giving us the worst of both. On one side, the AST can be manipulated. If lombok does it, then anyone can do it the same way. On the other side, the way to do it is obscure, complex and cumbersome. It feels more like a hack than proper API design. I can see two solutions that make logical sense.
One. If modifying the AST should be forbidden for security reasons, then it should be clearly stated, documented, and there should be no backdoors. Annotation processors would be then just tools for validating files and generating existing files, but never modifying files. In this scenario, lombok would not exist at all.
I honestly would not recommend this path since lombok is massively popular, and for good reason. This means that modifying the AST is a very poweful feature, and there can be more annotation processors in the future that will be as useful lombok. It seems to me that this makes the java language more dynamic, flexible, expressive and popular.
Two (the solution I ask for). Provide a standardised, straightforward and documented way for annotation processors to modify the AST. Some mechanism that will not require us to hack around with sun.misc.Unsafe, and open packages that are not supposed to be opened. Probably making com.sun.tools.javac.tree public again would be the simplest solution. But any other way is of course welcome.
Last but not least: in case such AST-modifying mechanism already exists, please point it out to me, because the possibility that I am missing something is of course real.
- duplicates
-
JDK-8265887 Allow annotation processors to modify AST
-
- Closed
-