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 usually 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 Package object for the classes it loads:

protected PackagedefinePackage(String name, String specTitle,

String specVersion, String specVendor, String implTitle,

String implVersion, String implVendor, URL sealBase)

Returns a Package object with the given name, and with specification and

implementation values set to the corresponding arguments. If sealBase is

null the package is unsealed, otherwise it is sealed with respect to that URL.

The Package object for a class must be defined before the class is defined

and package names must be unique within a class loader. If the package name

duplicates an existing name, an IllegalArgumentException is

thrown.

You can get the Package object for a given class from the getPackage method of the Class object for
that class. You can also get a Package object by invoking either the static method
Package.getPackage with the name of the package, or the static method Package.getPackages,
which returns an array of all known packages. Both methods work with respect to the class loader of the code
making the call by invoking the getPackage or getPackages method of that class loader. These class
loader methods search the specific class loader and all of its parents. If there is no current class loader then the
system class loader is used. Note that the class loader methods will return null if the package is unknown
because no type from the package has been loaded.

When a shepherd goes to kill a wolf, and takes his dog along to see the sport, he should take

care to avoid mistakes. The dog has certain relationships to the wolf the shepherd may have

forgotten.

Robert Prisig, Zen and the Art of Motorcycle Maintenance

Chapter 19. Documentation Comments

Any member introducing a dog into the Society's premises shall be liable to a fine of £10.

Any animal leading a blind person shall be deemed to be a cat.

Rule 46, Oxford Union Society (circa 1997)

Documentation comments, usually called doc comments, let you associate reference documentation for
programmers directly with your code. The contents of the doc comment can be used to generate reference
documentation, typically presented using HTML.

Doc comments are generally designed as fairly terse reference documentation. The reference documentation
typically covers the contract of the documented interface, class, constructor, method, or field to the level of
detail most programmers need. This approach is distinct from a full specification, which can be too long for
reference documentation. A full specification might devote several pages of text to a single method, whereas
reference documentation might be one or two paragraphs, possibly even short ones. Specifications should be