Disclaimer

Common Complaints

"Java is slow"
"Java is bloated"
"Java is ugly"
"Java is useless"

Let us tackle these one at a time.

Java Performance

Many people will tell you that Java is a compiled language; not interpreted like Perl, REXX and other common scripting languages. They are only partially right.

Java source-code is written into a standard text file and given a .java file extension.
These files are then compiled into Java ByteCode and given a .class file extension.

Class files are like any other executable file. They consist of a well-defined file structure specific to a target platform. Herein lies the catch: Java's "target platform" is not Windows or OS/2 or Macintosh but rather a non-existant platform called the Java Machine. "But wait", you say, "How can OS/2 run executables designed for another platform?" That's where Mr. Interpreter comes in.

Here's the part where it becomes hazy. In a sense, all executable files are interpreted. If you think about it, for the operating system to be able to execute a given program, it must first load the program into memory, formatting it to the specific machine code, and then the CPU proceeds to execute it sequentially. Granted this is a somewhat simplified overview of the process, but it more-or-less holds true.

Java adds one extra step to this process. Before one can execute Java class files, the executable code must be translated from the Java Machine's architecture to the local machine's architecture. This extra layer of translation leads to the performance overhead in question. If you think about it, the Java Virtual Machine (JVM) is nothing more than a glorified platform emulator.

Anyway, getting back to the point at hand: this is where the big performance drop comes from. The extra overhead of translating the executable code from one architecture to another leads to the slowdown you and I experience. Granted, JVM technology has been improving in leaps and bounds over the past few years, but Java code will never be as efficient as C/C++ code, just as C/C++ code will never be as efficient as ASM code. There is a reason for moving from one language to another, although from the end-user's point of view, this might not be quite so obvious.

Where does this leave us? I agree Java is slow. I don't promise it will get any faster anytime soon. I do promise, however, that by the time you next upgrade your computer you will notice little or no difference between native code and Java code running on your machine. To prove my point, I recently ran into a Java-based MP3 player called Jazz which looks and sounds great and uses approximately as much CPU as WinAmp on this machine. So you never know.

There are major performance increases planned for the next release of Java (JDK 1.4), mainly in the field of video I/O, so keep an eye out for this one. Applications making use of JDK 1.4 will be able to use video hardware-acceleration which will lead to noticeable performance increases, especially in the field of multimedia.

Java Memory Fingerprint

Java is fat. Why? Remember the JVM we discussed a little earlier? Well, as you might have guessed, translating code from one architecture to another is a really slow process. What do programmers do when a frequent operation runs slowly? Simple! Cache your result! That's exactly what the JVM does. It analyzes the Java code as it is being executed, isolating frequently-used operations. It then saves the result of translating these operations so when they are next encountered, no translation will be needed. JVMs which make use of this trick are called "Just-In-Time (JIT) compilers." IBM's JDK for OS/2 is one such compiler. The resulting JVM leads to superior performance but increased memory usage.

When you run a Java program, your memory is being used by the following three entities:

Java ByteCode - the actual "machine code" making up the program which has to be loaded into memory.
JIT cache - used to cache frequently-used translations.
Java Heap - memory used by the program when it allocates/deallocates memory during its lifetime.

Here's the trick: the Java Heap has a default value of around 128MB for most systems. This is excessive and in some cases it encourages programs to continuously allocate more memory instead of reusing what they already have. I won't go into the specifics here, but the basic idea is that a Java program will use as much memory as is available to it in order to increase its performance. You are expected to be smart enough to limit the heap-size to a reasonable amount. Unfortunately, most software developers are ignorant of this fact and rely on the default value. This leads to bloated programs.

Be warned, you have absolutely no control over the amount of memory the Java ByteCode and JIT cache will use. The ByteCode will use as much memory as necessary to load the program into memory (just like all other programming languages.) The JIT cache will depend on various factors (ByteCode and heap size to mention two.)

So, once again, where does this leave us? Well, it is up to us to make sure we limit the heap-size to a reasonable figure. Giving the program too little memory will lead to OutOfMemory errors or poor performance (caused by frequent memory cleanup.) Giving the program too much memory leads to wasted memory. How much is enough? This is usually best-determined by the program developer, but early figures suggest minimum-heap + 25% should be used. That is to say, if we find out the program absolutely requires 1MB of ram, we should give it 1.25MB of heap space to play around with. Other programs, such as Netbeans, load and unload class files during their lifetime so this 25% rule doesn't apply in quite the same way. In any event, it's not the end-user's job to figure this out; developers should be including start-up scripts with their programs to deal with this issue. I've posted such scripts on my site and take requests in case some Java application does not come with its own script.

Beauty is in the Eye of the Beholder

JDK 1.2 introduced Swing, a new GUI library, which changed the face of Java applications. Using Swing, developers can modify the program's Look & Feel at will. This concept is built on top of the idea of "application skinning" but is far more powerful.

The result speaks for itself:

Limewire, a Gnutella client written in Java

Jazz, a Java-based MP3 player

Nowadays, Java's Look & Feel is limited only by the developer's imagination. Hopefully we'll see more good use of this in the near future.

Real Applications -- Real Uses

So, without further ado, here are a few Java programs to feast your eyes on:

Limewire - A Gnutella client (peer to peer, like Napster.)
JNapster - A Napster client.
Jazz - An MP3 player.
Dungeon Master - Game.
Java applications for PalmOS.
Java MPEG Player - pretty impressive albeit slow loading.
Java Image Editor.
Postscript Generator for Java.
Jave - Java ASCII editor (neat!); check out http://www.jave.de/i2a2_ss.gif
WeirdX - XWindows written in Java.
Java Art
Netbeans - Java IDE.
JBuilder - Java IDE.
AnyJ - Java IDE.
TogetherJ - Model-Build-Deploy platform.
Discussion of Java Games - An article hosted on javasoft.com.
AI Pengo - A old addictive atari game where you play a penguin.
Friendly Giants - Online gaming company.
Java arcade games - A listing of many good Java games.

Conclusion