It's been a good run for Sun lately. First, a federal judge made a
preliminary ruling in Sun's favor, forcing Microsoft to update its
version of Java to be compatible with the standard specification. Next, it came out of the AOL/Netscape deal with an exclusive license to Netscape's
server software, plus a commitment from AOL to improve and extend
browser-side Java. Finally, the company will next week release JDK 1.2, a much-anticipated upgrade to the Java platform that promises to increase performance, functionality, and security.
But does it live up to the hype? We've all heard this kind of promise
before. Sun has said for years that the next version of Java will be
"The One" that silences all the naysayers for the last time. Furthermore, this release has been plagued with delays and pulled features, causing some to wonder if it isn't just vaporware in the classic style.
Fortunately, I can report that Version 1.2 of the Java Development Kit is (pretty much) everything Sun said it would be. Those of us who have been using Java all along can breathe a sigh of relief -- we've finally got a high-quality user
interface framework, a standard Collections framework, and a security model that makes sense, among other things. Those who are just joining us will find a
development platform that's consistent, feature-rich, platform-independent, and, yes, not dog slow. (I still hesitate to call Java "high performance.") Moreover, Java is primed to enter the enterprise, with integrated support for CORBA, SQL, naming services, distributed transactions, and security -- all the items on a corporate developer's checklist.
Should I upgrade?
In a word: yes. With one notable
exception, there's really no reason not to upgrade your present installation.
There are enough new features to make your mouth water.
JDK1.2 is fully backward-compatible with previous versions of Java, including 1.1 and 1.0. None of the deprecated methods have actually been removed (nor are there any plans to remove them). Even the old 1.0 event model is still supported. So that means all your old source code will compile and run fine. (You should still plan to test it, naturally.)
Sun's new VM is faster than ever, even without the still-vapor HotSpot technology.
JDK 1.2 is also remarkably stable. In a break from software industry tradition, the reason it's been delayed so long is because the engineers were actually working on stability, not trying to rush new, untested features in before the deadline. I've personally been using pre-release JDK1.2 for months now, and aside from a few Swing glitches, I've been very pleased. I'm sure the release won't be flawless. They never are. But there's no need to be paranoid with this one. (Of course, you should run your code through
its paces after you upgrade, if only to reassure yourself.)
Compatibility
First, a definition. Java as a software development environment comprises essentially three parts:
- the virtual machine (VM) spec -- bytecodes and memory management and thread scheduling and synchronization
- the language -- everything that goes inside of
.java files
- the core libraries -- all the various class files that make up the
java.* hierarchy (plus some of the new javax.* standard extensions)
In the beginning was the Alpha -- that is, the various alpha (then beta) versions of Java that were released to friends and family while Gosling and company were deciding what features to put into the language and the virtual machine. With the release of JDK 1.0 in January 1996, the virtual machine specification was essentially fixed. With the release of JDK 1.1 in February 1997, they added some major features to the language (e.g., inner classes, reflection) and
some major new class libraries (e.g., RMI, events).
For JDK 1.2, they have added virtually nothing to the language and the VM spec. JDK 1.2 is primarily a library and performance release. [*1]
This means that most of the new features of JDK 1.2 are actually
compatible with JDK 1.1! If, for whatever reason, you can't upgrade,
or if your IDE hasn't been updated, but you want to use Swing, or
Collections, or CORBA, in your old 1.1 installation -- go right ahead.
Just add the classes to your CLASSPATH. The only real issue in doing
this is the package naming issue. Some IDEs, such as Visual Age for
Java, refuse to import new classes from the java.*
hierarchy, essentially ignoring the normal CLASSPATH semantics. If you're
using these IDEs, you'll have to wait for the vendors to update their products.
(Note that the old package naming issue -- that some package names
changed during the beta cycle -- is now moot. Just update all your source to use the new, standard names, like import javax.swing.*.)
Client-side compatibility
When Java was first announced, it was touted as a new paradigm (sorry)
in software distribution. Users on any hardware or OS platform would
connect using a Web browser, download their software, and run it inside an HTML page. Best of all, they would always get the latest version of the code! Java would solve the age-old version problem once and for all.
It didn't quite work out that way. Programs of any reasonable size
need a more sophisticated caching and updating mechanism than just
"download it all every time" (such as the one Marimba's Castanet
provides). Furthermore, ironically, the designers of Java just plain
forgot that the Java virtual machine itself occasionally needs to be
updated.[*2] Because there is no standard mechanism for automatically updating the VM, developers who want to write applets that run across the global Internet are now looking out over a wasteland of old and incompatible browser VMs.
The Java Plug-In is supposed to fix this problem. With the Java Plug-In, the browser is supposed to install the latest version of the Java VM before running an applet.
Unfortunately, there are two major flaws.
- Plug-ins don't work right. Netscape's mechanism for
downloading and installing plug-ins is clunky and confusing; Internet
Explorer's works pretty well, but in any case it's a 9-meg download
and an install wizard before the user can see your applet...
- It doesn't override the <APPLET> tag. Instead, you
have to alter your page to use EMBED and/or OBJECT tags. That means if
the user comes to a page that uses the APPLET tag, the old, buggy
browser VM will be used instead.
The good news is, if these two flaws aren't important to you, you've
got a standard, compatible way to use JDK 1.2 in your users' browsers. The best example is in an intranet, where you have full control over a limited number of machines, and you can put the install file on a file server on your LAN, so the 9-meg download isn't so painful.
Coming next time...
In part 2 of this article, we'll cover the new features and some advice on how best to use them.
Footnotes
[*1] With JDK1.2, the language now has a new keyword,
strictfp, which forces floating point operations to use
standard IEEE math, instead of taking advantage of faster but
nonstandard extended precision math on some VMs. The VM has changed a
bit, but all of the changes are to the implementation, either for performance improvements, bug fixes, or to add support for native methods called by some new classes. The execution of bytecodes has not changed at all.
To quote David Bowen, an engineer from Sun:
The core VM spec hasn't changed in major ways... (I'm using the
term "core VM" to refer to the VM as defined in the VM book. The term
"VM" is sometimes used to describe more than just this core, e.g., reflection, class loading, thread support, JNI, etc. Of course, sometimes people use "VM" to mean the whole runtime environment, including all the class libraries.)
Behind the scenes there have been a small number of obscure fixes that
were necessary to fix design bugs... [V]arious things were done to the
implementation to improve performance, and scalability on
multiprocessor machines. There is a new version of the Symantec JIT
(3.0) bundled with the Windows release. (This JIT also ships with
1.1.6 and up.) Some runtime space improvements were made by improved
sharing of constant data across classes. The VM is now able to return
space to the OS, a much requested enhancement. Internally, a new
binary interface has been implemented between the VM and the rest of
the native code which supports the libraries. This interface, called
the JVM interface, will allow us to ship the HotSpot VM as a simple
add-on to JDK 1.2, rather than requiring a whole new JDK. (Note that
the JVM interface is not a public interface at this time.)
There is VM support needed for Reference Objects. Also, the new
fine-grained security model requires some modifications at the VM
level. Finally, the extensions mechanism is a significant enhancement
which can be considered VM-related. All of these are outside the
current scope of the VM specification, which is focused on defining
precisely the execution semantics of bytecodes, but they are closely
related to the VM.
[*2] Okay, they didn't literally forget, but it feels that way... :-)
About the author
Alexander Day Chaffee is the CEO of Purple Technology, a leading Java training and consulting company. (If you want to take a class, click here!) He has been
promoting, teaching, and programming in Java since way back in 1995. As the director of software engineering for EarthWeb, Alex co-created Gamelan, the
official Java directory. He has also given presentations at numerous users groups and conferences, written articles for several magazines, and contributed to the book The Official Gamelan Java
Directory.
