More Java Basics

By Dave Mark

Last month, we started exploring Java, Sun’s object-programming language that has exploded in popularity over the last year. As a reminder, Java is similar to C++, but with some very important differences. The Java syntax is just like C++, but without the pointer syntax. The Java environment that runs on your machine is multi-threaded, with a low-priority thread that does automatic garbage collection.

Your Java source code will reside in a file ending with the .java extension. Your Java source code will implement a class, or a series of classes. Depending on your development environment, you will compile the classes into a stream of Java byte-code, which will get stored in a .class file, in a series of .class files, in a .zip file, or, in some cases, in a double-clickable application file.

The .class file is designed to hold a single class. If you build a bunch of .class files, you could pay a severe penalty in wasted hard drive space. For example, my 1-gig hard drive has a minimal file size of 17K. If I build 100 .class files, each of which is filled with 100 bytes of byte-code, I’ll end up using 1700K of hard drive space to store 10,000 bytes of byte-code. Not very efficient, eh?

The solution to this problem is the .zip file. The .zip lets you combine a set of classes into a single file of byte-code. Since the .zip format is based on the .zip compression format from the PC universe, you can use a zip utility (like UnZip) to peruse the classes in a .zip file.

To run your byte code, you’ll need a byte-code interpreter. There are several options for doing this. Your development environment most likely came with some form of Java virtual machine. It might be called “javai”, “Applet Runner”, “Applet Viewer”, or something else. The point is, the virtual machine knows how to turn your generic Java byte-code into the equivalent machine code specific to your platform. There are Java virtual machines written specifically for the PowerMac, and Java virtual machines written for 680x0, x86, and Unix platforms as well. The first virtual machines came from Sun. Other vendors are writing their own. Check with your development environment for details on your virtual machine.

Java Reference Basics

Our first Java program this month demonstrates an important and potentially confusing difference between Java and C++. As stated earlier, Java doesn’t support pointers. When you create an object, the variable you associate with the object instance is known as a reference. This example should make this clear.

If you are using CodeWarrior or Caffeine, create a new project file using the appropriate Java stationery. I’m using the CodeWarrior droplet stationery, so my project was named reference.µ.

The CodeWarrior environment ships with a bunch of stationery, including one for Java applets and one for Java droplets. The Java applets stationery lets you create an applet designed to be launched from an HTML file. This is pretty standard stuff and will be supported by most every Java development environment you run into.

The droplet stationery is both cool and different. It lets you turn your Java code into a standalone application, complete with 4-byte creator code and its associated 'BNDL' resources. And if you drop a file or set of files onto the droplet, the names of the files get passed to main() via the argv parameter. I’ll present a small example of this later in the column.

Once your project file is set up, create a new source code file named reference.java and type this source code into the file:

public class reference
{
 public static void main( String argv[] )
 {
 String s1 = "Sample String";
 String s2 = "Sample String";
 String s3 = new String(s1); 

 if ( s1 == s2 )
 System.out.println( "s1 is the same object as s2" );
 else
 System.out.println("s1 is not the same object as s2");

 if ( s1 == s3 )
 System.out.println( "s1 is the same object as s3" );
 else
 System.out.println("s1 is not the same object as s3");
 }
}

Compile and run the program. Here’s the results you should see in your stdout window:

s1 is the same object as s2
s1 is not the same object as s3

Let’s take a walk through the source. These three lines declare references to String objects:

 String s1 = "Sample String";
 String s2 = "Sample String";
 String s3 = new String(s1); 

The first line creates a reference named s1 and also creates a new String object, initializing it with the literal “Sample String”. The second line also creates a reference, this one named s2. The question here is, was a new object created? The answer is no. The compiler checks to see if a literal with the value “Sample String” already exists. Since such a literal does exist, the compiler doesn’t bother creating a new one. It just creates the new object reference (s2) and makes it refer to the original literal. Since there is no way to modify a literal, this strategy is pretty sure-fire. Since pointers don’t exist in Java, the compiler has more freedom in allocating memory for objects.

The third line of the set uses new to force the allocation of a new String object. The String reference s1 is passed as a parameter to the String constructor. So we end up with three String references: s1 and s2 both refer to the same String object, and s3 points to a second String object.

To verify this theory, the first if-else statement uses the == operator to test if s1 is the same as s2. Note that this tests whether s1 and s2 refer to the same object. As proof, the result of the first if-else is:

s1 is the same object as s2

The second if-else compares s1 to s3. Since we used new to force the allocation of a new String object, it is no surprise that the second if-else produces this result:

s1 is not the same object as s3

Take a few minutes to review the String methods; you’ll find them in the API Documentation folder in the file java.lang.String.html. Pay specific attention to the compareTo(), equals(), and equalsIgnoreCase() methods.

Copying an Object

Before we move on to our second example, let’s talk about copying objects for a moment. I was reading through my pile of Java books when I noticed an interesting discrepancy. Several of the books specified that to duplicate an object, you should use the copy() method, inherited from java.lang.Object. Alternatively, some sources recommended that you use the clone() method, also inherited from java.lang.Object.

Being a curious son-of-a-gun, I wheeled over to Netscape and opened up java.lang.Object.html (in the folder API Documentation) to look for clone() and copy(). As it turns out, copy() isn’t there and clone() is there, but marked as protected and couldn’t be called from our main() class above.

So what the heck was going on here? After a few phone calls and emails to my Java buddies, I found out that copy() was dropped from the Java API between beta 1 and beta 2 of Java. I also found out that the clone() method was changed to protected and that a new interface (we’ll talk about Java interfaces in a future column) was created, called the cloneable interface. Basically, if you want your objects to be cloneable, they need to implement the cloneable interface. To learn more about this, check out the file CloneNotSupportedException.html and this URL: http://java.sun.com/JDK-beta2/changes.html

The point of all this isn’t to push the cloneable interface. I was just trying to save you from going through the head-banging exercise I just went through trying to figure out why copy() and clone() weren’t working as they were described in the books. But if you want to learn how to make your objects cloneable, well, go right ahead...

Figure 1: The Preferences dialog from the Hello droplet

A Quick Droplet

Our second example is a droplet, built using CodeWarrior. Basically, the droplet is an application that sends the embedded classes to the virtual machine. If any files are dropped on the droplet, their names are sent to main() in the argv parameter.

To create a droplet, create your project using the droplet stationery. Copy the resource file from the example “HelloWorld” droplet and edit it to change the creator signature and signature resource. Next, edit the project preferences to reflect the application’s file name, the name of your class, and your creator (Figure 1).

Here’s the droplet source code for the Hello droplet (note that the class is called HelloWorld but the droplet is called Hello):

public class HelloWorld
{
 public static void main(String argv[])
 {
 if (argv.length == 0 )
 System.out.println("You launched Hello " +
 "without dropping anything on it.");
 else
 {
 System.out.println("You launched Hello " +
 "dropping the following things:");

 for(int i = 0; i<argv.length; i++)
 System.out.println("Arg[" + 
 i + "]=" + argv[i]);
 }
 }
}

Basically, this code prints one message if the droplet is launched without any files dropped on it, or else prints the list of files dropped on the droplet.

Here’s the result of launching the Hello droplet without any files dropped on it:

You launched Hello without dropping anything on it.

Here’s the result when I dropped three files on the droplet:

You launched Hello dropping the following things:
Arg[0]=/Macintosh%20HD/Test%20Files/File1
Arg[1]=/Macintosh%20HD/Test%20Files/File2
Arg[2]=/Macintosh%20HD/Test%20Files/File3

Note that the %20 in the string represents ASCII character 32, which is the space character. 20 in hex is 32.

Our First Applet

Before we go, here’s a taste of things to come: our first official applet. As mentioned in last month’s column, a Java applet is a Java class that is derived from the class java.applet.Applet. The java.applet.Applet class is described in the file java.applet.Applet.html. Take a few minutes to look this page over.

Our first applet takes advantage of the packages java.awt.Graphics and java.awt.Font. Take a few minutes to look over the files java.awt.Graphics.html and java.awt.Font.html. In fact, it is probably a good idea to look through the files in the API Documentation just to get an idea of what is in there.

Our applet will consist of a single class, called hello, and a single method, called paint(). Our paint() overrides the standard paint() method that is part of the standard applet. The default paint() method does nothing. Ours will use a sequence of AWT (the Java equivalent to the Mac Toolbox) calls to draw the string “Hello, world!” in a pane or in a window (depending on the browser).

Here’s the source code:

import java.awt.Font;
import java.awt.Graphics;

public class hello extends java.applet.Applet
{
 public void paint( Graphics g )
 {
 Font f = new Font( "Chicago", Font.PLAIN, 36 );
 
 g.setFont( f );
 g.drawString( "Hello, world!", 0, 30 );
 }
}

Notice that we don’t have a main() in our class. Instead, our class follows the standard established for applets. The paint() method will be called when it is time to draw our applet. The Font object will be created using the Chicago font and is set to plain 36 point. The Font object is passed to the setFont() method, making that font, style, and size current for the Graphics object g. Next, the string “Hello, world!” is drawn in g at the coordinates (0, 30) using the method drawString().

To run this applet, you’ll need to first compile the source code into a class file (I called my class file hello.class) and then build a bit of HTML to launch the applet. Here’s my HTML code:

<title>My test applet...</title>
<hr>
<applet code="hello.class" width=250 height=35></applet>
<hr>

Of course, you might want to add more to your HTML, but this should do the trick. Save the code as hello.html, and be sure hello.html and hello.class are in the same folder. Now drag hello.html onto your applet runner. Theoretically, you should see something like the window shown in Figure 2.

Figure 2. Running the applet using CodeWarrior

Till Next Month...

To me, having the advanced windowing toolkit (AWT) is like having a copy of PowerPlant or the TCL. The framework takes care of all the administrative detail so I can concentrate on filling in the details. In next month’s column, we’ll do just that. We’ll poke around the nooks and crannies, exploring the AWT. See you then...