Java Cookbook, Second Edition

One of the better aspects of the Java language is that it has defined a very clear packaging mechanism for categorizing and managing the external API. Contrast this with a language like C, where external symbols may be found in the C library itself or in any of dozens of other libraries, with no clearly defined naming conventions.[1] APIs consist of one or more packages; packages consist of classes; classes consist of methods and fields. Anybody can create a package, with one important restriction: you or I cannot create a package whose name begins with the four letters java. Packages named java. or javax. are reserved for use by Sun Microsystems' Java developers. When Java was new, there were about a dozen packages in a structure that is very much still with us; some of these are shown in Table 23-1.

[1] This is not strictly true. On Unix, at least, there is a distinction between normal include files and those in the sys subdirectory, and many structures have names beginning with one or two letters and an underscore, like pw_name, pw_passwd, pw_home, and so on in the password structure. But this is nowhere near as consistent as Java's java.* naming conventions.

Table 23-1. Java packages basic structure

Name

Function

java.applet

Applets for browser use

java.awt

Graphical User Interface

java.lang

Intrinsic classes (strings, etc.)

java.net

Networking (sockets)

java.io

Reading and writing

java.util

Utilities (collections, date)

Many packages have since been added, but the initial structure has stood the test of time fairly well. In this chapter, I show you how to create and document your own packages, and then discuss a number of issues related to deploying your package in various ways on various platforms.

Related

Категории