LAB 5- Packages

Goal

Practice with java packages; note that use of packages is required from project 2.
Take your project1 Moogle

• use packages for it following SUN conventions(your company is UNM)
• compile from command line, isolating source and classes
• make a jar file
• run your application from jar file

Why use packages?

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

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

SUN convention for packages

• Names representing packages should be in all lower case.
• By convention a company uses its reversed Internet domain name in its package names. The sample company whose Internet domain name is hobnob.com would precede all its package names with com.hobnob. Each component of the package name corresponds to a subdirectory.

Importing packages

Once you have a package, you will want to import classes and/or interfaces from that package to your program, so it can use those classes and/or interfaces. One way to accomplish that task is to supply the fully qualified package name (the package name and all subpackage names) in each place where the reference type name (the class or interface name) appears.Fortunately, Java supplies the import directive to import a package's public reference type name(s), so you do not have to enter fully qualified package name prefixes. An import directive consists of the import keyword immediately followed by an identifier that names a package, packageName. An optional list of subpackageName identifiers follows to identify the appropriate subpackage (if necessary). The directive concludes with either a referencetypeName identifier that identifies a specific class or interface from the package, or an asterisk (*) character. If referencetypeName appears, the directive is a single-type import directive. If an asterisk character appears, the directive is a type-on-demand import directive.

Compiling with javac

Usually try to compile everything, just to make sure you'll get the most recent version of all classes. There are some non-obvious dependencies in Java, such as constants from one class being embedded in another. There are two ways you could compile everything. Either specify it explicitly:
• c:\java> javac -d . com\mycompanypackage\*.java org\mypersonalpackage\util\*.java
• or create a list of files and pass that to javac:
  
  c:\java> dir /s /b *.java > srcfiles.txt
  
  c:\java> javac -d . @srcfiles.txt
  
  
Note that you compile from the root directory, and you specify -d . to tell the compiler to put the classes in a package structure starting at the root too. Some people don't like keeping class and source files together - in that case, you could use -d classes, although you need to create the classes directory first.

Running your code with java

Many people "accidentally" end up with their classes in the right place, etc, just by luck, but then run into errors like: java.lang.NoClassDefFoundError: MyCompanyApp (wrong name: com/mycompanypackage/MyCompanyApp. It happens if you try to run your code using something like this:

c:\java\com\mycompanypackage> java MyCompanyApp

Here's how to avoid it: Stay in your "root" directory, eg c:\java Always use the fully qualified classname. So, for example:

c:\java> java com.mycompanypackage.MyCompanyApp

The JVM knows to find that class file in the directory com\mycompanypackage (note, this is a VM-specific convention, it's just that almost all VMs use it - there's nothing in the language specification to say that packages have to be stored that way; the VM just has to know how to find and load a class), but there's something in the class file which says what its fully qualified name is - and the VM uses that to check that the class its been asked to load is actually the one it's found.

Links

• How to use a jar file
• Make a jar file