Review request 8057645: Deprivilege JAX-WS, JAXB, JAF to extension class loader

Miroslav Kos miroslav.kos at
Wed Jan 28 17:11:05 UTC 2015

On 26/01/15 20:23, Mandy Chung wrote:
> This patch proposes to move, java.xml.bind, 
> java.activation out of the boot loader and be loaded by the extension 
> class loader.  We grant and java.xml.bind the minimum set 
> of permissions.  java.activation hasAllPermission for now and that can 
> be revised in the future when JAF team identifies the permission set 
> required java.activation.
> Miroslav - can you confirm if the JAX-WS and JAXB standalone tests 
> pass with this patch?
Hi Mandy,

I just ran standalone JAX-WS tests and without SM results are ok, with 
SM enabled I will need some more time - our WS-harness (test framework) 
requires some permissions too so I'll need to investigate which ones are 
those. Up to now, we used single policy file which was union of 
permissions requred by WS-harness + JAX-WS runtime.

I'll ping you when have more results.
For JAX-B, we are currently unable to run standalone tests against JDK.


> Existing code that assumes the defining class loader of JAX-WS, JAXB, 
> JAF classes may be impacted by this change (e.g. the class loader 
> delegation to the bootstrap class loader skipping the extension class 
> loader).  They are standalone technologies that used to be loaded by 
> non-null class loader before they were included in Java SE.  It should 
> be rare of such dependency. Callbacks may assume and 
> java.xml.bind classes to have AllPermissions so that when running with 
> security manager, if the permission required for callback is not part 
> of the permission set granted to and java.xml.bind, 
> SecurityException will be thrown. We need customer testings to 
> identify this callback permission case and revisit if they should be 
> granted with AllPermission for JDK 9.
> Mandy

More information about the core-libs-dev mailing list