Letters to the Editor (3/5/99)

Cover story: “The Volano Report: Which Java platform is fastest, most scalable?” by John Neffenger

Read

JVM test choices explained

John,

Did you do any of the VolanoMark tests on Sun’s JDK 1.1.7 for Windows or Solaris? In your article I saw only JDK 1.2 [aka Java 2] from Sun. Don’t you think this would be a more apples-to-apples comparison between the VMs — comparing the same JDK versions?

Jeff Vagg

Jeff, I compared the JVMs our customers are using or will be using in the next few weeks. There’s always a large gap in the latest versions of Java available from each of the Java vendors. SCO is still on JDK 1.1.3, while Sun has already released Java 2. IBM and Sun are both going to release a JDK 1.1.8, but Sun’s Java 2 will have been available for months by then. Also, it isn’t fair to compare JDK 1.1.7 to JDK 1.1.3, for example, since Sun made several large performance improvements in the reference release of JDK 1.1.5. So I end up testing what our customers are running. In doing so, I give them the information they need to choose their Java platform. John Neffenger

Relationship between threads and OSs in VolanoMark tests

Thanks for publishing your performance figures. Do you have any idea how the threaded performance numbers are OS related? What’s the chance you could get a performance boost by implementing parts of your application with native code? I’m working on an application in Java that would need to use thousands of threads, and I wonder what the performance difference would be between Java and C++. If the underlying thread performance is OS related, I might not get much of a performance boost.

Michael Czeiszperger

Michael, A major factor in determining the VolanoMark score is whether the JVM implementation uses native threads, how native threads are implemented, and how Java threads are mapped onto native-OS threads. Native threads aren’t necessarily faster. For example, with high numbers of threads in the current implementations, on Solaris they’re faster and on Linux they’re slower. The issue is whether you think native code can more efficiently map the work to be done onto the threads doing the work, or whether you think the Java architecture does a good enough job. For networked applications handling a large number of connections, you might consider writing native code to call select or poll, since that kind of socket-to-thread multiplexing isn’t available in pure Java. I chose instead to stick with pure Java and avoid any native code in Volano’s products. John Neffenger

What? No Mac OS Runtime for Java 2.1 test?

John,

Great job in going to the heart of the matter in your test of what Java needs to do to be serious.

But where is the MRJ 2.1 test? Even if doesn’t run, you should have tried it and said so, if only to force improvement.

Bill Anders

Bill, I ran tests on the Mac in my previous JavaWorld article, “Which Java VM scales best,” (August 1998), but this time I concentrated on Intel-based platforms. The Mac OS Runtime for Java (MRJ) 2.1 is a huge improvement, solving many problems formerly encountered using Microsoft’s JVM for Internet Explorer on the iMac. I recommend that everyone using Internet Explorer on the Mac upgrade to MRJ 2.1, available at: https://devworld.apple.com/java/index.html John Neffenger

Why John didn’t test Sun’s HotSpot

John,

I noticed in your JavaWorld article on JVM performance that you occasionally used preview releases of operating systems, such as IBM’s OS/2.

What about HotSpot? Were you able to try out a HotSpot beta with VolanoMark? Last I heard Sun was keeping HotSpot betas private and not disclosing any performance results. Have you heard anything different?

Jonathan Brumley

Jonathan, Some of the operating systems and JVMs I tested are preview releases, but all of them are generally available for download on the Web. However, I don’t know anyone outside of Sun who has been able to test HotSpot. Dave Griswold, manager of Java Platform Performance at Sun, has given talks (with numbers) at Sun Headquarters Briefings and at tradeshows about relative performance running with and without HotSpot. I’ll test VolanoMark with HotSpot as soon as it’s available. John Neffenger

JavaBeans: “XML JavaBeans, Part 2: Convert your JavaBeans to XML documents” by Mark Johnson

XML: The big-picture picture

Mark,

I’ve read both your first article and this current article and, although you’ve demystified a lot of stuff for me, I’m still not comfortable with the whole idea and supposed beauty of combining the XML and Java technologies.

Specifically, XML and JavaBeans are talked about in the industry as a “marriage made in heaven” but I fail to see the significance (and subsequently the opportunities) available when combining these technologies.

I think my problem is that I fail to see the big picture!

Correct me if I’m wrong but, taking your XMLBeanReader/XMLBeanWriter application as an example, this whole thing of one XML application being able to exchange XML objects with another XML application is entirely dependent on both XML applications strictly conforming to your DTD [document type definition]. But what if some company out there decides to develop an enhanced version of your DTD to incorporate more JavaBeans features? Should this occur, there now would be two different competing and perhaps incompatible XML JavaBean applications.

Then we’re back to the old story of a company extending or supplanting an existing standard in favor of its own offering. (Analogous to the case where both Netscape and Microsoft decided to develop their own extensions of the HTML standard.)

This would leave both individuals and companies confused as to which implementation to use.

The only way I can see this working is if everybody agrees on a standard (in our example a standard XML JavaBean XML implementation) XML implementation.

Garry Cronin

Garry, Great questions. Let’s see if I can come up with some great answers. XML isn’t just another language like HTML, it’s a language for defining new languages like HTML. HTML is a mess because people need extensions, and HTML isn’t easily extensible. XML lets you make up your own language for each problem domain. The DTD is the description of the language, like the (implied) DTD in my XML JavaBeans. What people will be arguing over is the content of the DTDs, but that’s what the whole process of designing standards is about. It’s fine to make up your own DTD for use inside an application. However, if you want an open system, you’ll need to find (or create) a standard DTD domain and then design to that. A major reason that XML and Java together is such a win is that designers can extend their XML “dialect” (that is, the DTD) and then extend their application to handle the new features of that dialect by writing new classes. Of course, you can do that in any language (making XML a win with systems not written in Java), but Java’s dynamic class loading and runtime class handling make it an excellent choice for designing systems that use XML. Systems don’t necessarily have to conform to the DTD in order to use my XML JavaBeans (which, by the way, I don’t recommend — IBM’s Bean Markup Language is the real thing). This is because once a bean is formatted in XML (let’s use my DTD as an example), an XSL style sheet (or some other object transformer) can be used to translate between my output DTD and the input DTD of whatever you wish. In fact, you could even write an XSL that transforms a serialized JavaBean object into a Web page! Certainly XML won’t keep Microsoft and Netscape from fighting. That’s too much to ask of any (non-nuclear) technology. To paraphrase Richard Stallman, XML only solves some of the world’s problems, not all of them. The problem with HTML is that it’s a language designed for information display, not information representation. That’s why everyone is jumping up and down about XML: It’s about how to represent content. XML is the level playing field for discussing how to represent information in a portable, well-documented, and consistently digestible way. If you want to find out more about XML, XSL, Java, and the like, be sure to read my upcoming article in JavaWorld, where I explain how XML works, how it works with Java, and how all this technology hangs together. Mark Johnson

“Java Tip 69: Press Escape to close your Java dialog windows” by Eugene Podgorbunskikh

Even better!

Eugene,

I believe your article gave an excellent review of the event model in 1.1x and indicated what I believe is a serious flaw: that events aren’t forwarded up the parental hierarchy.

What I believe is a better model is for all events to be passed up to their superclass.

This can be achieved by modifying the code for Container:

processEvent(AWTEvent e) {
 super.processEvent(e);
 // normal process event code
}

This would allow keyEvents to be trapped at the top-level dialogue without all the intermediate registration mechanisms.

Alex Blewitt

Alex, I agree with you. But I would modify your code as follows:

protected void processKeyEvent(KeyEvent e)
{
      Container c = e.getComponent().getParent();
      if(c != null){
          c.processKeyEvent(e);
      }
      super.processKeyEvent(e);
}

I would also add boolean member

consumed

to class

KeyEvent

and allow programmers to modify its value. Then, if

KeyEvent

is processed at the

Container

level, we could notify the component that received the

KeyEvent

not to process it:

protected void processKeyEvent(KeyEvent e)
{
            Container c = e.getComponent().getParent();
             if(c != null){
                  c.processKeyEvent(e);
             }
             if(!e.consumed){
                 super.processKeyEvent(e);
    }
}

Eugene Podgorbunskikh

“Internationalize your software, Part 3” by Geoff Friesen

Read

How to set up Arabic text in Java

Geoff,

I want to display and manipulate Arabic text in Java. Are there resources I can use to develop my idea?

Omar Butaiban

Omar, Prior to Java 2 (formerly known as JDK 1.2), the input and display of Arabic, Chinese, and other complex characters required support from the host computer. Basically, at least as far as the various Microsoft Windows platforms were concerned, you needed to have appropriate keyboard drivers and fonts installed to enter and view such characters. You also needed to modify certain Java runtime files, such as font.properties, to map Java’s virtual fonts to the host’s fonts. Java 2 introduces two important internationalization features that should make it easier to enter international characters and display them. These features are:

1. An input method framework for entering complex characters (such as Arabic)
2. An output framework for rendering complex characters via Java’s 2D API

The input method framework consists of one interface and three classes that are part of the

java.awt.im

package. The interface is called

InputMethodRequests

, and the classes are called

InputContext

,

InputMethodHighlight

, and

InputSubset

.

InputMethodRequests

defines the requests a text-editing component has to handle in order to work with input methods.

InputContext

objects manage the communication between text-editing components and input methods.

InputMethodHighlight

objects abstractly describe the highlight attributes associated with text.

InputSubset

objects define additional Unicode subsets for use by input methods. The following Internet address contains Sun’s official specification for the input method framework:

http://java.sun.com/products/jdk/1.2/docs/guide/intl/spec.html

The following Internet address contains Sun’s official

Programmer’s Guide

to the Java 2D API:

http://java.sun.com/products/jdk/1.2/docs/guide/ 2d/spec/j2d-title.fm.html

Finally, I’ve come across a good Web site that contains links to other sites that deal with Java font and internationalization issues. This site is located at:

http://www.alumni.caltech.edu/~dank/javafont.htm

With this information in hand, you should be well on your way to manipulating Arabic text in Java. Geoff Friesen