[weld-issues] [JBoss JIRA] (WELD-2619) Refactor ClassFileUtils to operate better on JDK 11+

2020-08-11 Thread Jira
Title: Message Title


 
 
 
 

 
 
 

 
   
 Issue was automatically transitioned when Matěj Novotný created pull request #11 in GitHub  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Weld /  WELD-2619  
 
 
  Refactor ClassFileUtils to operate better on JDK 11+   
 

  
 
 
 
 

 
Change By: 
 Matěj Novotný  
 
 
Status: 
 Open Pull Request Sent  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c)  
 
 

 
   
 

  
 

  
 

   

___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues

[weld-issues] [JBoss JIRA] (WELD-2619) Refactor ClassFileUtils to operate better on JDK 11+

2020-03-28 Thread Jira
Title: Message Title


 
 
 
 

 
 
 

 
   
 Matěj Novotný created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Weld /  WELD-2619  
 
 
  Refactor ClassFileUtils to operate better on JDK 11+   
 

  
 
 
 
 

 
Issue Type: 
  Enhancement  
 
 
Affects Versions: 
 3.1.4.Final  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 Proxies  
 
 
Created: 
 28/Mar/20 7:26 AM  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Matěj Novotný  
 

  
 
 
 
 

 
 There was a series of issues around class loading on JDK 11+ and those problems persist. We need to take a look at how to twist the logic in ClassFileUtils to work on JDK 11 without getting IllegalAccess warnings. Note that this concerns only SE and maybe Servlet as all EE integrators should use the new API that delegates class defining on them. One way is doing a multirelease JAR where we can keep current approach (cracking open CL with setAccessible() for JDK 8 and changing this file for JDK 11 using modular way of adding classes. I know last time I checked, there was a problem with: 
 
default packages - you always needed to add classes into existing package which is not what we currently do when we need to replace packages for proxies 
another problem was not being able to define classes with different ProtectionDomain, I am not certain how we use this and if it is even an issue in SE. 
 Another way could be to define our CL since then we would have full access to those methods. But I think this would likely do more harm then anything else. I am open to more suggestions Martin Kouba