Narayanan wrote:
Daniel John Debrunner wrote:
Knut Anders Hatlen wrote:
Narayanan <[EMAIL PROTECTED]> writes:
"If you try to load a class in a sealed package from another source
other than the JAR file in which the sealed package lives, the JVM
will throw a |SecurityException|."
here http://www.ibm.com/developerworks/library/j-jar/#N101D6 as the
last line in the Package sealing sub-header.
By "load a class ... from another source" I think he means that the
loaded class is located in another source, not that the code that causes
the class to be loaded is in another source.
Right, derbynet.jar uses sealed classes from derby.jar, so sealing is
not an issue here.
Dan.
Well I guess I misinterpreted this. But just thinking aloud why isn't
derby.jar sealed in
entirety if sealed classes can anyway be used from outside?
Well maybe because the presence of the class was required in other jars
as well and
we wanted to allow the derby build system to include these classes in
the other jars
without causing a sealing violation similar to Derby-2701 (keeping with
the explanation
given by knut).
Right, in some cases we need the same class in multiple jars (e.g.
sysinfo related classes), in other cases we put classes from different
jars in the same package (o.a.d.jdbc has embedded drivers from derby.jar
and client drivers from derbyclient.jar).
Dan.
