JDK-4244970 : Sealing violations not found in certain cases
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:class_loading
  • Affected Version: 1.2.0,1.2.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_95
  • CPU: generic,x86
  • Submitted: 1999-06-09
  • Updated: 1999-06-24
  • Resolved: 1999-06-24
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.

To download the current JDK release, click here.
Other
1.3.0 betaFixed
Related Reports
Duplicate :  
Relates :  
Description
A sealing violation is not detected in the case where the first class in the
package is loaded from a directory (rather than a jar file) and the second
is loaded from a sealed jar file.  If the classes are loaded in the reverse
order, the sealing violation is detected.  The attached example has a 
Unix-specific makefile, but the bug should exist on Windows also.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: kestrel kestrel-beta INTEGRATED IN: kestrel-beta
14-06-2004

EVALUATION A sealing violation occurs when a Package object has been defined for a package foo, and later on, the same class loader or a descendent class loader tries to load some classes in the same package foo from a different url. The sealing violation checking depends on an existing Package object. A Package object is created if the package is bundled in a jar file with a manifest. Otherwise, no Package object is defined and will result in the undetected sealing violation described in the bug report. The fix should be that whenever the first class in any package is loaded, a Package object will be created for that package in all cases, no matter where is the class is loaded from, a directory, a jar file with a manifest or without a manifest. The fix will go into next build. ###@###.### 1999-06-23
23-06-1999