| by Patrick Bouklee
|
||
IntroductionMany times when we get a chance to work on a small project, one thing we intend to do is to put all java files into one single directory. It is quick, easy and harmless. However if our small project gets bigger, and the number of files is increasing, putting all these files into the same directory would be a nightmare for us. In java we can avoid this sort of problem by using Packages. Packages are nothing more than the way we organize files into different directories according to their functionality, usability as well as category they should belong to. An obvious example of packaging is the JDK package from SUN (java.xxx.yyy) as shown below:
Figure 1. Basic structure of JDK package Basically, files in one directory (or package) would have different functionality from those of another directory. For example, files in java.io package do something related to I/O, but files in java.net package give us the way to deal with the Network. In GUI applications, it's quite common for us to see a directory with a name "ui" (user interface), meaning that this directory keeps files related to the presentation part of the application. On the other hand, we would see a directory called "engine", which stores all files related to the core functionality of the application instead.
Packaging also help us to avoid class name collision when we use the same class name as that of others.
For example, if we have a class name called "
Suppose we have a file called
One thing you must do after creating a package for the class is to create
nested subdirectories to represent package hierachy of the class.
In our case, we have the
Figure 2. HelloWorld in world package (C:\world\HelloWorld.java) That's it!!! Right now we have
From figure 2 we put the package We set theset CLASSPATH=.;C:\; CLASSPATH to point to 2 places, . (dot) and C:\ directory.
Note: If you used to play around with DOS or UNIX, you may be familiar with . (dot) and .. (dot dot). We use . as an alias for the current directory and .. for the parent directory. In our CLASSPATH we include this . for convenient reason. Java
will find our class file not only from C: directory but from the current directory as well. Also, we use ; (semicolon) to separate the directory location in
case we keep class files in many places.
When compiling If you try to run thisC:\world\javac HelloWorld.java HelloWorld using java HelloWorld, you will get the following error:
The reason is right now the HelloWorld class belongs to the package world.
If we want to run it, we have to tell JVM about its fully-qualified class name (world.HelloWorld) instead of its plain class name (HelloWorld).
Note: fully-qualified class name is the name of the java class that includes its package nameC:\world>java world.HelloWorld C:\world>Hello World To make this example more understandable, let's put the
Figure 3. HelloWorld class (in world package) under myclasses directory We just changed the location of the package from C:\world\HelloWorld.java to C:\myclasses\world\HelloWorld.java.
Our Thus, Java will look for java classes from the current directory and C:\myclasses directory instead.set CLASSPATH=.;C:\myclasses; Someone may ask "Do we have to run the C:\>set CLASSPATH=.;C:\; C:\>set CLASSPATH // see what we have in CLSSPATH CLASSPATH=.;C:\; C:\>cd world C:\world>java world.HelloWorld Hello World C:\world>cd .. C:\>java world.HelloWorld Hello World
If we store the package ![]() Figure 4. HelloMoon in world.moon package
Although we add a subpackage under package world, we still don't have to change anything in our How to use packageThere are 2 ways in order to use the public classes stored in package.1. Declare the fully-qualified class name. For example, 2) Use an "... world.HelloWorld helloWorld = new world.HelloWorld(); world.moon.HelloMoon helloMoon = new world.moon.HelloMoon(); String holeName = helloMoon.getHoleName(); ... import" keyword:
import world.*; // we can call any public classes inside the world package import world.moon.*; // we can call any public classes inside the world.moon package import java.util.*; // import all public classes from java.util package import java.util.Hashtable; // import only Hashtable class (not all classes in java.util package) Thus, the code that we use to call the HelloWorld and HelloMoon class should beNote that we can call public classes stored in the package level we do the import only. We can't use any classes that belong to the subpackage of the package we import. For example, if we import package... HelloWorld helloWorld = new HelloWorld(); // don't have to explicitly specify world.HelloWorld anymore HelloMoon helloMoon = new HelloMoon(); // don't have to explicitly specify world.moon.HelloMoon anymore ... world, we can use only the HelloWorld class, but not the HelloMoon class.
Using classes stored in jar fileJar files are the place where we put a lot of files to be together. We compress these files and make them as a single bundle. Jar files may also include directories, subdirectories to represent class and package hierachy. Normally, we can see what is inside a jar file by using the commandjar -tvf fileName.jar as shown in Figure 5:
Figure 5. JSDK package viewed by jar -tvf jsdk.jar command
From figure 5 we see that there is a class called import javax.servlet.http.Cookie; // import only Cookie class or import javax.servlet.http.*; // import the whole javax.servlet.http package But we have to include this package in the Note that if the package is stored inside a jar file, we have to include the jar file with its extension (.jar) in theset CLASSPATH=.;D:\JSDK2.0\lib\jsdk.jar; CLASSPATH. However, if the package is a plain directory, we just put the name of
directory into the CLASSPATH.
|