Java Reference
In-Depth Information
bers has more components than the other, the missing components in
the shorter version number are considered to be zero. For example, if
the package's specification version is
"1.4"
and you compare it to
"1.2"
,
"1.3.1"
, or
"1.1.8"
, you will get
TRue
, but if you compare it to
"1.4.2"
or
"1.5"
, you will get
false
. This comparison mechanism assumes backward
compatibility between specification versions.
Implementation version numbers do not have a defined format because
these will be defined by the different organizations providing the imple-
mentations. The only comparison you can perform between implement-
ation versions is a test for equalitythere is no assumption of backward
compatibility.
Packages can be
sealed,
which means that no classes can be added to
them. An unsealed package can have classes come from several differ-
ent places in a class search path. A sealed package's contents must all
come from one placegenerally either a specific archive file or a location
specified by a
URL
. Two methods ask if a package is sealed:
public boolean
isSealed()
Returns
TRue
if the package is sealed.
public boolean
isSealed(URL url)
Returns
true
if the package is sealed with respect to the given
URL
, that is, classes in the package can be loaded from the
URL
.
Returns
false
if classes in the package cannot be loaded from
the given
URL
or if the package is unsealed.
The specification and implementation information for a package is usu-
ally supplied as part of the manifest stored with the packagesuch as
the manifest of a Java Archive (jar) file, as described in "
Archive Files
java.util.jar
"
on page
735
.
This information is read when a class gets
loaded from that package. A
ClassLoader
can dynamically define a
Pack-
age
object for the classes it loads:
