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

Related:
1 2 Page 1
Page 1 of 2