[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Martin Kouba resolved as Done Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Martin Kouba Status: Open Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1815 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title
Matej Novotny updated an issue
Weld / WELD-2460
JDK 9/10 - reflection usage, multirelease jar, testing
Change By:
Matej Novotny
Our main problem is {{ClassFileUtils}} which use CL to invoke {{defineClass()}}. In order to do this, you need to {{setAccessible()}} those methods which is a no-go for JDK 9+.There are two approaches that we can take:1. Use {{Unsafe}} to crack open the CL's methods and keep the code as it is* This is a "safe" way in that we know all will work as it did up to this point* We cannot be 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 11)2. We can use {{MethodHandles.Lookup}}, namely {{privateLookupIn()}} to define new classes ([branch with simple impl draft|https://github.com/manovotn/core/tree/methodHandles]) * This is the intended way, but it has limitations:** {{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()" rights** In WFLY, proxies built from JDK classes ({{Map}},...) use (top level) CL of the deployment's module*** Hence on undeploy those proxies are tossed away (no leaks)*** We cannot (easily) get such {{MethodHandle.Lookup}} 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 ([branch with draft|https://github.com/manovotn/core/tree/multiRelease]) ** Easy to do, nuisance to maintain and test (and bothersome with the current state of IDE support for those JDKs) Another illegal access issues is usage of JDK's internal BCEL classes.* We will replace this with optional Maven dependency* Hence this functionality will only work if user adds that dependency* This only hinders reporting error lines in bytecodeThere 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+ with {{--illegal-access=deny}} switch.
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title
Matej Novotny updated an issue
Weld / WELD-2460
JDK 9/10 - reflection usage, multirelease jar, testing
Change By:
Matej Novotny
Our main problem is {{ClassFileUtils}} which use CL to invoke {{defineClass()}}. In order to do this, you need to {{setAccessible()}} those methods which is a no-go for JDK 9+.There are two approaches that we can take:1. Use {{Unsafe}} to crack open the CL's methods and keep the code as it is* This is a "safe" way in that we know all will work as it did up to this point* We cannot be 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 11) * There is also a fair possibility this won't work on obscure Java distributions such as IBM JDK 2. We can use {{MethodHandles.Lookup}}, namely {{privateLookupIn()}} to define new classes* This is the intended way, but it has limitations:** {{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()" rights** In WFLY, proxies built from JDK classes ({{Map}},...) use (top level) CL of the deployment's module*** Hence on undeploy those proxies are tossed away (no leaks)*** We cannot (easily) get such {{MethodHandle.Lookup}} 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) Another illegal access issues is usage of JDK's internal BCEL classes. * We will replace this with optional Maven dependency* Hence this functionality will only work if user adds that dependency* This only hinders reporting error lines in bytecode 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+ with {{--illegal-access=deny}} switch.
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title
Matej Novotny updated an issue
Weld / WELD-2460
JDK 9/10 - reflection usage, multirelease jar, testing
Change By:
Matej Novotny
Our main problem is {{ClassFileUtils}} which use CL to invoke {{defineClass()}}. In order to do this, you need to {{setAccessible()}} those methods which is a no-go for JDK 9+.There are two approaches that we can take:1. Use {{Unsafe}} to crack open the CL's methods and keep the code as it is* This is a "safe" way in that we know all will work as it did up to this point* We cannot be 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 11) * There is also a fair possibility this won't work on obscure Java distributions such as IBM JDK 2. We can use {{MethodHandles.Lookup}}, namely {{privateLookupIn()}} to define new classes* This is the intended way, but it has limitations:** {{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()" rights** In WFLY, proxies built from JDK classes ({{Map}},...) use (top level) CL of the deployment's module*** Hence on undeploy those proxies are tossed away (no leaks)*** We cannot (easily) get such {{MethodHandle.Lookup}} 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+ with {{--illegal-access=deny}} switch.
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny assigned an issue to Matej Novotny Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Assignee: Matej Novotny Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Fix Version/s: 3.0.4.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Labels: jdk10 jdk9 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Summary: JDK 9 /10 - reflection usage, multirelease jar, testing Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Affects Version/s: 2.4.6.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
