Java packages

ishonp98 2,133 views 66 slides Nov 30, 2013
Slide 1
Slide 1 of 66
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29
Slide 30
30
Slide 31
31
Slide 32
32
Slide 33
33
Slide 34
34
Slide 35
35
Slide 36
36
Slide 37
37
Slide 38
38
Slide 39
39
Slide 40
40
Slide 41
41
Slide 42
42
Slide 43
43
Slide 44
44
Slide 45
45
Slide 46
46
Slide 47
47
Slide 48
48
Slide 49
49
Slide 50
50
Slide 51
51
Slide 52
52
Slide 53
53
Slide 54
54
Slide 55
55
Slide 56
56
Slide 57
57
Slide 58
58
Slide 59
59
Slide 60
60
Slide 61
61
Slide 62
62
Slide 63
63
Slide 64
64
Slide 65
65
Slide 66
66

About This Presentation

Packages in JAVA


Slide Content

Java Packages

Packages are used in Java in-order to prevent naming conflicts, to control access, to make searching/locating and usage of classes, interfaces, enumerations and annotations easier etc.

A Package can be defined as a grouping of related types(classes, interfaces, enumerations and annotations ) providing access protection and name space management.

Programmers can define their own packages to bundle group of classes/interfaces etc. It is a good practice to group related classes implemented by you so that a programmers can easily determine that the classes, interfaces, enumerations, annotations are related.

Since the package creates a new namespace there won't be any name conflicts with names in other packages. Using packages, it is easier to provide access control and it is also easier to locate the related classed.

Overview Every class is part of some  package . All classes in a file are part of the same package. You can specify the package using a  package declaration : package  name  ; as the first (non-comment) line in the file .

Multiple files can specify the same package name. If no package is specified, the classes in the file go into a special unnamed package (the same unnamed package for all files). If package  name  is specified, the file must be in a subdirectory called  name  (i.e., the directory name must match the package name). You can access public classes in another (named) package using: package- name.class -name You can access the public fields and methods of such classes using: package- name.class - name.field -or-method-name

You can avoid having to include the  package-name  using: import  package-name .*; Or import  package- name.class -name ; at the beginning of the file (after the package declaration). The former imports all of the classes in the package, and the second imports just the named class. You must still use: class-name to access the classes in the packages, and class- name.field -or-method-name to access the fields and methods of the class; the only thing you can leave off is the package name.

Many 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.

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 " Vector ", its name would crash with the  Vector class from JDK. However, this never happens because JDK use  java.util  as a package name for the Vector class ( java.util.Vector ).

So our Vector class can be named as "Vector" or we can put it into another package like  com.mycompany.Vector  without fighting with anyone. The benefits of using package reflect the ease of maintenance, organization, and increase collaboration among developers. Understanding the concept of package will also help us manage and use files stored in jar files in more efficient ways.

How to create a package Suppose we have a file called  HelloWorld.java , and we want to put this file in a package  world . First thing we have to do is to specify the keyword  package  with the name of the package we want to use ( world  in our case) on top of our source file, before the code that defines the real classes in the package, as shown in our HelloWorld class below:

// only comment can be here package world; public class HelloWorld { public static void main(String[] args ) { System.out.println ("Hello World"); } }

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  world  package, which requires only one directory. So, we create a directory  world  and put our HelloWorld.java into it.

Setting up the CLASSPATH

we put the package  world  under C : So we just set our  CLASSPATH   as: set CLASSPATH=.;C:\; We set the  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 .

If you do the following: C:\world\javac HelloWorld.java If you try to run this  HelloWorld  using  java HelloWorld , you will get the following error :

C:\world>java HelloWorld Exception in thread "main" java.lang.NoClassDefFoundError : HelloWorld (wrong name: world/ HelloWorld ) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass (ClassLoader.java:442) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:101) at java.net.URLClassLoader.defineClass (URLClassLoader.java:248) at java.net.URLClassLoader.access$1(URLClassLoader.java:216) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged (Native Method) at java.net.URLClassLoader.findClass (URLClassLoader.java:191) at java.lang.ClassLoader.loadClass (ClassLoader.java:290) at sun.misc.Launcher$AppClassLoader.loadClass (Launcher.java:286) at java.lang.ClassLoader.loadClass (ClassLoader.java:247)

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 ) .

C:\world>java world.HelloWorld C:\world>Hello World Note:  fully-qualified class name  is the name of the java class that includes its package name

To make this example more understandable, let's put the  HelloWorld  class along with its package ( world ) be under  C:\myclasses  directory instead. 

We just changed the location of the package from C:\world\HelloWorld.java to C:\myclasses\world\HelloWorld.java. Our  CLASSPATH  then needs to be changed to point to the new location of the package  world  accordingly . set CLASSPATH=.; C:\myclasses;

Thus, Java will look for java classes from the current directory and  C:\myclasses  directory instead.

Someone may ask "Do we have to run the  HelloWorld  at the directory that we store its class file everytime ?". The answer is NO. We can run the  HelloWorld  from anywhere as long as we still include the package  world  in the  CLASSPATH . For example,

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

Subpackage (package inside another package) Assume we have another file called  HelloMoon.java . We want to store it in a subpackage   "moon" , which stays inside package  world . The  HelloMoon  class should look something like this:

package world.moon ; public class HelloMoon { private String name = "rabbit"; public getName () { return name; } public setName (String n ame) { this.name = name; } }

If we store the package  world  under C: as before, the  HelloMoon.java  would be  c :\world\moon\HelloMoon.java  

Although we add a subpackage under package world, we still don't have to change anything in our  CLASSPATH . However, when we want to reference to the  HelloMoon  class, we have to use world.moon.HelloMoon  as its fully-qualified class name.

How to use package There are 2 ways in order to use the public classes stored in package. 

1. Declare the fully-qualified class name. For example, ... world.HelloWorld helloWorld = new world.HelloWorld (); world.moon.HelloMoon helloMoon = new world.moon.HelloMoon (); String name = helloMoon.getName (); ...

2) Use an " 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 be

... 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 ...

Note 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  world , we can use only the  HelloWorld  class, but not the  HelloMoon  class.

Using classes stored in jar file Jar 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 command  jar - tvf fileName.jar 

there is a class called  javax.servlet.http.Cookie . We can call this class by 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  CLASSPATH  as well . set CLASSPATH=.;D:\JSDK2.0\lib\jsdk.jar;

Note that if the package is stored inside a jar file, we have to include the jar file with its extension (.jar) in the  CLASSPATH . However, if the package is a plain directory, we just put the name of directory into the  CLASSPATH . 

Using Packages

Using packages In a Java source file, the package that this file's class or classes belong to is specified with the  package   keyword. This keyword is usually the first keyword in the source file . package java.awt.event

To use a package's classes inside a Java source file, it is convenient to import the classes from the package with an  import  declaration. The following declaration import java.awt.event .*; imports all classes from the  java.awt.event  package, while the next declaration

import java.awt.event.ActionEvent ; imports only the  ActionEvent  class from the package. After either of these import declarations, the  ActionEvent  class can be referenced using its simple class name : ActionEvent myEvent = new ActionEvent ();

Classes can also be used directly without an import declaration by using the fully qualified name of the class. For example , java. awt . event . ActionEvent myEvent = new java. awt . event . ActionEvent (); does not require a preceding import declaration.

Note that if you do not use a package declaration, your class ends up in an unnamed package.Classes in an unnamed package cannot be imported from classes in any other package.

Package access protection Classes within a package can access classes and members declared with  default access  and class members declared with the  protected  access modifier. Default access is enforced when neither the  public ,  protected  nor  private  access modifier is specified in the declaration.

By contrast, classes in other packages cannot access classes and members declared with default access. Class members declared as protected can be accessed from the classes in the same package as well as classes in other packages that are subclasses of the declaring class.

Creation of JAR files JAR Files are created with the jar command-line utility. The command jar cf myPackage.jar *.class compresses all .class files into the JAR file  myPackage.jar . The ' c ' option on the command line tells the jar command to "create new archive." The ' f ' option tells it to create a file. The file's name comes next before the contents of the JAR file.

How the Java Compiler Finds Files When you compile a file that uses a class (or interface) that is not defined in the same file, the Java compiler uses the name of the class the names of imported packages (if any) the name of the current package

to try to locate the class definition. For example, assume that you are working in directory Javadir , which contains one file named Test.java: import ListPkg.*; public class Test { List L; ... }

Since List is not defined in Test.Java , and since there is no file List.java in the current directory, the compiler will look for List.java in the ListPkg subdirectory (since Test.java imports the ListPkg package).

Now suppose that the ListPkg subdirectory contains two files: List.java and ListNode.java, both part of the ListPkg package. Also assume that List.java uses the ListNode class defined in ListNode.java. If you try to compile just List.java in the ListPkg subdirectory, you will get an error, because the compiler will try to find the file ListNode.java in a " ListPkg " subdirectory of the current directory, rather than looking in the current directory itself.

There are (at least) three ways to solve this problem: Always compile a package from the  parent  directory. For example, compile List.java from Javadir , rather than from Javadir / ListPkg ; in the Javadir directory, type: javac ListPkg /List.java

Always compile  all  files in a package at the same time; for example, in the directory Javadir / ListPkg type: javac *.java Make a circular link from the package subdirectory to itself; for example, in the directory Javadir / ListPkg type: ln -s . ListPkg

The CLASSPATH Environment Variable To use a package that is not in a subdirectory of the current directory (i.e., the directory in which you invoke javac ), you must set the environment variable CLASSPATH to tell the java compiler where to look.

For example, if there were a List package in  /p/course/cs368-horwitz/public/ ListPkg , you would set CLASSPATH like this: setenv CLASSPATH .:/p/course/cs368-horwitz/public

Including the dot and the colon before the directory tells the compiler also to look in the directory in which the compile is being done. Note that you should set the CLASSPATH variable to the  parent  of the " ListPkg " subdirectory, not to the ListPkg subdirectory itself.