PACKAGES

PACKAGES

Programs are organized as set of packages, with each package having its own set of names for types, which will help prevent name conflicts. We know by now that if a type is top level and declared public it is generally accessible outside the package. The sections below discusses other features of packages.

Package Members: package members are:
1. subpackages
2. all top level class types
3. top level interface types
where 2 and 3 are declared in all the compilation units of the package.
Note:
a. if a package P has a subpackage Q, then the fully qualified name of the subpackage is P.Q
b. a package may not contain 2 members of the same name or a compile-time error results.
c. The hierarchical naming structure for packages is intended for convenience in related-packages organization but has no significance except to prevent package members from being same name.

Host support for packages:

Each host determines how packages, compilation units and subpackages are created and started, and which compilation units are observed in a particular compilation.

Compilation unit observability in turn determines which packages are observable and which packages are in scope.

Packages may be stored in a local file system or use a distributed file system or some form of database to store source and/or binary code.

Storing packages in a file system: imagine that a directory is used to store the packages that are used for a project, then each immediate subdirectory of the directory would represents a top level package i.e one whose fully qualified name consists of a single simple name.

e.g subdirectories might be java or com or one you created yourself, like api_package. The directory java might contain, amongst others, the subdirectories applet, awt, io, lang or util. these subdirectories then correspond to the packages java.applet; java.awt; java.io; java.lang; java.util which are defined as part of the java API.

Inside the util directory, we might get the following files:
BitSet.java, BitSet.class where the .java files contain the source code and the .class files contain the binary compiled files for a compilation unit that defines the class or interface.

So if we had something like: java.util.BitSet, then the directory structure in same a Windows file system will be java\util\BitSet i.e each package is said to have a top level directory where it is the subdirectory.

If a package name component or class name contains characters outside the allowed ranges (usually ASCII) of an Operating System’s directory naming scheme, the character outside the range can be escaped using the @ character followed by four hexadecimal digits giving the numeric value of the character, similar to the \uxxxx escape we earlier encountered in Unicode escaping.

Supposing we have a package name like this: children.activities.craft.papierM\u00e2ch\u00e9

which in Unicode will give us:
children.activities.craft.papierMâché

and this might be mapped to the directory name:
children\activities\craft\papierM@00e2ch@00e9 in Windows.

Note: if the @ character is not a valid character in a file name for some given host file system, then some other character that is not identifier-valid could be used instead.

Storing packages in a database:

When a host system stores programs, their compilation units and subpackages in a database, such a database must relax some restrictions on compilation units as found in file-based implementation, but provision should exist so that such a program can be exported to file-based implementation.

COMPILATION UNITS

A compilation unit is the goal symbol for the syntactic grammar of java. Note here that type dependence can be created amongst different compilation units i.e where a type contains another type as its member and that other type contains this type as its member.

A compilation unit consists of three parts, each of which is optional:

1. a package declaration, giving the fully qualified name of the package to which the compilation unit belongs. If there is no package declaration, then the package is an unnamed package.

2. import declaration that allows simple names use of types, given other packages and static members of types to be referred.

3. top level type declarations of class and interface types.

A host system determines which compilation units are observable but all compilation units of the package java and its subpackages java.lang and java.io must always be observable. The observability of a compilation unit affects the observability of the package.

Named Packages: a named package is one with a package declaration. A package declaration is defined thus:
Annotationsopt package PackageName ;

The keyword package may optionally be preceded by annotation modifiers. If an annotation a on a package declaration corresponds to an annotation type T, T has a (meta)annotation m that corresponds to annotation.Target, then m must have an element whose value is annotation.ElementType.PACKAGE, otherwise a compile time error occurs.

The PackageName in a package declaration must be the fully qualified name of the package.

Package annotations: annotations may be used on package declaration with the restriction that at most one annotated package declaration is permitted for a given package.

Unnamed Packages: a compilation unit where there is not package declaration is unnamed. Unnamed packages do not have subpackages.

Observability of a package: a package is observable if and only if either:
- a compilation unit containing a declaration of the package is observable.
- A subpackage of the package is observable.

Scope of a package declaration: provided that a package declaration is observable, the scope is all observable compilation units. Subpackage declarations are never in scope. Package declarations never shadow other declarations.