We need to inspect and rework our calls to JDK internal libs - with JDK 9 this Our main problem is permitted but throws warnings in logs {{ClassFileUtils}} which use CL to invoke {{defineClass()}} . In JDK 10 order to do this is , you need to be forbidden and {{ Handles setAccessible() }} anr/or those methods which is a no-go for JDK 9+.
There are two approaches that we can take:
1. Use {{Unsafe}} needs to be used. Once done, crack open the CL's methods and keep the code as it is
* This is a "safe" way in that we know all will likely need to java a multirelease JARs work as the new solution won't it did up to this point
* We cannot be available sure when/if/whether Oracle guys wake up one morning and say "Hey, we are removing those {{Unsafe}} methods!" (case of {{Unsafe.defineClass()}} in EA JDK 8. 11)
Note that it does not matter whether you
2. We can use classpath or module path {{MethodHandles . Lookup}}, namely {{privateLookupIn()}} to define new classes
One such case of our reflection usage * This is the intended way we create proxies by calling , but it has limitations:
** {{ ClassLoader Lookup .defineClass()}} has no way to specify {{ProtectionDomain}} which is something we currently do, we enrich it, so that newly added classes always have "getDeclaredFields ( protected method on CL ) in " rights
** In WFLY, proxies built from JDK classes ( {{ ClassFileUtils Map }} , . This could instead be done via either ..) use (top level) CL of the deployment's module
*** Hence on undeploy those proxies are tossed away (no leaks)
*** We cannot (easily) get such {{ Unsafe MethodHandle.Lookup }} or from WFLY and if we define those classes on our CL, we have a memory leak
*** This also entails change to our API where WFLY hands us over _some_ {{ MethodHandles. Lookup}} . which we can work with
** In WFLY, static modules w/o Weld dependency use (top level) CL of the deployment's module
*** Same problem as above
* This approach implies the need for *multi-release JAR* of at least {{core-impl}} artifact
** Easy to do, nuisance to maintain and test (and bothersome with the current state of IDE support for those JDKs)
There might be some changes required in classfilewriter itself which is to be discovered (likely related to https://github.com/jbossas/jboss-classfilewriter/issues/14)
* Newest version uses {{Unsafe.defineClass()}} so we need to update to that one for the time being (1.2.2.Final)
Another part of this issue is to ensure we are continuously testing on JDK 9 (or 10, doesn't matter) as well as JDK 8.
* Releases will be tested on JDK 8 + latest fully released JDK (9/10/11)
* All PRs will be tested on JDK 8 + latest fully released JDK (9/10/11)
** In the future with illegal access _denied_
Goal is to be able to execute all our tests with JDK 9 without any WARN messages related to + with {{-- illegal - access =deny}} switch . |
|
