Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

Audio Enhancements

The earliest releases of Java did not include much provision for sound—a serious shortcoming for a language so well suited for multimedia. Sun quickly closed this gap. The latest version of the JDK offers the best sound support yet.

Java Sound JDK 1.2 contains a new, higher-quality sound engine that plays MIDI files as well as traditional sounds (such as .au, .wav, and .aiff formats). The new sound engine is backward compatible with the sound engine in JDK 1.1—no programming changes are required.

getNewAudioClip Method Prior to JDK 1.2, one played audio clips through an applet context. This design presented a problem for application programmers who wanted to play audio clips but were not running an applet.

The new getNewAudioClip method is an Applet class static method—associated with the class rather than any particular instance of the class. This method enables application programmers as well as applet programmers to make a new audio clip based on a URL.

Performance Enhancements

When the subject of Java comes up, someone always points out that native code runs about 20 times faster than Java. Although that figure may have been true at one time, Sun has been working hard to close the gap. The greatest successes come from the use of Just-in-Time (JIT) compilers, but Sun has also introduced improved performance for multithreaded programs and even better memory management. This section describes the performance improvements associated with JDK 1.2.

---

NOTE:  If your application needs true native speed but you still want to work in Java, consider one of the new compilers that generate native code. Just remember that you’ll lose many of the benefits of the JRE when you compile your Java as a native application.

---

Solaris Native Thread Support One of the shortcomings of multitasking systems is the time that it takes to fork a process. Operating system vendors such as Sun have made a considerable investment in “lightweight processes,” or threads, at the operating system level.

To be platform independent, Sun ensured that services offered by the first versions of the JVM were completely independent of the underlying operating system. Thus, threads are included in any version of Java without regard to whether the underlying operating system supports threads.

When the underlying operating system does support threads, however, it makes sense for the JVM to take advantage of that fact. Because the native threads have been highly optimized, native threads will typically run much faster than the threads written in a platform-neutral JVM.

Because Sun Microsystems makes both Java and a family of UNIX workstations (with highly optimized threads), it makes sense that Sun would add native thread support to the version of the JVM that runs on its own Solaris operating system. (Solaris is a variant of UNIX.)

The fact that the JVM is using native threads does not mean that your Java code has to change at all. You still make, control, and destroy threads the same way you do on any platform. If the underlying platform is Solaris, however, your code will now run faster.

Memory Compression for Loaded Classes Starting in JDK 1.2, constant strings are shared between classes, reducing the memory needs of all classes. Because Java strings are immutable, you don’t need to worry about some other class changing your class’s string.

Faster Memory Allocation and Garbage Collection As programmers have started to take advantage of multithreading, resources that are shared among threads become the constraining factor in performance. In JDK 1.2 Sun has given each thread some independent memory allocation and garbage collection assets. The effect of this change is a marked improvement in performance for multithreaded programs.

Monitor Speedups Some threads must be marked as synchronized so they don’t conflict with other threads for resources. Inside the Java Runtime Environment, a monitor function makes sure that only one synchronized thread is running at once. Sun has improved the performance of the monitor, which leads to further speedups for multithreaded code.

Native Library JNI Port Way back when Apple chose the PowerPC as the successor to the Motorola 680x0, it made an amazing discovery. About 80 percent of a typical Mac application used only 20 percent of the application’s code—and most of that was in Apple’s own routines, a section called the Mac Toolbox. By porting the Toolbox to the PowerPC, it was able to improve the performance of older applications that had been written for the Motorola processor.

Sun has been using that same lesson to improve the performance of Java. Most of an application or applet’s time is spent deep inside Sun’s code, not out at the level that you and I write. Sun has rewritten its core libraries to use the Java Native Interface (JNI). Because your program is now running native code when it runs Sun’s libraries, your program gets a performance boost.

JIT Compilers The name “Just-in-Time” compiler is a bit misleading. To most professional programmers, a compiler is a program that runs on their machine—the binary output is distributed to the end users. The Java compiler is a compiler in this sense of the word. The JIT compilers, however, run on the end user’s machine, just ahead of the Java interpreter.

The first time the JIT compiler sees a piece of code, it passes it through to the interpreter, but it also compiles it and saves the native code. If the program loops back through this same section and the JIT compiler sees this code again, it doesn’t bother to run the interpreter—it executes the native code.

Both Microsoft and Netscape have included JIT compilers in their Web browsers, giving end users a 13-to 15-fold performance improvement inside loops. Because most modern programs are loops within loops, the performance gain is substantial.

In JDK 1.2, Sun has included both a Solaris and a Win32 JIT compiler.

JNI Enhancements

For all the power of Java, sometimes a programmer needs to get to platform-specific code. You can link C++ or other programs into your Java application by using the Java Native Interface—JNI.

In JDK 1.2 Sun added several enhancements suggested by its users and licensees. Under JDK 1.1 for example, a native library loaded by one class became visible from all other classes. This practice led to namespace collisions and violated Java’s type-safety rules. In JDK 1.2, the same native library cannot be loaded into more than one class loader.

A native library that wants to use the new JNI 1.2 services must export the function

jint JNI_OnLoad(JavaVM *vm, void *reserved)

When OnLoad() is called, the native library must return 0x00010002 to indicate that it wants version 1.2 services.