JDK-6567947 : java.lang.NoClassDefFoundError while loading http://bugster.sfbay.sun.com using Kernel JRE
Type:Bug
Component:deploy
Sub-Component:deployment_toolkit
Affected Version:6u4
Priority:P2
Status:Closed
Resolution:Fixed
OS:windows
CPU:x86
Submitted:2007-06-09
Updated:2010-09-08
Resolved:2007-08-03
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
java.lang.NoClassDefFoundError while loading http://bugster.sfbay.sun.com with Kernel JRE .
Error:
java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.SunJCE_b
Comments
EVALUATION
There were two issues at work here:
1) The JCP provider JARs are signed, and the signature wasn't surviving the pack200 / unpack200 cycle.
2) The JCP provider JAR was inadvertently being loaded by the boot class loader, despite living in the lib/ext subdirectory. This was preventing the signature from being verified even when it was correct.
For the time being, packing has simply been disabled on signed JRE jars. A better fix would be to alter the build process to generate JARs that could survive pack / unpack with intact signatures, but that is a bigger change than we have time for at the moment. The extension class loader was also modified to check for a download before trying to load a given class; this means that the search never bubbles up to the boot class loader and so the JAR never ends up on the boot class path.