Enable LTW in JDK 16+ without --add-opens
#117
Comments
nope. |
|
This is a big issue. I don't want to write this to my vm option. |
@KillerJmc, nobody does. But it is necessary. Feel free to either complain to the OpenJDK team, to suggest a technically viable strategy to solve the problem or provide a pull request. Alternatively, use compile-time instead of load-time weaving. Hi @mlchung, is JDK-8200559 still scheduled to be fixed in JDK 21? If so, can you please elaborate on how we could in the future use the corresponding new JDK feature? You were talking about this issue with AspectJ project lead @aclement before in Bugzilla 546305. This is still a major issue for byte code engineering tools such as Byte Buddy or AspectJ. |
### TODO: Add better description and force-push, if tests are OK. ### Fixes #117. Signed-off-by: Alexander Kriegisch <[email protected]>
Overhaul ClassLoaderWeavingAdaptor to use statically initialised Unsafe instances and method handles pointing to their 'defineClass' methods. Those now work universally on JDKs 8-21. In older JDKs, the method used to be in sun.misc.Unsafe, in more recent ones on jdk.internal.misc.Unsafe. It is challenging to fetch instances, especially as reflection protection and module boundaries have been increased in the JDK progressively. But finally, a solution was adapted from Byte Buddy (BB). Kudos to BB author Rafael Winterhalter. The previous solution to use ClassLoader::defineClass and require '--add-opens' is no longer necessary for the first time since it became necessary in AspectJ 1.9.7 with Java 16 support. Add org.ow2.asm:asm-common as a dependency everywhere org.ow2.asm:asm was used before. Maybe that is too many places, but no worse than before. Add missing dependency to loadtime to aspectjweaver. This kept a build like "mvn install -am -pl aspectjweaver" from picking up changed loadtime classes. Fixes #117. Signed-off-by: Alexander Kriegisch <[email protected]>
Overhaul ClassLoaderWeavingAdaptor to use statically initialised Unsafe instances and method handles pointing to their 'defineClass' methods. Those now work universally on JDKs 8-21. In older JDKs, the method used to be in sun.misc.Unsafe, in more recent ones on jdk.internal.misc.Unsafe. It is challenging to fetch instances, especially as reflection protection and module boundaries have been increased in the JDK progressively. But finally, a solution was adapted from Byte Buddy (BB). Kudos to BB author Rafael Winterhalter. The previous solution to use ClassLoader::defineClass and require '--add-opens' is no longer necessary for the first time since it became necessary in AspectJ 1.9.7 with Java 16 support. Add org.ow2.asm:asm-common as a dependency everywhere org.ow2.asm:asm was used before. Maybe that is too many places, but no worse than before. Add missing dependency on loadtime to aspectjweaver. This kept a build like "mvn install -am -pl aspectjweaver" from picking up changed loadtime classes. Fixes #117. Signed-off-by: Alexander Kriegisch <[email protected]>
Overhaul ClassLoaderWeavingAdaptor to use statically initialised Unsafe instances and method handles pointing to their 'defineClass' methods. Those now work universally on JDKs 8-21. In older JDKs, the method used to be in sun.misc.Unsafe, in more recent ones on jdk.internal.misc.Unsafe. It is challenging to fetch instances, especially as reflection protection and module boundaries have been increased in the JDK progressively. But finally, a solution was adapted from Byte Buddy (BB). Kudos to BB author Rafael Winterhalter. The previous solution to use ClassLoader::defineClass and require '--add-opens' is no longer necessary for the first time since it became necessary in AspectJ 1.9.7 with Java 16 support. Add org.ow2.asm:asm-common as a dependency everywhere org.ow2.asm:asm was used before. Maybe that is too many places, but no worse than before. Add missing dependency on loadtime to aspectjweaver. This kept a build like "mvn install -am -pl aspectjweaver" from picking up changed loadtime classes. Fixes #117. Signed-off-by: Alexander Kriegisch <[email protected]>
|
We finally have a solution for this, and I am actually a little bit proud of the achievement, even though part of the credit goes to Byte Buddy, where I found something to adapt into AspectJ, but using ASM directly instead (which is also used under the hood in BB, even though not so visible in the code there). The relevant code sections in What I am not proud of is that we still need |
|
@aclement, what I have no idea about is whether LTW used to work on GraalVM (never tried using it) before and, if so, it would still work after this change. Maybe you or one of your team mates could verify this. It might have an impact on Spring Native too, I have no idea. |
|
Wow! Awesome! Please notify me when the new version is released. |
|
You should not expect me to personally notify you of a new release. I already send notifications to the AspectJ users and announcements mailing lists, and you can easily subscribe to GitHub releases using the "Watch" button and then customise the notifications of your choice. |
Relates to #117. In commit f986c3d, the asm-commons dependency became necessary to pull off the new trick to define classes in arbitrary class loaders during LTW. The dependency was added to aspectjweaver, but not to aspectjtools due to an oversight. As aspectjtools is meant to be a super set of aspectjweaver, add the dependency to the assembly descriptor. Signed-off-by: Alexander Kriegisch <[email protected]>
Since 1.9.7, the AspectJ release notes say:
@aclement, do you have any ideas how to solve this?
See also:
Maybe taking a look at how other tools like Byte Buddy or Javassist try to define classes in other class-loaders can be helpful, e.g. https://github.com/jboss-javassist/javassist/blob/master/src/main/javassist/util/proxy/DefineClassHelper.java.
The text was updated successfully, but these errors were encountered: