Letters to the Editor

Readers, To begin, any defects in the composition of the article are mine alone. I stand by the article, but admit it could have been better. To clarify matters, I offer the following comments on some of the criticism the article has received. The main complaint seems to be that the conclusion does not satisfy the premise. One reader notes: "The sensational title of your article does not match its reality." I made several attempts to contact appropriate representatives at Netscape and Sun for comment on this point, but neither organization responded in any detail for the record. Informed sources told me, however, that the dynamic linking problem in JDK 1.x and all contemporary implementations of the Java VM is a serious flaw. A distinction must, of course, be made between the existence of a flaw and its actual exploitation. The importance of the Princeton hole, in my opinion, was due to its breaking the barrier of successful type confusion in current and planned designs -- especially, by mounting a three-phase attack. That type safety was only broken in Navigator 4.x should not be considered a disturbance; it should be an alarm. Princeton's SIP researchers have long been at work on a theory that the dynamic linking mechanism in Java may have unsound technical properties. The Hostile Applets home page's class loader bug, discovered earlier this year, and the security manager trick in Navigator simply provided the topography for an attack. In my view, they succeeded in accomplishing their mission. Java developers should be very defensive in creating code. Designing security policy for users is of paramount concern for the success of the language and platform. So, I do not think my premise and conclusion disagree. In a related vein, another reader writes that a discrepancy exists between the quote of Dr. Mark LaDue -- "I've just taken a look at Communicator 4.50 PR1 and the holes still exist there" -- and a statement found on the SIP site -- "This flaw is fixed in Navigator 4.5. We have verified that our demonstration applet does not work on Navigator 4.5." This person has me by the short hairs. Briefly, two answers. First, in editing the final copy, I probably quoted LaDue out of context. Though his hostile applets are essential to the overall Princeton attack, in going through my notes, I realize his remark applied only to his own applets at the time I wrote the article. So I am guilty of rushing. In this regard, I believe I owe JavaWorld readers an apology. Second, the SIP site currently states: "Last modified: Wed Jul 15 16:22:00 EDT 1998." In my notes, I have a printout of the SIP site taken on July 16. It does not include the statement in question. I do not know when this addition was made, but I did not use it in my article, because I was unaware of it. I did know that Netscape had been apprised of the hole about a week earlier. Another reader writes to remind me that "early access ... is intended to flush out bugs." I wish I could kiss this guy. Sometimes commentators of all stripes forget the big picture. Software development is just that: code in progress. News readers want to hear the latest dispatches from the frontlines, and news writers try to give them that, as rapidly and well as we can. We need to remember that we are all communicating with one another because we are trying to help one another. We are not on different sides. Kieron Murphy

Jack and John, I would like to see how all of the other IBM systems perform with respect to Java: IBM AIX, OS/390, and OS/400. It's just a little harder (and it would be costly) to set those systems up myself in our lab. I would have included AIX but I was told IBM no longer supports an Intel version of that OS. I restricted my tests to operating systems that are available on the Intel platform, since it's impossible to compare Java virtual machine implementations once you start varying the hardware underneath. I made an exception with the Mac OS, since we have quite a few customers running Internet servers and our VolanoChat product on the Mac. I included the scalability tests on Solaris SPARC just to show that other hardware architectures can affect processor scalability, but only after I made the fair comparison to Windows NT with Solaris Intel Edition. Hewlett-Packard HP-UX, OSF, SCO OpenServer and UnixWare, and Silicon Graphics IRIX were also left out this time around. With well over 100 Java licensees, it's getting impossible to test all of the latest Java virtual machines on all of the available hardware platforms and still publish timely results. Once SPEC publishes its server-side Java benchmark suite, we'll be able to get these results directly from the Java vendors themselves. John Neffenger

Christof, I did include Symantec with the following Java virtual machines: JavaSoft JDK 1.1.6 JIT Update for JDK 1.1.6 Early Access 2 (Symantec JIT compiler Version x3.00.050) Novell JDK 1.1.5 Symantec Java! JIT compiler Version 3.00.040(x) for JDK 1.1.x JavaSoft JDK 1.2 Beta 3 Symantec Java! JIT compiler Version 3.00.023(x) for JDK 1.2 See the small print under each Java VM system configuration. John Neffenger