Lab 5: Platforms, Packages, and Archives

Glossary

Abstract Platform

The term platform (also called a physical platform or a runtime environment) is commonly used to collectively refer to a computer together with its operating system. An abstract platform (also called a virtual platform) is a document that specifies the services provided by a platform without describing a physical platform that provides these services. This is done by describing the services purely in terms of the interfaces they present to application programmers (APIs). An application developed using an abstract platform can run on any physical platform implementation:

There are currently three abstract Java platforms: the Java 2 Enterprise Edition (J2EE), the Java 2 Standard Edition (J2SE), and the Java 2 Micro Edition (J2ME). Generally speaking, J2EE describes an abstract server platform, J2SE describes an abstract client platform, and J2ME describes an abstract PDA (Personal Digital Assistant) platform.

Application Programmer Interface (API)

An API describes a set of related services provided by an abstract platform. Typically, these services might be described by a package of class specifications and interfaces. Common APIs include:

presentation and control
concurrency and synchronization
media access and control
containers
persistence
network access Package

A package is a named collection of classes and sub-packages. A package defines a namespace. Thus, a program might consist of two classes named Star, as long as they were contained in two different packages.

The J2SE organizes its class library into three packages:

java   (core packages)
javax (Java extensions)
org.omg (Object Management Group extensions) The java package contains about 60 sub-packages and sub-sub-packages: java
java.applet
java.awt
java.awt.event
java.util
java.io
java.lang
java.lang.reflect
java.math
java.net
etc. These packages, together with the classes they contain, are documented on the web at: http://java.sun.com/j2se/1.3/docs/api/index.html Runtime Environment

A runtime environment (also called a physical platform) implements an abstract platform specification. A runtime environment is a combination of hardware and software. The Java 2 Runtime Environment (J2RE) is Sun's implementation of the J2SE abstract platform. The J2RE contains Java's pre-defined classes and the Java virtual machine.

Software Development Kit

A software development kit (SDK) is a suite of libraries and tools (compilers, etc.) for developing applications. The Java 2 SDK (J2SDK) is Sun's SDK for developing applications that will run on the J2SE abstract platform. It includes the Java 2 Runtime Environment as well a javac, javadoc, applet viewer, etc. The J2SDK is also called the Java Development Kit (JDK).

Creating Packages

We have seen that the Java platform specification organizes its class library into packages and sub-packages. Programmers can organize their class libraries in the same way. For example, assume the files Apple.java, Banana.java, and Peach.java are to contain the definitions of the Java classes Apple, Banana, and Peach, respectively. Instances of these classes will represent virtual trees, so we want to place them in a special package named tree.

If we have decided to keep all of our packages in a directory called c:\jlab, then we create a subdirectory of c:\jlab called tree, and place all three Java files in this directory. At the top of each file place the Java statement:
 
 

package tree; Assume three different files also called Apple.java, Banana.java, and Peach.java also contain the definitions of Java classes named Apple, Banana, and Peach, respectively, only instances of these classes will represent virtual fruits, so we want to place them in a package named fruit that will be placed inside a parent package named food. The food package will also contain packages named meat and veggies. In this case we create a subdirectory of c:\jlab called food. We create three subdirectories of food called meat, fruit, and veggies. Place the Apple.java, Banana.java, and Peach.java files in c:\jlab\food\fruit. At the top of each file place the statement: package food.fruit; Here are the complete path names of both Apple.java files: c:\jlab\tree\Apple.java
c:\jlab\food\fruit\Apple.java Here is the general layout of the c:\jlab\tree\Apple.java file: // Apple.java
package tree;
public class Apple {
   // tree-related methods & attributes go here
} and here is the general layout of the c:\jlab\food\fruit\Apple.java file: // Apple.java
package food.fruit;
public class Apple {
   // fruit-related methods & attributes go here
} A package diagram represents packages using labeled folder icons and classes as labeled boxes. We can use a package diagram to quickly summarize the structure of our class library:

We're not done! Before programmers can use these files, the Java compiler and virtual machine must know where to look for them. Starting with Java version 1.2, the Windows implementations of the compiler and virtual machine consult the PATH variable in the DOS command shell environment. Use the Environment tab of the System control panel to append the directories c:\jlab\tree and c:\jlab\food to the PATH variable.

A class in another package can now refer to virtual trees and fruits by qualifying names with

tree.Apple a = new tree.Apple();
food.fruit.Apple a2 = new food.fruit.Apple(); Of course we can add an import statement to our program. For example, if we import the food.fruit package: import food.fruit.*; then we can create fruits without qualification: tree.Apple a = new tree.Apple();
Apple a2 = new Apple(); // creates a fruit Of course if we import the tree package as well: import food.fruit.*;
import tree.*; then the compiler complains of ambiguities: Ambiguous class: food.fruit.Apple and tree.Apple The default Package

When a Java file doesn't declare which package it belongs to, then we say that it belongs to the default package.

Package Visibility

Every field and method in a class declaration declares its visibility: public (visible to clients, extensions, and local methods ), protected (visible to extensions and local methods), or private (visible to local methods only). But what happens if a programmer forgets to declare the visibility of a field or method? The default visibility of a field or method is package visibility: visible to local methods and all clients and extensions that are in the same package.

Hidden Classes

Suppose the file c:\jlab\tree\Apple.java also contains the declaration of a class called Redwood:

// from Apple.java
class Redwood {
   // redwood tree methods & attributes go here
} Of course the Redwood class is also a member of the tree package, but without the modifier "public" in front of the declaration, the Redwood class will only have package visibility. It can't be used by clients in other packages. We can partially remedy this situation by declaring the Redwood class to be public: public class Redwood { ... } but most compilers will complain that these classes should be put in their own files. This is another disadvantages of putting all of your classes in one file.

Problem

Create a package called molecule that contains classes named Water, Sugar, Carbon Dioxide, and SulfuricAcid, and a sub-package named molecule.atom. The atom sub-package contains classes named Carbon, Hydrogen, Oxygen, and Sulfur. Each class in the molecule package should re-define the toString() method to print the numbers and types of atoms that constitute the molecule. For example, molecule.Sugar.toString() should return the string:

"Sugar: 6 Carbon, 12 Hydrogen, 6 Oxygen" Each class in the atom package should redefine the toString() method to the atomic number and mass of the atom, together with its symbol. For example, molecule.atom.Sulfur.toString() returns the string: "Sulfur: symbol = S, num = 16, weight = 32.066" (See http://www.cs.ubc.ca/cgi-bin/nph-pertab/tab/periodic-table for a table of the elements.)

Create a class called ChemTest belonging to the default package. ChemTest.main() creates and prints instances of each molecule and atom, but does not contain any import statements.

Archives

A file compression program can reduce the size of a file. For example, a compression program might replace the text:

"it's a big big big big big big world" with the text: "it's a big^6 world" A decompression program performs the reverse substitution, thus restoring the file to its original form.

An archive is a single file that contains several compressed files appended together. Programs like zip and tar can be used to create archives and to extract and decompress the files in an archive. The Java SDK comes with an archive creating/extracting tool called jar. The Java on-line tutorial has a chapter on using the jar tool located at:

http://java.sun.com/docs/books/tutorial/jar/basics/index.html As an example, a directory called jlab\jartest contains .java and .class files for modeling banking transactions: Directory of D:\jlab\JarTest
10/08/00 01:28p <DIR> .
10/08/00 01:28p <DIR> ..
10/08/00 01:06p 578 Account.class
10/08/00 01:05p 308 Account.java
10/08/00 01:08p 364 Address.class
10/08/00 01:07p 95 Address.java
10/08/00 01:08p 436 ATM.class
10/08/00 01:04p 329 ATM.java
110/08/00 01:06p 507 Customer.class
10/08/00 01:06p 593 Customer.java
10/08/00 01:08p 511 Person.class
10/08/00 01:07p 205 Person.java
10/08/00 01:08p 358 Phone.class
10/08/00 01:07p 87 Phone.java
10/08/00 01:06p 698 Transaction.class
10/08/00 01:04p 370 Transaction.java Creating

The cvf option of the jar tool is used to verbosely create an archive file:

D:\jlab\JarTest>jar cvf bank.jar *
added manifest
adding: Account.class (in=578) (out=399) (deflated 30%)
adding: Account.java (in=308) (out=190) (deflated 38%)
adding: Address.class (in=364) (out=265) (deflated 27%)
adding: Address.java (in=95) (out=80) (deflated 15%)
adding: ATM.class (in=436) (out=319) (deflated 26%)
adding: ATM.java (in=329) (out=185) (deflated 43%)
adding: Customer.class (in=507) (out=349) (deflated 31%)
adding: Customer.java (in=593) (out=229) (deflated 61%)
adding: Person.class (in=511) (out=339) (deflated 33%)
adding: Person.java (in=205) (out=142) (deflated 30%)
adding: Phone.class (in=358) (out=260) (deflated 27%)
adding: Phone.java (in=87) (out=78) (deflated 10%)
adding: Transaction.class (in=698) (out=438) (deflated 37%)
adding: Transaction.java (in=370) (out=202) (deflated 45%) Viewing

The tf option is used to display the contents of an archive:

D:\jlab\JarTest>jar tf bank.jar
META-INF/
META-INF/MANIFEST.MF
Account.class
Account.java
Address.class
Address.java
ATM.class
ATM.java
Customer.class
Customer.java
Person.class
Person.java
Phone.class
Phone.java
Transaction.class
Transaction.java Extracting

The xf option is used to extract and decompress an archive:

jar xf bank.jar Running

The java virtual machine can execute an archive if the archives manifest (i.e. table of contents) contains a line specifying which class in the archive is the main class. In our banking example ATM is the main class.

Create a file called mainclass.txt containing the single line:

Main-Class: ATM Make sure this line is terminated by a newline character (i.e., a carriage return).

Create a new jar file with the contents of mainclass.txt added to the manifest:

jar cmf mainclass.txt bank.jar *.java *.class In JDK 1.2 and later, the java command can accept a jar file as input: D:\jlab\JarTest>java -jar bank.jar
creating a new transaction.
creating a new person.
creating a new account.
creating a new customer.
creating a new address.
creating a new phone. Problem

Create an archive called chem.jar containing all of the ChemTest.java, ChemTest.class, and all of the files in the molecule and atom packages. Compare the size of the archive with the total sizes of all of the decompressed files it contains. How percentage of size reduction was acheived?