Aug 26, 2011

Packages

Introduction
      Java provides a powerful means of grouping related classes and interfaces together in a single unit: packages.Packages are groups of related classes and interfaces. Packages provide a convenient mechanism for managing a large group of classes and interfaces while avoiding potential naming conflicts.

Packages are useful for several broad reasons:
          They allow us to organize your classes into units. Just as we have folders or directories on    your hard disk to organize your files and applications, packages allow us to organize your    classes into groups so that we only use what we need for each program.
          They reduce problems with conflicts in names. As the number of Java classes grows, so    does the likelihood that we'll use the same class name as someone else, opening up the    possibility of naming clashes and errors if you try to integrate groups of classes into a    single program. Packages allow you to "hide" classes so that conflicts can be avoided.
          They allow you to protect classes, variables, and methods in larger ways than on a  class-by-class basis, as you learned yesterday. we'll learn more about protections with    packages later today.
          They can be used to identify your classes. For example, if you implemented a set of    classes to perform some purpose, we could name a package of those classes with a    unique identifier that identifies you or your organization.   The Java API itself is implemented as a group of packages.

Creating packages
             Creating a Java Package is relatively simple but may seem a bit confusing for people who have not done it before. There are two fundamental requirements for a package to exist:
  • The package must contain one or more classes or interfaces. This implies that a package cannot be empty.
  • The classes or interfaces that are in the package must have their source files in the same directory structure as the name of the package.

Naming Packages
           With programmers worldwide writing classes and interfaces using the Java programming language, it is likely that many programmers will use the same name for different types. In fact, the previous example does just that: It defines a Rectangle class when there is already a Rectangle class in the java.awt package. Still, the compiler allows both classes to have the same name if they are in different packages. The fully qualified name of each Rectangle class includes the package name. That is, the fully qualified name of the Rectangle class in the graphics package is graphics. Rectangle, and the fully qualified name of the Rectangle class in the java.awt package is java.awt.Rectangle.
This works well unless two independent programmers use the same name for their packages.
What prevents this problem?
Convention.

Naming conventions
             Package names are written in all lower case to avoid conflict with the names of classes or interfaces.Companies use their reversed Internet domain name to begin their package names—for example, com.example.mypackage for a package named mypackage created by a programmer at example.com.
Name collisions that occur within a single company need to be handled by convention within that company, perhaps by including the region or the project name after the company name (for example, com.example.region.mypackage).
Packages in the Java language itself begin with java. or javax.
In some cases, the internet domain name may not be a valid package name. This can occur if the domain name contains a hyphen or other special character, if the package name begins with a digit or other character that is illegal to use as the beginning of a Java name, or if the package name contains a reserved Java keyword, such as "int". In this event, the suggested convention is to add an underscore.

Declaring package members
            The first thing to do when creating a package is to decide which classes and interfaces should belong to that package. Once you have decided that, you need to specify this by adding a package declaration to the source file of each class and interface that is a part of the package.
The declaration is simple, you use the package keyword followed by the package name. This declaration comes right at the top of the source file, before any import statements.

                    package com.mycompany.myproject;

                    import java.util.*;

                    class MyClass {

                     }

Managing source and class files
             One of the requirements for a package is that the source file should be contained in a directory structure that resembles the name of the package. This is simply creating a set of directories with the names given in the package name.
Take the package name and split it up according to where the periods (.) occur, for example, com.mycompany.myproject can easily be split up into three components, namely: com, mycompany and myproject. These will be the three directories that you create. The first directory will be the com directory and within this directory you will create a sub directory namely the mycompany directory and within that directory a sub directory, namely the myproject directory.
Finally, all the source files that are part of the package will go into the myproject directory.
It is typical in many java project to have the source code go into a src directory and when it is compiled, the resulting byte code goes into a classes directory. The package directories will therefore go into the src directory. As an example, consider a class named MyClass in the package named com.mycompany.myproject and all source code in the src directory. The following picture depicts this situation clearly:



Compiling the package
            At first it may seem like a nightmare trying to compile the package, especially having the resulting class files occur in the classes directory, but it can be achieved using a single command. You don't even need all the package directories under the classes directory since they will be created in the compilation.
To try this out, create a test directory and all the sub directories required:

Open your command prompt and type the following commands

             mkdir test
             mkdir test\src
             mkdir test\classes
             mkdir test\src\com
             mkdir test\src\com\mycompany
             mkdir test\src\com\mycompany\myproject

Now create the MyClass source file named MyClass.java in the test\src\com\mycompany\myproject directory.

                package com.mycompany.myproject;
                                                                               
                public class MyClass {
                                                                               
                 }

Change into the test directory and compile the package:

                cd test

                javac -d ./classes/ ./src/com/mycompany/myproject/*.java

If you take a look in the classes directory, you will find the exact same directory structure as in the src directory. You'll also find a MyClass.class file in the test\classes\com\mycompany\mypackage directory. This is good as it allows you to keep your source and class files separate and provides greater control over your files.



Using Packages
            Once you have created your package you may want to use it in your program or you may wish to use another programmer's package or the packages in the Java API. There are three ways of using the resources in a package; inline package member declarations, importing only the package member that you want and importing the entire package.

Inline member declarations
            In this approach you simply declare the package member you wish to use with its fully qualified package name. As an example, suppose you wish to use the Vector class in the java.util package. You can easily declare a vector using  java.util.Vector vector;
When you initialize the object by calling its constructor, you will again have to use the fully qualified package name.

                       class Test {
                        java.util.Vector vector;
  
                        Test() {
                        vector = new java.util.Vector();
                        }
                      }

Importing a single package member
             Using the inline declaration works well if you only use it a few times in your source code, but it can become a pain to type the fully qualified package name if you use it often. Instead you want to do this once and only once, and from then on, simply use the member's name wherever you need it.
This is easily achieved using an import statement in which the import keyword is followed by the fully qualified name of the member you wish to use. Consider the example given previously, but revised to use this method:

                     import java.util.Vector;
                     class Test {
                     Vector vector;
 
                     Test() {
                     vector = new Vector();
                   }
                 }

Importing an entire package
            It may be that you use a number of members from a package and end up with a large number of import statements. As an example consider the following:

                      import java.util.Vector;
                      import java.util.LinkedList;
                      import java.util.Hashtable
                      import java.util.Stack
                      import java.util.Set

                     class Test {
                        ...
                      }
This can become messy quite quickly, and you would like to get away from this. The answer is to simply import the entire package, again using the import statement but instead of declaring the member you use a wildcard symbol to indicate that everything should be imported. The wildcard symbol is an asterisk (*), using this method you can replace all the import statements of the previous example with simply one import statement.
                  
                     import java.util.*;

                     class Test {
                      ...
                      }

As you can see, this is much cleaner but it does have its limitations. If the package is very large and you import everything in the package, this will impact the performance of your program. You should consider carefully whether greater clarity in your code and ease of writing the code outweighs the addition of some overhead to the performance of your application.


0 comments :

Post a Comment