Letters to the Editor

This month: Readers cut HotSpot (and Java) down to size. Plus, more MessageBox app questions for Jack Harich; new columnist Bryan Morgan fields his first Distributed Objects inquiry; and Mark Johnson may just have to switch from instant -- "freeze-dried" -- JavaBeans to beans by the bag

"HotSpot: A new breed of virtual machine" by Eric Armstrong

Read

Generational garbage collection: Smalltalk did it first

Eric,

In your HotSpot article you wrote that generational garbage collection "has seen a lot of academic work, but is now finding a major application in the Java language."

Please, Eric. Smalltalk (VisualWorks) has used generational garbage collection for years. You make it sound like Java is introducing this feature to mainstream computing.

Don't get me wrong. I love Java, but I've seen too many articles about all the cool "new" things Java brings to the table (i.e., virtual machines, JIT compilers, reflection). In fact, many of these things have been around for years, and were perfected in Smalltalk and other bytecode-based languages.

Hell, Sun went out and bought Anamorphic Systems for its VM expertise. Guess which language it gained all that expertise supporting?

Mark A. Woyna

Director of Object-Oriented Architecture

The Chicago Board Options Exchange

Java will never beat C++!

Eric,

Java meets or exceeds the performance of C++ in object-oriented programs? You must be kidding. Either you've never programmed in C++ or you're lying to yourself and everyone else.

A good object-oriented program requires the fast creation and destruction of lots of little objects (small amounts of allocated memory). This is exactly where C++ shines and Java chokes!

Plus, the C++ language is just C with an extra function parameter, so C++ and C programs are very similar in performance.

I like Java as a language, it's clean and simple, but it comes with a price. Java will never meet or exceed the performance of C++ -- no matter how many times Java fanatics say otherwise!

Jim Cudney

JavaBeans: "Do it the 'Nescafé' way -- with freeze-dried JavaBeans" by Mark Johnson

Read

Uh oh...FreezeDryTM

Mark,

I enjoyed your recent article on JavaBeans, but I found your titular analogy off the mark.

FreezeDryTM is the trademark for a TeleMedia Devices Inc. proprietary technology that allows Java to run in less RAM by "concentrating" classes so that they take up far less memory.

The term "freeze-dried" in your title implies smaller (which is why we took it as a trademark) and more intense (concentrated). What JavaBeans actually offers is a packaging technology, putting the components you want in an accessible form.

A better analogy might be coffee bags, which contain plain old coffee, but include a built-in filter. You just drop them in a mug and let them steep. See, same stuff, with easier to use (more accessible) packaging, just like JavaBeans!

What do you think?

Richard A. Ross

TeleMedia Devices Inc.

Richard, Thanks for writing in. I certainly don't want to infringe on your trademark. Personally, though, I still believe that "freeze-dried" is a more direct (not to mention more euphonic) metaphor than "coffee bags." JavaBeans encompasses customization of running and serialized components; structured exposure of object properties; persistent storage; and event discovery, binding, delivery, and processing. In addition, JavaBeans offers a bridge to other component technologies and will soon include a runtime containment and services protocol (now in beta); beans-compatible drag-and-drop functionality; and the JavaBeans Activation Framework. So, JavaBeans is a lot more than a packaging technology. Because they don't contain the class bytecodes, serialized beans are smaller than their runtime memory images. As such, they're a more concentrated representation of the original bean (kind of like instant coffee). Just add a class file, and, voilà! An object instance. Nevertheless, your technology looks very interesting. I can certainly see how its wider availability could facilitate Java in memory-constrained applications. And I acknowledge your concern that my use of the term "freeze-dried" might be confusing to your potential customers. In the future, I promise to include a disclaimer that distinguishes my use of the analogy from your technology, and I'll include a link to your Web site if you send it to me. Best of luck with your worthy contribution to the Java movement. Mark Johnson

The best kind of praise

Mark,

I'm a tech writer for Actuate Software and the principal author of, among other things, the Actuate Basic Reference Manual. I'm also the author of an upcoming book.

I just wanted to tell you that I really enjoyed your article on persistence. I think you're an uncommonly fine writer.

Would you mind pointing me to a list of your other articles and books (not only in JavaWorld, but elsewhere) if you have such a list available?

Of course, if you don't have such a list, I'll just get off my lazy butt and go hunting around for your name.

Ray Simon

Ray, Thanks a lot! I really love to hear from readers who like my writing. I'm especially flattered that this comes from someone who writes for a living. I'm a programmer by trade, but aspire to writing and developer training for a living. As for a list of publications, check out JavaWorld's back issues for my JavaBeans columns. That's the extent of my published work, with the exception of some (fortunately pseudonymous) poetry in my high school literary magazine. Mark Johnson

"Microsoft takes wraps off Visual J++ 6.0" by Niall McKay and Bob Trott, InfoWorld Electric

Read

Distributed Computing Monitor editor in chief clarifies stance on WFC quote

Editor,

You'll be pleased to know that JavaWorld is widely read. I've received letters from all over the world in response to a quote published in a recent article, "Microsoft takes wraps off Visual J++ 6.0". One of the problems with being quoted in the press is that the quote never expresses my full opinion. Given that my comment has generated a lot of controversy, I'd like to take the opportunity to state my case.

I find myself in the unlikely position of defending Microsoft's Java initiatives. Normally I'm pretty harsh on them. Even so, I am fully in favor of WFC. WFC is a Windows-specific set of Java enhancements. Microsoft's Java technology license allows them, and even encourages them to build platform-specific enhancements, as long as the enhancements are clearly identified as non-portable proprietary extensions. WFC is absolutely in line with the spirit of the license agreement.

From my point of view Java provides two primary advantages:

  • It's highly portable
  • It's highly productive

I've always been an adamant supporter of portable Java -- 100% Pure Java, complete Java compatibility, plug-and-play components (JavaBeans, Enterprise JavaBeans), etc. I constantly beat up Microsoft over the non-compatible issues of JNI, RMI, JFC, and the locale classes.

But Java is not just about portability. I believe that Java is the best programming language available. It is more powerful than Visual Basic or other 4GLs. It is more productive and produces cleaner code than C++. I recommend that all development teams use Java for every development project unless there is some compelling justification to use another language. But for some reason, most of the world believes that Java is only useful for Internet-based development projects. I want the world to think of Java as a general purpose programming language.

So let's be pragmatic. Win32 is installed on approximately 98 percent of all desktops and a rapidly growing percentage of servers. If an organization intends to develop an application that will only be deployed on Win32, why does it need to be portable? Why would someone implement a client/server GUI in Java (VJ++) if the performance is so slow that you can watch the screen paint itself. WFC GUIs perform as well as C++ GUIs. Why would someone implement an MTS server in Java (VJ++) over VB if the VB application performs faster. WFC makes the performance issue goes away. Therefore, I believe that WFC will increase the use of Java as a general purpose application development language.

If I intend to build applications that will be deployed on multiple platforms or across the Web, then obviously I wouldn't want to use VJ++ or WFC. But if I intend to only deploy on Win32, then perhaps I might.

Java platform differentiation and exploitation isn't a bad thing, as long as the core JVM is fully compatible with the standard Java specification. Microsoft still isn't towing the line, and I will not stop harrassing them until they add support for JNI and JFC. But I'm not going to berate them for providing Windows-specific enhancements in conformance with their license agreement. IBM, HP, Digital, Intel, and most every other Java licensee are also implementing platform-specific enhancements. Platform optimizations and native compilers aren't a bad thing. I don't think WFC is a bad thing either. Users have the right to choose to develop proprietary implementations or standard portable implementations.

Regards,

Anne Thomas

"Java embeds itself in the control market" by Rick Cook

Read

Size and determinacy key to embedded systems

Rick,

I really enjoyed reading your article. As one of the engineers involved in embedded Java systems, I need accurate analysis and forecast information on how Java can be applied in the embedded arena and what needs to be done to make it happen.

It is amazing to see your broad and in-depth observation of the Java technology in the embedded arena. In particular, you pinned the fact that determinacy and size are the biggest concerns for those designing embedded Java systems. These problems concern me, but I think they may well be solved in the near future.

The size issue may be solved by Java CPUs, as you described in the article. I have reliable data showing that a complete JVM can be built within 100 kilobytes based on a Java CPU. This size, however, doesn't include any class libraries.

The determinacy problem, in my opinion, is largely an application issue, not a runtime environment issue. If you look into any realtime application, very little dynamic memory allocation and deallocation is happening; most likely, memory objects are statically allocated and remain resident forever. Garbage collection is a controllable, optional entity in a Java virtual machine; you can remove it if you don't need it.

Without garbage collection, a Java virtual machine may behave very similarly to other realtime systems, such that determinacy will no longer be an issue.

Chan Lee

Chan, Handing the determinacy problem off to the application is a traditional way of dealing with it. It's not a very clean method, however, and it means that every application -- and every patch -- potentially contains disastrous bugs. Further, while this method can work nicely when you've got, say, 8 kilobytes of total embedded code, it becomes more difficult when you've got 800 kilobytes of application-specific embedded code, possibly distributed over multiple processors. (And for some embedded applications today 800 kilobytes is small.) A lot of people do handle determinacy this way, but it's not optimum. Those who plan to migrate to innovative system software for embedded systems expect something better. Rick Cook

Java Tip 48: "How to create a reusable MessageBox class" by Jack Harich

Read

New MessageBox app to support blocking

Jack,

Nice tip, but how do I pause my Java application until the user has responded to the dialog? Obvious situation: User clicks on button, which generates ActionEvent. I create a message box and show it, but then I need to wait until the user has responded to continue my application.

Mike Lehman

System Architect

Mike, I've already modified my MessageBox app and will be updating the article to support blocking. Meanwhile, here's a copy of my production

MessageBox

class. It might not compile if it refers to classes you don't have, but you should be able to figure out how to extract what you need. Be cautious about blocking. Use it only when appropriate. For example, an error message dialog from a database query should not block, because that would (probably) leave the connection open until the user responded -- which could be awhile if her or she were out to lunch. Jack Harich

                                       * Same as ask(String message) except adds an "Okay" button.
                                       */
                                       public void askOkay(String message) {
                                       addChoice("Okay");
                                       ask(message);
                                       }
                                       /**
                                       * Same as ask(String message) except adds "Yes" and "No"
                                       * buttons.
                                       */
                                       public void askYesNo(String message) {
                                       addChoice("Yes");
                                       addChoice("No");
                                       ask(message);
                                       }
                                       //---------- Private Methods -----------------------------
                                       // Prepares but does not show the dialog
                                       private void prepareDialog(String message) {
                                       if (frame == null) {
                                       frameNotProvided = true;
                                       } else {
                                       frameNotProvided = false;
                                       }
                                       dialog = WindowMgr.createDialog(true);
                                       dialog.addWindowListener(this);
                                       dialog.addKeyListener(this);
                                       dialog.setTitle(title);
                                       dialog.setLayout(new BorderLayout(5, 5));
                                       Panel messagePanel =
                                       WindowLib.createMultiLinePanel(message);
                                       if (imageCanvas == null) {
                                       dialog.add("Center", messagePanel);
                                       } else {
                                       Panel centerPanel = new Panel();
                                       centerPanel.add(imageCanvas);
                                       centerPanel.add(messagePanel);
                                       dialog.add("Center", centerPanel);
                                       }
                                       dialog.add("South", buttonPanel);
                                       dialog.pack();
                                       WindowLib.enforceMinimumSize(dialog, 200, 100);
                                       WindowLib.center(dialog);
                                       Toolkit.getDefaultToolkit().beep();
                                       }
                                       //--- Std
                                       private static void print(String text) {
                                       System.out.println("MessageBox" + text);
                                       }
                                       } // End class
                                      

Spooked about deadlocking

Jack,

Thanks for your tip. This is my understanding of the deadlock problem from your article:

  • The AWT thread calls actionPerformed()
  • My code tries to pop a modal dialog, thus blocking
  • AWT can't show the dialog because I'm blocking it
  • I can't stop blocking it until AWT shows the dialog

If I'm wrong here, please explain.

Also, when will I ever be able to use a modal dialog, other than with the main thread?

The JDK doc (http://java.sun.com/products/jdk/1.1/docs/api/java.awt.Dialog.html) has this to say about public void show():

It is permissible to show modal dialogs from the event dispatching thread because the toolkit will ensure that another dispatching thread will run while the one which invoked show is blocked.

Joe Walker

Joe, In Java 1.1, modal dialogs start a new thread to show themselves. Thus in 1.1 the deadlocking no longer occurs. In 1.0 you need to show a modal dialog in a new thread if the call is from an AWT thread. You should have no problems. Sorry if I spooked you about deadlocking. Jack Harich

Class evasion

Jack,

In your MessageBox app there are two packages. When I ran this application, I typed

java COM.jconsort.ui.MessageBoxTest
                                      

but the ImageCanvas class (used in MessageBoxTest) belongs to another package, org.jcon.ui, and cannot be found and invoked. Please advise.

Thank you very much for your help!

Judy

Judy, Try commenting out the package names, putting them all into the same directory, and running from that directory. Jack Harich

Distributed Objects: "Java 1.2 extends Java's distributed object capabilities" by Bryan Morgan

Read

Distributed Objects columnist offers advice on CORBA and Java

Bryan,

I am a final year student of computer science. As part of one of my projects I'm investigating and implementing a database to be viewed through a Web brower using CORBA. I was wondering whether or not you would advise me on using Java -- applets and all -- for commercial use at the moment.

Gareth Griffin

Gareth, First of all, as part of your university project, I would definitely recommend pursuing a three-tier project using Java, CORBA, and a commercial RDBMS. From an educational viewpoint, it will help you apply much of the in-class information you've been receiving and you will receive valuable training in technologies the industry is clamoring for. As far as the feasibility of a client/server project using Java, you should be aware that hundreds, perhaps thousands, of projects are underway now at nearly every major corporation using these technologies. When developing a client/server application, it is important to analyze your choice in tools by looking at the whole system instead of each individual part. Java is a great programming language and it offers you the ability to build a platform-independent solution, with a tradeoff in performance. The fact that CORBA is endorsed by so many vendors, is truly standardized, and is available on a wide range of operating systems means that your middle-tier (the object server) can be very flexible in terms of product choice and implementation. If you choose to use Java as your programming language, you'll need to decide between an applet or an application. Applets are dynamically downloaded and displayed within the Web browser and are subject to stringent security restrictions. Further, the major Web browsers have many problems with Java 1.1 functionality and a CORBA/Java applet requires a large number of class files to be downloaded before the applet can actually start. So for now I'd go with the Java application. Developing an application will ensure that the user has the latest version of the JDK and CORBA packages installed and will also open up the ability to print and save to a file. Good luck and keep me posted on your progress! Bryan Morgan

Java Step By Step: "Write your own threaded discussion forum" by Michael Shoffner

Read

Michael,

I am writing an application based loosely on your wonderful forum example. I use a file that I've created with DataOutput to keep track of different documents floating around on the server, as well as the corresponding senders, dates. I'm hoping for your input.

Billy Perez

Billy, You ought to just model the app with classes and use object serialization to serialize the message objects to the filesystem. Try something like this:

Message  
                                       _________________
                                       String sender 
                                       Vector recipients
                                       Date date 
                                       String subject 
                                       ...            
                                       MessageBody body 
                                      

Then

MessageBody

could be made to lay out and display text, images, etc. (You name it.) Then you could make a custom AWT component that knows how to lay out messages and put that in place of the text area that's in the display right now. Hope this helps, Michael Shoffner

Book Review: "Java virtual machine books -- a comparative review" by Laurence Vanhelsuwé

Read

Source code not always filler

Laurence,

I enjoyed your review of JVM books. It was useful and well-written, and probably saved me 30 minutes at Barnes & Noble.

You seem to take the position that printing source code is almost always a way for lazy authors to up page count.

I'd like to weigh in for the opposing view. When we were putting together our book Programming with Java IDL (Wiley 1997), this was the most contentious issue we had to resolve amongst our contributors.

Some felt as you did, that it was a page waster and that people would rather look at the code in electronic form. The other side of the argument -- that the inclusion of source code is vital to any discussion of a program -- is what eventually carried the day, largely because I insisted upon it.

I have seen books where the source code was presented in a page-wasting fashion, and I've felt cheated by it. One particularly egregious example actually presented each line of each program in the book at least three times.

But in books that teach programming or programming techniques, presenting the source code in full is very important. It's valuable to step people through the interesting parts of each program, often with surrounding text -- the "snippet" approach. It's equally valuable to present the whole enchilada, uninterrupted, for reasonably short programs. The author is not omniscient, and it's possible that the code the author thinks trivial is the part the reader is having trouble with, in which case the reader desperately needs to see a working example.

On the practical side, I ride the subway to work and this is where I do most of my reading. Given my busy life, having the source code squirrelled away on a CD-ROM would mean that I would be left with text. No thanks.

Sometimes I think that my views on this subject are idiosyncratic, because a lot of people do hold your view that source code is a waste of space. But then I notice that people like Don Knuth, who spent years developing the Web integrated text/code system, and Gerald Sussman, who once said in a lecture that programmers should study good source code listings as rabidly and as completely as English majors study Shakespeare, seem to agree with me, and I rest more easily.

Steve Barber

Java Tips Q&A with John D. Mitchell

Read

So, you want to make a Back button? See Tip 15

John,

I want to create a Back button in a Java applet using the JavaScript history.back() method, but I don't now how.

Can you help me?

Roberto Santiago

Roberto, Check out Java Tip 15, "How to make a 'Back' button in JavaScript." Note that Java and JavaScript are quite different, and you will not be able to use the same methods in both. John D. Mitchell

Why can't I view my applets?

John,

I'm a software developer in New Delhi. We are just starting to use Java. We have made a few applets using standard component toolbars of Visual Café 2.0, Web development edition. We are able to view them in appletviewer, but are not able to view them in Netscape 4.02. We don't know why.

The browser says: java.lang.NoSuchMethodError.

Murty

Murty, I suspect that you are making use of Java 1.1x constructs -- versions of Netscape 4.x before 4.04 aren't complete implementations of Java 1.1x. Try upgrading. It also wouldn't hurt to read the manuals on Visual Café. John D. Mitchell

Resources, resources, resources

Read

Do you know about JavaWorld's topical index?

To the editors:

I know you have an index page with all Java Tips listings.

I would like to see a similar chronological list of all your published Nuts & Bolts tutorial articles (and why not other articles too?)

It's rather cumbersome to load and browse through the back-issues one by one.

Thanks for listening.

Johannes

Johannes, Perhaps you are not aware of JavaWorld's topical index, which will help you navigate our rich archives by topic (for example, "How-Tos and Tutorials," "Security," and "Java Virtual Machine"). Just go to http://www.javaworld.com/common/jw-topicalindex.html Thanks for reading JavaWorld! Jenni Aloi

Associate Editor

Links for beginners

To Bill Day:

Can you send me some useful links for a Java programming beginner?

Roman g. Tchessov

Roman, Thank you for your interest in JavaWorld. I've included a few references below, all of which provide useful information in addition to the content available from JavaWorld magazine. A good place for any Java beginner to start is JavaSoft's Web site: http://www.javasoft.com This site contains tutorials to get you started and pointers to tools and programming environments. From there, you can click over to the Java Developer Connection. Though the JDC requires a login, it's free and has a lot of additional early and "inside" information on Java tech. Another decent source of Java information and tutorials is the Cafe au Lait site: http://sunsite.unc.edu/javafaq And here are a couple more sources for Java information, particularly books: http://www.oreilly.com/java; and http://java.miningco.com Bill Day