Returns the name of the vendor that owns and maintains the specification that
this package implements, or null if the vendor is unknown.public StringgetImplementationTitle()Returns the title of the implementation provided by this package, or null if
the title is unknown.public StringgetImplementationVersion()Returns a string describing the version of the implementation provided by
this package, or null if the version is unknown.public StringgetImplementationVendor()Returns the name of the organization (vendor) that provided this
implementation, or null if the organization is unknown.For example, extracting this information for the java.lang package on our system yielded the following:[4]
[4] Yes the 1.4 specification version is a bugSpecification Title: Java Platform API Specification
Specification Version: 1.4
Specification Vendor: Sun Microsystems, Inc.
Implementation Title: Java Runtime Environment
Implementation Version: 1.5.0_02
Implementation Vendor: Sun Microsystems, Inc.
Specification version numbers are non-negative numbers separated by periods, as in "2.0" or "11.0.12".
This pattern allows you to invoke the isCompatibleWith method to compare a version following this
pattern with the version of the package. The method returns true if the package's specification version
number is greater than or equal to the one passed in. Comparison is done one dot-separated number at a time.
If any such value in the package's number is less than the one from the passed in version, the versions are not
compatible. If one of the version numbers 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 implementations. The only comparison you can perform between implementation
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 different 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 booleanisSealed()Returns TRue if the package is sealed.public booleanisSealed(URL url)