import java.*Jumping into Java

Hello again. "import java.*" invites you, the C/C++ programmer, to learn Java. In case you were wondering, there are some good reasons why you might want to do so. Java is much more than a mechanism for energizing web pages. It is a general-purpose object-oriented programming language found in increasing demand in many sectors of the software engineering industry. When it comes to learning Java, you are at an advantage as a C/C++ programmer, since Java's syntax closely resembles that of C++. And if you are a C++ programmer who is comfortable with the principles of object-oriented programming, you'll feel right at home. Just as many C programmers have picked up C++, many C++ programmers are finding the move to Java a natural.

I will be examining all aspects of the language, library, and culture, but from a C/C++ perspective. This means that I'm not a Java bigot (a zealot maybe, but not a bigot :-). In fact, my mastery and fondness of C++ may possibly bias me the other way at times. It also means that I will occasionally do the unspeakable. I'll compare the two languages and try to say something useful. In this article I offer only a brief look at Java, leaving detailed tutorials to future installments. But first, a little context.

A Word About Hype

I first heard the term "object-oriented" in 1984 in connection with the Apple MacIntosh. When I asked "What does object-oriented mean?" I was given some gibberish about graphical objects on the screen. Hence the myth that a graphical user interface makes something object-oriented.

By the mid-1980s the term "object-oriented" had been so abused that the only way to really cut through the hype was to find an unquestionably object-oriented programming language and use it. My epiphany came when I discovered Symbolics' Lisp with Flavors in 1987 and got first-hand experience with language support for encapsulation, inheritance, and polymorphism.

Later that year I attended an on-site marketing presentation from a certain relational DBMS vendor. I was quite proficient with their product already and was our company's local "expert." In the course of the presentation I heard the words "<Product X> is object oriented." I struggled to bite my tongue for the rest of the presentation, after which I raced up to the front and asked the presenter, "What did you mean when you said that <Product X> is object oriented?" The ensuing discussion revealed that <Product X> wasn't object oriented at all — it was just something they liked to say. Hype.

As you may know, the buzzword of the 70s was Structured Design, which the industry finally got right in the 80s. The hype of the 80s was object-oriented, which is today's orthodoxy. What is being hyped today? Patterns, I suppose; and, yes, Java.

Grass Roots vs. Hype

It is interesting that C++'s popularity grew so explosively without any marketing. In 1982 the designer of C++, Bjarne Stroustrup, faced a dilemma. The effort to support users of "C with Classes" (later named C++) was eating up most of his time, but there weren't enough users for management to justify funding an official support organization. Reflecting on the situation, Bjarne said,

I saw only two ways out of this dilemma:

1) Stop supporting C with Classes

2) Develop a new and better language that would serve a large enough set of users to pay for a support and development organization. At the time I estimated 5,000 industrial users was the necessary minimum.

The third alternative, increasing the user population through marketing (hype), never occurred to me [1].

In 1991, twelve years after the birth of C with Classes, there were 400,000 C++ users, and the number was doubling on the average every 7.5 months [2]. (A little math tells us that if that rate of growth had prevailed, every person on planet Earth would be a C++ developer by the year 2000 — a truly formidable Y2K problem!)

Since there was no carefully orchestrated marketing plan, and, moreover, since C++ is such a "complex language" (or so we hear), it's fairly safe to say that C++ has earned its place as a leading object-oriented development tool on its technical merits alone. Just as with C before it, C++ emerged from a grass roots movement among developers eager for increased power to meet the increasing demands placed upon them.

But the C++ story of rapid growth is nothing compared to Java's.

Java Sapiens

At his public Java seminars, well known author and teacher Bruce Eckel gives a T-shirt to all who attend. When you put it on you have a miniature Homo Sapiens running for his life on the left side of your chest. Bruce has named him Java Sapiens, for he represents you and I and most of the modern computer industry as we all try to keep up with the Java wave. A glance at the Java library reveals the velocity at which that wave is traveling. When Sun Microsystems introduced version 1.0 of the JDK (Java Development Kit) in mid-1995 there were 212 classes and interfaces in its library. Version 1.1 followed in 1997 with 504. The 1.2 JDK currently has 1,592 library classes and interfaces (with 13,635 methods), and it's still in beta! And as if that plus several new language features (inner classes, new event model, Swing components, pluggable VM architecture, etc.) weren't enough to keep our brains and fingers busy, we also need to unlearn the many classes and methods deprecated by each release as well.

Corporate America has traditionally been somewhat conservative when it comes to adopting new technology. All three of the large companies I've worked for preferred to use only programming languages defined by an ANSI standard. This explains why I was using Fortran at my first job in 1978. I did manage to sneak C into the workplace in 1986, a few years before its standard was final, but it was already 16 years old and quite stable at the time. The earliest I could get away with officially using C++ at work was in 1994, fifteen years after it was invented, nine years after going public, and five years into standardization. In general, corporate IT officers only go for "proven technology."

Why is it, then, that in spite of the unstable nature of this relatively new Java language, nearly every major software vendor provides Java tools, most beyond initial releases, to keep up with demand? Why has Java made such inroads into so many large, normally skittish corporations? Case in point: I taught Java to a very conservative company this spring so they could use it to rewrite their internal accounting system. What gives?

The easy answer is, of course, the Internet. Java came along when Internet access was becoming a household commodity. Giving it away for free certainly didn't hurt, but it was the Internet that made the freebie feasible. Adding applet capability was the clincher. Making static web pages come alive via applets has enticed lots of marketing dollars out of the hands of our nation's CFOs.

So hype — uh, I mean, marketing — is certainly part of the answer. In an interview with Bjarne Stroustrup in 1996, I asked what he thought of the "Java Revolution." He replied,

Java is certainly not the language I would have designed if I had had no [C] compatibility constraints. It is amazing, though, what Sun marketing dollars have been able to achieve. That is a lesson that will not be forgotten, and one that is ominous to the individual programmer, the small company, and the academic. If people insist on comparing C++ and Java — as they seem to do — I suggest they look through D&E (The Design and Evolution of C++) to see why C++ is the way it is, and consider both languages in the light of the design criteria I set for C++. The differences between C++ and Java are more than skin-deep, and not every advantage goes to the same language [3].

Where's the Beef?

Marketing may get our attention, but it can't ensure sustained success. Javascript and animated GIFs now do most of what applets have been used for, yet the Java revolution continues. Java is a growing success because there is merit behind the hype. It appeals to programmers because it comes off as a clean, well designed software development tool that isn't "too hard" to learn. Java appeals to those who fund development because its emphasis on objects and packages, together with its virtual machine architecture, support a tractable, cost-effective, and (mostly) secure way to build and distribute applications. Everyone except vendors of operating systems likes the idea of "write once, run anywhere." And Java's unparalleled support for network programming is winning praise from the world of electronic commerce. Let's face it: Java is cool.

But don't shelve your C++ compiler just yet. Java can't do everything. That's why it comes with support for the JNI (Java Native Interface) to call C and C++ functions. Where speed really matters, C++ is still the winner (for now). And even though Sun has released a specification for Embedded Java, you can be sure that it will be some time before Java replaces C as the lingua franca of embedded programming.

And Java is not as easy to learn as some might have you think. On the fourth day of teaching at the company I mentioned previously, a number of the students, sporting a wearied countenance, emoted, "Boy, this isn't easy as I thought it was going to be!" (As I recall, we were talking about cloning, reflection, and I/O that day.) I think Larry O'Brien summed it up best when he said, "Saying Java is less complex than C++ is like saying K-2 is shorter than Mt. Everest." Java is complex, but in different ways than C++. Whether it really is easier depends on you and your needs. Solving real problems is never easy, no matter what tools you use.

What's Missing?

Java began as Oak, a language based on C++ but stripped down to work on embedded systems. Although what you now get in the JDK is bigger than Oak (and not suited for embedded applications), Java manages without the following features found in C++:

• explicit pointers & references
• a delete operator
• destructors
• default arguments
• templates
• global functions and data
• local static data
• macros (imagine!)
• operator overloading
• multiple (implementation) inheritance
• separating declarations from definitions

The first two items seem to be a big selling point for Java converts. Pointers are among the most difficult concepts to master, and chasing runaway pointers is common sport in the C/C++ workplace. But you still have to understand basic indirection, otherwise you can't use objects in Java (therefore you can't use Java). All Java objects are dynamic and live on the heap. You create a Java object with the new operator:

Foo f = new Foo();

f is essentially a pointer to the real Foo object on the heap, but you can use it only as a means of accessing its object; you can't, for example, do arithmetic with f. To make things easier for us C/C++ programmers, we need a term other than "pointer" or "reference" to denote f. "Handle" seems to do nicely. To access a class member, then, you use the usual C member selection syntax with its handle, e.g., f.x. If you pass an object as an argument to a function, it is a copy of the handle that gets passed. As in C, all arguments are passed by value, so Java has no equivalent of C++ references.

What this means is that you can't write a function that effectively swaps its two arguments, but a function can modify the data members of its object parameters. Suppose, for example, that I define Foo with a single integer argument, x, as follows:

class Foo {
    public int x;
}

Then the following swap function will exchange the x member of its arguments:

public static void
swap(Foo f1, Foo f2) {
    int temp = f1.x;
    f1.x = f2.x;
    f2.x = temp;
}

and behaves essentially the same as the following C function:

void
swap(struct Foo* f1,
    struct Foo* f2) {
    int temp = f1->x;
    f1->x = f2->x;
    f2->x = temp;
}

Now take a look at the second item in the list above. What? No delete operator? How irresponsible! No, not really. Programmers don't need to return memory to the heap because Java has garbage collection, which reclaims all unreferenced memory automatically. The good news is that you don't have to worry about memory leaks. The bad news is you have no idea when the garbage collector will run, and which objects will be reclaimed when. This makes it infeasible to control resource deallocation through garbage collection, and is one reason why Java doesn't have destructors. If you want to release a resource at some particular point in time, you have to do it explicitly.

What's There

So much for what Java doesn't have. What it does have is robust support for classes and objects, as well as a feature-rich library for any programming task you can imagine. C++ programmers learning Java will find the following items significant:

• Everything resides in a class. (Remember, there are no globals.)
• You don't have to worry about memory leaks.
• Character types are encoded in Unicode.
• Exceptions are not optional. (Be prepared to handle them.)
• The library supports threads and network programming.
• Built-in (primitive) types are the same size on all platforms.

To illustrate the first point, here's the complete program I used to test the swap routine above:

// Swap.java
class Foo {
    public int x;
}

public class Swap {
    public static void swap(Foo f1, Foo f2) {
        int temp = f1.x;
        f1.x = f2.x;
        f2.x = temp;
    }
    public static void
    main(String[] args) {
        Foo f1 = new Foo();
        f1.x = 1;
        Foo f2 = new Foo();
        f2.x = 2;
        swap(f1, f2);
        System.out.println(f1.x);  // 2
        System.out.println(f2.x);  // 1
    }
}

Notice the absence of anything resembling a delete operator.

As this listing suggests, Java programs consist only of classes, which in turn contain fields (data members) and/or methods (member functions). That's it! This simple organization, along with a convenient library packaging mechanism that I'll show in future articles, provides a practical discipline for managing large applications.

To compile this program using the JDK, I typed the following on the command line:

C:> javac Swap.java

The file extension for Java source code is .java. There must be at most one public class in each file, and it must match the base part of the file name (case included). The javac command produces a .class file for all classes defined in its .java file arguments. A .class file contains byte codes, which are executed by your local implementation of the JVM (Java Virtual Machine). The java command loads the JVM and instructs it to start execution by interpreting the byte codes in the main method in a .class file, as in

C:> java Swap
2
1

The Swap class itself contains no data, and all its methods are static, which means they don't need a Swap object to execute (just like in C++). In fact, Swap exists only to serve as a place for the swap and main methods to reside. System.out is the Java equivalent of stdout, and the println method converts its argument to a string before writing it.

A working Java program typically consists of multiple .class files. When one class needs to call upon the services of another, the JVM searches for the latter's corresponding .class file. Since every function in Java is a method of some class, there is no conflict in having multiple mains in a program. In fact it is not unusual to have a main in each public class for testing purposes. The existence of no single program main also means that there is no return from main to the operating system, but Java provides a special method, similar to C's exit function, for that purpose.

It is the virtual machine architecture that gives Java its "write once run anywhere" portability. As long as a platform has a JVM that meets spec, it doesn't matter where the byte codes come from. Since a JVM is an interpreter, however, it exhibits the expected speed degradation when compared to full compilation. To partially compensate for this degradation, the JDK now comes with a "just in time" (JIT) compiler that compiles byte codes to native code the first time a class is loaded. So code needs to be interpreted only once, instead of every time it is called. Other commercial JIT compilers and full native code compilers are also becoming available.

The Executive Summary

As you can see, Java's syntax is almost identical to that of C++ — statements end with a semicolon and compound statements reside between braces. Notice, however, that class definitions don't end with a semicolon. Furthermore, there is no struct keyword (which shouldn't bother anyone). You also have to specify the access (public/private/protected) of each field or method definition individually, which forces some extra keystrokes. Perhaps the biggest culture shock is doing formatted I/O. Java has no equivalent of scanf or printf, for example, which can make simple command-line I/O in Java pure frustration for the potential C/C++ migrant. Yet this kind of command-line I/O is becoming less important in today's world of graphical user interfaces, and I'll show in future articles that Java's I/O package has a number of very sophisticated features.

Is that all there is? No, that's just all I'm going to cover in this article. My purpose in this first installment is to lay the context for this series, and to whet the appetite a little. In my next installment I'll begin an in-depth look at the Java language, starting with primitive data types, operators, and control structures (the easy stuff). If you're interested in worthwhile books on the subject, you'd do well to visit the Essential Reading List in the Editor's Corner at the CUJ web site (www.cuj.com). I recommend the following books as two of the very best:

1) Arnold & Gosling. The Java Programming Language, Second Edition (Addison-Wesley, 1998). A superb, concise introduction to the language, by the inventors.

2) Bruce Eckel. Thinking in Java (Prentice-Hall, 1998). The friendliest, most comprehensive book on the market.

Enjoy.

References

[1] Bjarne Stroustrup. The Design and Evolution of C++ (Addison-Wesley, 1994), p. 63.

[2] Bjarne Stroustrup. The Design and Evolution of C++, p. 163-164.

[3] Chuck Allison. "C++: The Making of a Standard," C/C++ Users Journal, October 1996.

Chuck Allison is Consulting Editor and a former columnist with CUJ. He is the owner of Fresh Sources, a company specializing in object-oriented software development, training, and mentoring. He has been a contributing member of J16, the C++ Standards Committee, since 1991, and is the author of C and C++ Code Capsules: A Guide for Practitioners, Prentice-Hall, 1998. You can email Chuck at [email protected].