The Development Environment

Once you have installed the Java 2 SDK, you can start creating Java source code and compiling it. Java is like any other high-level programming language, in that you write the source code in an English-like form. The source code then has to be converted into a form that the machine can understand before it can be executed. To perform this conversion for a normal language, the code is usually either compiled (converted once and stored as machine code) or interpreted (converted and executed at run time).

Java combines these two approaches. The source code has to be compiled with a Java compiler, such as javac , before it can be used. This is a conventional compilation. However, the output that javac produces is not machine-specific code, but instead is bytecode, a system-independent format.

In order to execute, the compiled code has to be processed by an interpreter, which is part of the Java execution environment known as the JVM. The JVM is a run-time platform, providing a number of built-in system services, such as thread support, memory management and I/O, in addition to the interpreter.

Class Consciousness

Java is an object-oriented language, meaning that a program is composed of a number of object classes, each containing data and methods. One result of this is that, although a program may consist of just a single class, when you have compiled it into byte code, only a small proportion of the code that gets executed is likely to be in the resulting class file. The rest of the function will be in other classes that the main program references. The JVM uses dynamic linking to load these classes as they are needed. As an example, consider the simple applet contained in the following Java source file:

import java.awt.BorderLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import jamjar.examples.Button;
public class PointlessButton extends java.applet.Applet
implements java.awt.event.ActionListener
Button donowt = new Button(“Do Nothing”);
int count = 0;
* The button was clicked.
public void actionPerformed(java.awt.event.ActionEvent e)
donowt.setLabel(“Did Nothing ” + ++count + ” time” + (count == 1 ? “” : “s”));
public void init()
setLayout(new BorderLayout());
this.add(“Center”, donowt);

If the file was placed, say, in the C:\itso\ch02 directory, then the following Java source file,, should be placed in the C:\itso\ch02\jamjar\examples directory:

package jamjar.examples;
import java.awt.Color;
import java.awt.event.MouseEvent;
import java.awt.event.MouseListener;
* This class was generated by a SmartGuide.

public class Button extends java.awt.Button implements MouseListener
* @param title java.lang.String
public Button(String title)
* Set the color of the button to red when the mouse enters
public void mouseEntered(MouseEvent m)
* Reset the color of the button to white when the mouse exits
public void mouseExited(MouseEvent m)
* Three do nothing methods.
* Needed to implement the MouseListener interface
public void mouseClicked(MouseEvent e) {}
public void mousePressed(MouseEvent e) {}
public void mouseReleased(MouseEvent e) {}

The first listing, is an applet that simply places a button on the Web page. Instead of using the standard AWT Button class, it uses a class of our own, also called Button, but available in a locally-written package. This works like a normal button, except that it changes color when you move the mouse pointer over it and registers how many times you clicked on it.

From the directory C:\itso\ch02, you should compile these files, by issuing the following command:

Next, we show you the listing of an HTML file that includes two copies of the PointlessButton applet in the Web page:


<TITLE>Pointless Button</TITLE>
<CENTER><H2>Pointless Button</H2>
<APPLET Code=”PointlessButton.class” Width=200 Height=50>
<H4>This area contains a Java applet, but your browser is not Java-enabled</H4>
<APPLET Code=”PointlessButton.class” Width=200 Height=50>
<H4>This area contains a Java applet, but your browser is not Java-enabled</H4>

The HTML file above is saved in the same directory where the Java class file PointlessButton.class resides.

You can load the PointlessButton.html file in your Web browser by pointing your browser to the URL where the HTML file resides.


fig: Running the pointlessButton Applet

The total size of the bytecode for this example is only 2 KB. However, the two classes cause a lot of other code to be dynamically installed, either as a result of inheritance (defined by the extends keyword in the class definition) or by instantiation (when a class creates an instance of another class with the new keyword). the hierarchy of classes that could potentially be loaded to run our simple applet. Notice that this is a simplified view, because it does not consider classes that may be invoked by classes above the lowest level of the hierarchy:


Fig: Classes Loaded for the PointlessButton Applet

This diagram illustrates a number of things about Java classes:
1. The classes are arranged in packages, which are collections of related classes. The language defines a large number of these, which have to be implemented by every JVM implementation. You can add your own class packages by defining new classes that inherit from one of the basic classes. In our example, all but two of the classes are provided as standard. Normally, Java class loaders impose a direct relationship between a package name and the location of the directory in which it expects to find the class files for the package. So, in our example, the classes contained in the jamjar.examples package will be found in directory ${codeBase}/jamjar/examples (codeBase is the base directory on the server from which the applet is loaded, specified in the <APPLET> tag).

2. Classes are defined as extending existing classes. This means that they can inherit the properties (variables and methods) of the higher (or super) class. They can also selectively override the properties of the super class. They also add new properties of their own.

3. Java identifies classes using the fully-qualified class name, that is, the combination of the package name and the class name. This allows you to have duplicated class names, such as our two Button classes. If two classes in different packages do have duplicate names, the programmer must take care to use the right one. Two things that help with this are:
• Importing classes by name, instead of importing the whole package
• Placing the desired classes at the start of the class path

Access to Classes, Fields and Methods

Java provides mechanisms for limiting access to classes, fields and methods. A class or interface may be declared public , in which case it may be accessed, using a qualified name, by any Java code that can access the package in which it is declared. A class or interface that is not declared public may be accessed only from the package in which it is declared. A field, method, or constructor of a class may be declared using at most one of the public , private , or protected keywords:
• A public member may be accessed by any Java code.
• A private member may be accessed only from within the class that contains its declaration.
• A protected member of an object may be accessed only by the code responsible for the implementation of that object. To be precise, a protected member may be accessed from anywhere in the package in which it is declared and, in addition, it may be accessed from within any declaration of a subclass of the class type that contains its declaration.
• A member that is not declared public, protected, or private is said to have default access and may be accessed from, and only from, anywhere in the package in which it is declared.

Notice that every field or method of an interface must be public. Every member of a public interface is implicitly public, whether or not the keyword public appears in its declaration. If an interface is not public, then every one of its fields and methods must be explicitly declared public.

There are security implications when using these keywords to limit access to classes, fields and methods.

Visual Application Builders and Java Beans

Java is unusual in the breadth of function that its built-in class frameworks provide; however, for a project of any complexity you are likely to employ graphical tools, such as a visual application builder (VAB) to link together predefined components, thereby reducing the code you have to write to the core logic of the application. Examples of VABs include IBM VisualAge for Java, Lotus BeanMachine, NetObjects BeanBuilder and Sun Microsystems’ JavaBeans Development Kit (BDK).

A component in this context is a package of Java classes that perform a given function. The JavaBeans definition describes a standard for components, known as beans . Basically a bean is a package of code containing both development and run-time components that:
• Allows a builder tool to analyze how it works ( introspection )
• Allows a builder tool to customize its appearance and behavior
• Supports events , a simple communication metaphor than can be used to connect beans
• Supports properties , or settable attributes, used both when developing an application and programmatically when the application is running
• Supports persistence , so that a bean can be customized in an application builder and then have its customized state saved away and reloaded later
• Provides interfaces to other component architectures, such as ActiveX and LiveConnect

From this list you can infer that, although a bean is mostly made up of Java classes, it can also include other files, containing persistent information and other resources such as graphical elements, etc. These elements are all packed (or pickled ) together in a Java Archive (JAR) file.

From a security viewpoint, VABs and beans do not affect the underlying strengths and weaknesses of Java. However, they may add more uncertainty, in that your application now includes sizeable chunks of code that you did not directly write. Their ability to provide interfaces to other component architectures may also cause problems.

Java 2 SDK Security Tools

The Java 2 development environment also contains a set of tools for managing the security features of the new Java platform:

• The Policy Tool creates and modifies the external policy configuration files that define your installation’s security policy.
• The jar command line utility is used to create Java archives.
• The keytool utility creates key pairs and self-signed X.509 V1 certificates, and manages keystores. Keys and certificates are used to digitally sign your applications and applets. A keystore is a protected database that holds keys and certificates.
• The jarsigner command line tool signs JAR files, and verifies the signature(s) of signed JAR files. It accesses the keystore when it needs to find a key to sign a JAR file.

Notice that keytool and jarsigner replace javakey , which in Java Development Kit (JDK) 1.1 was the command line tool used to apply a digital signature to a JAR file.