Page 1 of 3   next page »

• Watch Yakov Fain Delivering This Class Live

Java comes with thousands of classes that are organized in packages (similar to files and directories on you disk). Some packages include classes responsible for drawing, while other have classes for the Internet access, and so on. For example the class String is located in the package called java.lang, and the fully qualified name of this class is java.lang.String.

The Java compiler only knows where to find classes that are located in the package java.lang, but there are many other packages with useful classes, and it's your responsibility to let the compiler know where the classes that are used in your program live. For example, the package java.io contains classes responsible for input/output operations, while most of the Swing classes live in the following two packages:

javax.swing
javax.swing.event

It would be annoying to write a full class name every time you use it, for example:

javax.swing.JButton myButton = new javax.swing.JButton();
javax.swing.JFrame myFrame = new javax.swing.JFrame();

To avoid this you can use import statements right above the class declaration line, for example:

import javax.swing.JFrame;
import javax.swing.JButton;

class Calculator{
  JButton myButton = new JButton();
  JFrame myFrame = new JFrame();
}

These import statements allow you to use short class names like JFrame or JButton, and the Java compiler will know where to find them. Please note, that nothing is actually imported into your program: it's just a name resolution mechanism that helps the compiler to find classes and make your program more readable. If your need to use several classes from the same package, you do not have to list each of them in the import statement, just use the wild card. In the following example the asterisk (*) makes all classes from the package javax.swing visible to your program:

import javax.swing.*;

Still, it's better to use separate import statements, so you can see clearly which classes are imported from a particular package.

When programmers work on large projects that have lots of classes, they usually organize them in different packages. For example, one package can have all classes that display graphical windows, while another can contain data access classes.

Let's create a new project called PingPong in the Eclipse IDE. This project will have classes in two packages: screens and engine. Now create a new class PingPongTable and enter the word screens in the field Package:  

Press the button Finish and Eclipse will generate the code that will include the line with the package name.

package screens;

public class PingPongTable {

public static void main(String[] args) {
}
}

By the way, if your class includes the line with the keyword package, you are not allowed to write anything but the program comments above this line.

Since each package is stored in a different folder on a disk, Eclipse creates the folder called screens and puts the file PinPongTable.java there. Check it out - there should be a folder c:\eclipse\workspace\PingPong\screens on your disk with files PingPongTable.java and PingPongTable.class.

Now create another class called PingPongEngine and enter the word engine as the package name. The PingPong project has two packages now:

Since our two classes are located in two different packages (and folders), the class PingPongTable won't see the class PingPongEngine unless you add the appropriate import statement.

package screens;

import engine.PingPongEngine;

public class PingPongTable {

public static void main(String[] args) {
  PingPongEngine gameEngine = new
      PingPongEngine();
}
}

Java packages not only help better organize your classes, but also can be used to hide their classes from the "foreigners" living in other packages. In Java you can use public, private and protected keywords to specify the access level to a particular method or a class. But if you do not use any of these keywords in the method or class declaration, you'll be able to access them only from the classes located in the same package. We've discussed access levels briefly in Lesson 3 of this series.

Page 1 of 3   next page »