Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Letters to the Editor

Quite a few readers responded to last month's JDK 1.2 bug report with skepticism at best; author Kieron Murphy takes on the critics. Plus: VolanoMark's John Neffenger addresses a mailbag full of JVM scalability queries; Merlin Hughes tackles the mathematical intricacies of 3D programming in Java; Allen Holub defends his approach to coding; and technical Q&A with Chuck McManis, Todd Sundsted, Bill Venners, and John Zukowski

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

"First bug bites Java 1.2 -- Mozilla stung" by Kieron Murphy

Read

What bug?



Kieron,

I am curious about what bug Felten and co. have found that needs to fixed in "all JVMs." I have looked in great depth at the JVM definition, and do not believe any class loading or type verification bug exists in the JVM.

Vijay Saraswat

"Early access" software clarification



Kieron,

I think "early access" to software is intended to flush out bugs. Early access software should not be used in a production environment; it should be used only by developers.

Mike LaRocca

Sensationalism?



Kieron,

The sensational title of your article does not match its reality. How can you state in the title that the first JDK 1.2 security bug has been discovered when, at the end of the article, you state that it's not exploitable in the JDK?

Li Gong

Either/or



Kieron,

Which is it? Your article states in the second-to-last paragraph: "I've just taken a look at Communicator 4.50 PR1, and the holes still exist there." However, the link you provide for Princeton University Secure Internet Programming (SIP) report of July 1998, clearly states:

This flaw is fixed in Navigator 4.5. We have verified that our demonstration applet does not work on Navigator 4.5.


Please clarify.

Name withheld

Kieron Murphy responds

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


"Which Java VM scales best?" by John Neffenger

Read

For future consideration: IBM OS/400

John,

I'm interested in seeing how the IBM OS/400 Version 4 Release 2 JVM compares to the other environments mentioned in your article -- especially against native-compiled Java. I bet I'm not alone in my curiosity. Maybe a future article?

Jack Callahan

IBM AS/400 VM -- "most scalable"?



John,

I'm surprised you didn't include the IBM AS/400 Java VM in your benchmarks. IBM is advertising the AS/400 VM as the "most scalable" and only VM that addresses the threading and cleanup issues that have plagued other platforms. Also, as far as I know the AS/400 VM is the only pure 64-bit Java VM commercially available.

With the introduction of the 0K 170 AS/400 models earlier this year, the AS/400 platform should receive consideration when evaluating a scalable Java platform.

John Lambert

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


What about Symantec?



John,

Symantec claims its VM is faster than Microsoft's VM, but it isn't included in your comparison. Do you have any unpublished numbers for this VM?

Christof Baumgartner

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


What do you mean by "restart"?



John,

Great article. When I see the word scalability I always groan because of the inevitable misuse, but you were on the mark.

It would be interesting to know the CPU utilization of the VMs in the test, i.e., are the CPUs at 100 percent?

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources