-
Bug
-
Resolution: Fixed
-
P4
-
1.4.0
-
None
-
mantis
-
generic
-
generic
The implementation of the ObjectStreamClass.packageEquals() method may
return false positives in some cases. The current code assumes that the
Package object obtained from Class.getPackage() identifies a "runtime"
package--i.e., a class foo.C1 defined in class loader CL1 and a class foo.C2
defined in class loader CL2 will return distinct (non-equals()) Package
objects from getPackage(). This assumption is incorrect--Package instances
can be shared among delegating class loaders--so the packageEquals() method
can incorrectly return true if the two compared classes have the same
package name but are loaded in separate (parent and child) class loaders.
This can in turn result in invocation of the constructor of the wrong
non-serializable superclass, or the wrong writeReplace/readResolve method.
return false positives in some cases. The current code assumes that the
Package object obtained from Class.getPackage() identifies a "runtime"
package--i.e., a class foo.C1 defined in class loader CL1 and a class foo.C2
defined in class loader CL2 will return distinct (non-equals()) Package
objects from getPackage(). This assumption is incorrect--Package instances
can be shared among delegating class loaders--so the packageEquals() method
can incorrectly return true if the two compared classes have the same
package name but are loaded in separate (parent and child) class loaders.
This can in turn result in invocation of the constructor of the wrong
non-serializable superclass, or the wrong writeReplace/readResolve method.
- relates to
-
JDK-8289290 Serialization spec should be extended for writeReplace and readResolve lookup
-
- Open
-