<Core><Intermediate><Advanced>
Overview | Packages | Class Internals | Collections | I-O | Network | Database 

Every class in Java belongs to a package, and is referenced in code by the import statement or by the fully-qualified class name. A package is a grouping of related classes and may have a sub package. Packages allow Java class variables to have class-level or package-level access via the access modifiers public, protected, or private. User-defined classes may be grouped to belong to user-defined packages, but not to built-in packages. Classes that don't belong to any package are said to belong to 'default' package, though the term is not a keyword as defined by the Java language specification. We will see more about these modifiers in the next section 'class internals'.

Packages are arranged hierarchically, and are rooted in either java or javax package, the latter is an extension to the core Java classes originally released as version 1.0. The core packages consist of classes required to perform routine computing tasks such as text manipulation, input/output and networking.

Here is an overview of Java core packages:

java
  |____awt
  |         |____event
  |
  |____lang
  |
  |
  |____util
  |
  |
  |____io
  |
  |
  |____net
  |
  |
  |____sql

While we will see the classes in these packages in detail as we go along, it does not hurt to take a peek now.

The lang package is available to all classes as default, that is, you don't have to explicitly specify this package in the import statement when you use any classes from this package such as String and StringBuffer.

The util package, as the name suggests, consists of utility classes such as the collection classes and the Date class. The collection classes require that you only store objects. So, if you want to store a numeric, you need to convert it into an object first. The lang package has a class called Integer, which you can use to change a number to an object, and vice versa.

The io package deals with input and output streams and is by far the largest package in core Java. It has a forest of classes that let you stream almost anything that can be digitized, and are so convenient that any device from a satellite to a mobile phone can be used if it supports streaming. All the horrible internals are transparent to the developer.

The net package, as you might have guessed, has classes that let two systems talk, no matter what those systems are and where, as long as they are connected by a network and understand Java bytecode. This package relies heavily on the io package for communication.

Again, as the name suggests, the sql package deals with database connectivity and management of a data  store.

The awt contains classes for the user interface and in its expanded form means Abstract Windowing Toolkit. The toolkit provides display of user interface elements that are platform specific and relies on the underlying GUI toolkit to provide the functionality. It has a sub package event that has classes for transmitting mouse and keyboard events to the underlying system via system calls (totally transparent to the developer). Event handling in Java has graduated quite a bit from its original avatar, and shall be dealt with in another section.

Take a look at this code snippet:

package com.nanpackage.store;

import java.util.*;

public class JavaStore {
   
    private static Hashtable pairs = new Hashtable();
   
    public JavaStore() {

         pairs.put("nan", "1345");
         pairs.put("tan", "5432");
         pairs.put("zan", "3456");
   }

   public static void main(String[] args) {
      
       new JavaStore();
       Enumeration enum = pairs.keys();

       while(enum.hasMoreElements()) {

           String key = (String)enum.nextElement();
           String val = (String)pairs.get(key);

           System.out.println("Name: "+key+"          "+"Number: "+val);
      }
   }
}

Note the second line of the code. We import the util package so we could use the Hashtable class in it. Hashtable is a class that lets us store name-value pairs. It is a kind of associative array that holds what are called keys and values associated with those keys. We also used an instance of the Enumeration class from this package. It is basically an iterator that helps you to loop over the contents of a collection.

The pairs variable is declared static because we are using it in the function that is also by definition static. Declaring a variable or a function static has a significance we shall see later.

There is a method by the same name as that of the class JavaStore. It is a constructor; it has no return type, and is used to instantiate objects of this class. We use it to populate the pairs instance of the Hashtable that is declared and initialized to default capacity before the constructor.

Both Hashtable and Enumeration classes, like all the collection classes, store and return objects of the generic type. It means, if you store dogs, you will get back objects, which you must cast to the type that you originally stored it in. Theoretically, it is possible to type cast a Dog object that you stored to a Cat object on return, but you would do it with, perhaps, disastrous consequences. Here we store objects of the String type, so we get back our strings using the type-cast operator (<class-name>).

At last, coming to the first line of code, it simply means that the class we defined is to be placed in a package called com.nanpackage.store. If a package is defined for a class, it shall be the first line of code.

Package convention
A convention followed by Java developers in naming the class packages is to reverse the domain name and append the package name to it. We assume that the domain name in our example is www.nanpackage.com, and so we place the store sub package under it as com.nanpackage.store.

When you compile this class, the compiled code is accessible as com.nanpackage.store.JavaStore. So you will have a directory hierarchy as under:

com
  |___nanpackage
               |_______store

The package hierarchy translates as a folder hierarchy in physical terms, and accessible accordingly. So when you compile the source code from, say my_src directory, you get a class file as com.nanpackage.store.JavaStore. But if you try to run it from there, you get an exception:

Exception in thread "main" java.lang.NoClassDefFoundError: com/nanpackage/store/JavaStore

You create the folder hierarchy as com/nanpackage/store under my_src and move the class to store. Then you can run it from my_src folder. There is compiler option with javac that automatically creates the necessary folders for you based on the package declaration.

javac -d . JavaStore

The -d option stores the class files relative to the directory specified; here wanted from the current directory ( the dot following -d means that ) where we have our source file. And lo! You have the correct directory structure specified by the package declaration.