Showing posts with label Java Packages. Show all posts
Showing posts with label Java Packages. Show all posts

Sunday, 31 May 2015

Java Importing packages

We discuss this concept with reference to previous example. Given that packages exist and are a good mechanism for compartmentalizing diverse classes from each other, it is easy to see why all of the built in Java classes are stored in packages.

There are no core java classes in the unnamed default package; all of the standard classes are stored in some named package.

Since classes within packages must be fully qualified with their package name or names, it could become tedious to type the long dot-separated package path name for every class you want to use. For this reason, Java includes the import statement to bring certain classes, or entire package into visibility. Once imported, a class can be referred to directly, using only its name.

Note: The import statement is a convenience to the programmer and is not technically needed to write a complete Java program. If you are going to refer to a few dozen classes in your application, however, the import statement will save a lot of typing.

In Java source file, import statements occur immediately following the package statement. (if it exists) and before any class/interface definitions.

The geneal form of import statement:

import pkg1 [.pkg2] [.pkg3].[classname | *];

Note: 

1. The star form may increase compilation time. However, the star form has absolutely no effect on the run-time performance or size of your classes.

2. All of the standard Java classes included with Java are stored in a package called java. The basic language functionality is stored in a package inside of the java package called java.lang. Normally, you have to import every package or class that you want to use, but since Java is useless without much of the functionalities in java.lang, it is implicitly imported by the compiler for all programs. This is equivalent to the following line being at the top of all of your programs:

import java.lang.*;

3. If a class with the same name exists in two different packages that you import using the star form, the compiler will remain silent, unless you try to use one of the classes. In that case, you will get a compile-time error and have to explicitly name the class specifying its package.

4. Any place you use a class name, you can use its fully qualified name, which includes its full package hierarchy. When a package is imported, only those items within the package declared as public will be available to non-subclasses in the importing code.

Java Packages

If no package name is specified in any java file then the class is part of the unnamed package. This requires that every class must have a unique name to avoid collisions. After a while, without some way to manage the namespace, you could run out of convenient descriptive names for individual classes.

You also need some way to be assured that the name you choose for a class will be reasonably unique and not collide with class names chosen by other programmers.

Java provides a mechanism for partitioning the class name space into more manageable chunks. This mechanism is the package.

The package is both a naming and visibility control mechanism.
You can define classes inside a package that are not accessible by code outside that package.
You can also define class members that are only exposed to other members of the same package.
This allows your classes to have intimate knowledge of each other, but not expose that knowledge to the rest of the world.

Defining a package

To create a package, include a package command as the first statement in a Java source file. Any classes declared within that file will belong to the specified package. The package statement defines a name space in which classes are stored. If you omit the package statement, the class names are put into the default package, which has no name and is called un-named package.

This is the general form of package statement:

package pkg_name;

Java uses file system directories to store packages. Remember that case is significant, and directory name must match the package name exactly. More than one file can include the same package statement.

You can create a hierarchy of packages. To do so, simply separate each package name from the one above it by use of a period. The general form of a multi-leveled package statement is shown here:

package pkg_name1 [.pkg_name2] [.pkg_name3];


A package hierarchy must be reflected in the file system of your Java development system.

For example a package declared as:

package java.awt.image;

needs to be stored in java/awt/image, java\awt\image, or java:awt:image on your Unix, Windows, or Macintosh file system, respectively.

A global naming scheme has been proposed to use the reverse Internet domain names to uniquely identify packages.

For example the apache’s domain name is www.apache.org. So to store classes in package tomcat, preferably you should use the package hierarchy:

org.apache.tomcat

which would be unique.

A package hierarchy represents an organization of Java classes and interfaces. It does not represent the source code organization of the classes and interfaces. Each Java source file (also called compilation unit) can contain zero or more definitions of classes and interfaces, but the compiler provides a separate class file containing the Java byte code for each of them. A class or interface can indicate that its java byte code be placed in a particular package, using a package declaration.

At most one package statement can appear in a source file, and it must be the first statement in the unit.

Note that this scheme has two consequences. First, all classes and interfaces in a source file will be placed in the same package. Secondly, several source files can be used to specify the contents of a package.

Finding packages and CLASSPATH

As discussed, packages are mirrored by directories. This raises an important question. How does the Java run-time system know where to look for packages that you create?

There can be two approaches:

First, by default, the Java run-time system uses the current working directory as its starting point. Thus, if your package is in the current directory, or a subdirectory of the current directory, it will be found.

Second, you can specify a directory path or paths by setting the CLASSPATH environment variable. For example, consider the following package specification:

package mypack;

In order for a program to find mypack, one of the two things must be true. Either the program is executed from a directory immediately above mypack, or CLASSPATH must be set to include the path to mypack.

Jar File

If you are developing a complex system or using third party libraries then instead of creating a directory hierarchy for class files you can use .jar files by including them in the CLASSPATH.

The JVM searches for the packages and classes in .jar file as it does searches in the file system.
Instead of .jar file you can also use a .zip file created by any popular software like winzip, winrar etc. Jar files can be created using jar utility that is part of JDK. To include the current directory and all the sub-directories below it in a jar file give the following command:

jar -cf myjar.jar *

here, c stands for creating a new .jar file.

         f stands for name of the .jar file.

The above command will create myjar.jar file in the current folder.

Example:

package mypack;

public class MyProg

{ public static void main(String args[])

{ System.out.println("Yes, Its working!");

}

}

To compile the following program give following command:

C:\totest>javac -d . MyProg.java

Here -d is used to create a directory ‘mypack’ in the current folder and put the class file in this folder automatically. When we compile the program, ‘mypack’ directory is created in the current folder (which is assumed to be c:\totest).

We can run above program in following different ways:

1. Running from the current directory: 

Give the following command from the directory where the package directory is created i.e from folder c:\totest.

java mypack.MyProg

This is because, MyProg file is part of package mypack.

Output:

Yes, Its working!

2. Running using classpath:

Give the following command at the command prompt:

SET CLASSPATH = %CLASSPATH%;C:\totest;

Then give the following command from any directory/folder:

java mypack.MyProg

3. Running by specifying classpath as parameter

Give the following command:

 java –classpath c:\totest mypack.MyProg

4. Running using jar file: Go to C:\totest folder and give the following command:

 jar –cf myjar.jar mypack (or jar -cf myjar.jar mypack)

and then give the following command:

java -classpath c:\totest\myjar.jar mypack.MyProg

After creating the .jar file, you can also set the classpath as follows:

set classpath=%classpath%;c:\totest\myjar.jar

Note: you can use –d option to copy the class file in any desired folder. For example, use the following command to create folder ‘mypack’ in C:\myclasses:

javac –d C:\myclasses MyProg.java

This will create a folder mypack below myclassses, if not already present and put the MyProg.class file in it.