Java packages
Upcoming SlideShare
Loading in...5
×
 

Java packages

on

  • 290 views

Packages in JAVA

Packages in JAVA

Statistics

Views

Total Views
290
Views on SlideShare
290
Embed Views
0

Actions

Likes
0
Downloads
17
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Java packages Java packages Presentation Transcript

  • 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 Vectorclass 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:worldjavac 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 fullyqualified 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:worldHelloWorld.java to C:myclassesworldHelloWorld.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 name) { this.name = name; }}
  • If we store the package world under C: as before, the HelloMoon.java would be c:worldmoonHelloMoon.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 useworld.moon.HelloMoon as its fullyqualified 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.0libjsdk.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/cs368horwitz/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.