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

1 2 3 4 Page 4
Page 4 of 4
  • Your comment that synchronized methods are four to six times slower than non-synchronized methods is misleading. In fact there is almost negligible overhead for methods that do any real work.

  • Your approach to multithreading is for novices, and it does a good job for them. As a frequent user of multithreaded design, I would like to see a design pattern approach to building large-scale designs that guarantee against deadlock.

    For example, I do bi-directional communication using Java objects, where each object has a thread of its own. In my initial designs, I could get into deadlock if A sent a message to B while B was sending a message to A. I developed a design pattern to avoid this problem, which I now apply to all bi-directional messaging systems.

Keith Musser

Keith, To answer your comments:

  • I try to be kind of pessimistic with these numbers, because I don't want to be part of the Java hype. The four to six times number was very commonly quoted about the JDK, but it may be that the more recent JDK versions have improved significantly in this department, as your experience shows. Sun also promises that in its Hotspot VM, synchronized methods will be "free." Although sometimes when writing in Java, you know what VM your application will be running on, in general, I think you should write to the so-called Java platform, which implies that your application should be designed to run well on lots of different JVM implementations. That includes old JDK implementations that don't have the latest VM improvements, and of course, VMs from vendors other than Sun. So I try to walk the middle road in my advice by saying, don't make things synchronized (or thread-safe) that don't need to be synchronized because of the possible performance trouble. But also, don't avoid synchronization where you need it. Hopefully I emphasized that last one enough.
  • I'm not quite done talking about threads. This article was just focused on thread-safety, or how to get threads to not inadvertently clash with each other. I also plan to talk about active objects (a pattern) and thread cooperation. I'd be interested in hearing more about your bi-directional messaging pattern. I want to organize my column (and my next book) around both guidelines and idioms, so if you've got a good idiom (or pattern) to propose, I can publish it at my Flexible Java Web site and book (attributed to you) and perhaps it will make it into one of my Design Techniques columns (also with credit to you as the identifier of the idiom and/or pattern). I like the sound of your pattern, from the little you've told me about it, because it sounds like it is very object-oriented--in other words, it sounds like you've got a way for active objects to communicate without deadlocking.

Bill Venners

"Microsoft sheds its Java skin -- again" by John Zukowski

Read

Choosing a development environment

John,

I enjoyed your recent article. My question is how to marry, or whether to marry, Visual J++ and JDK 1.1? I am new to Java and don't know which development environment to establish.

Is it one or the other...or should I invest time and energy with both? Have you written on this topic before?

Ed Vesely

Ed, If you want to visually create forms-based programs based on standard Java components (JavaBeans/JDBC), you could do better than VJ++. If, however, you want to create Windows-specific programs, but don't like VB/Delphi, then VJ++ may be your answer. While VJ++ allows you to work with 1.1 JDK, it is strictly compiler support, not visual development support. If that is what you need, then you can use VJ++ as the integrated debugging support (it's much better than the Java debugger). If you want a visual development environment for creating front ends for database applications, check out tools like JBuilder, VisualAge for Java, PowerJ, and Visual Café for Java. Regarding the last part of your question, if you can read Japanese, I have an article comparing JDK 1.1 development with VJ++ development in the August 1998 issue of JavaWorld Japan (hardcopy only). John Zukowski

Related:
1 2 3 4 Page 4
Page 4 of 4