Letters to the Editor

"Enhance Your J2EE Presentation Layer"

Joseph Shomphe

What's the advantage of Flash?


You contend that the applet solution is at a disadvantage to Flash because it requires the user to install a Java runtime. Doesn't the Flash solution also have this limitation? Doesn't the user need Flash Player installed? It seems like the Flash Player and the Java runtime share the same role.

Alex McCarrier

Alex, You are definitely correct about the client system requiring pre-installed software. The advantage of Flash over Java is twofold:

  1. According to Macromedia's figures, about 98 percent of all browsers have Flash already installed (see http://www.macromedia.com/software/flash/survey/whitepaper/page8.html for more information)
  2. Macromedia Flash Player 6 is extremely small: download time estimate is one minute with a 56 K modem, and the file size is 404 KB

Joseph Shomphe

Flash and JMS


Does the Flash MX client support Java Message Service (JMS)? In other words, can a Flash MX client subscribe to a topic and dynamically receive data without requesting it?

Konrad Hernblad

Konrad, The Flash client does not really support any Java APIs. Flash Remoting allows you to invoke an exposed Java 2 Platform, Enterprise Edition (J2EE) method, and the results return in a Flash native format via an asynchronous callback method. The flow for a Flash-to-J2EE method invocation looks like this:

  1. Flash client sends an asynchronous message over HTTP to the Flash Remoting application installed on a J2EE application server
  2. Since this message is asynchronous, the Flash application can continue without waiting for the result from the application server
  3. Remoting application unmarshals the request and synchronously invokes native Java method
  4. Java method is called and returns results to Remoting application
  5. Remoting application converts and marshals results to Flash client
  6. Since the method call was asynchronous, the Flash client gets notified that results are ready for the initial message, and the callback routine is invoked on the Flash client

Since Flash Remoting is inherently asynchronous, you can easily call a long-running method on the J2EE application server at any time. The Flash client will automatically be notified when the method completes. This assumes, however, that the Flash client initiates the transaction. In your case, you need the opposite: the server calls back to the client without ever invoking a method. What are your reasons for using JMS? Can you describe your application a bit more? Joseph Shomphe


Thanks for your reply and detailed explanation. I am working on a type of intranet solution that will allow clients to listen to messages on a certain topic. With JMS and Swing, it is fairly easy, but Swing graphical user interface (GUI) development can sometimes get hairy in terms of code management. All IDEs use proprietary markers and so forth to manage their auto-generated code, so it might be difficult to switch IDEs later. Also, Flash apparently has a lot of components you can use to easily make nice screens and effects, whereas Swing might require custom building those components as GUI beans if they don't exist.

In sum, it seems like GUI development would be easier to some extent with Flash, but having to learn another (scripting) language (perhaps not 100 percent object oriented like Java) and the inability to receive JMS messages might persuade me to continue pursuing the Swing-based approach.

Konrad Hernblad

Konrad, I have a few other notes. ActionScript (the language used to develop Flash applications) is object oriented. I found it very similar to JavaScript. If you already have a good working knowledge of Java, it may not make sense to take on a whole new language and environment at this point. I suggest only using Flash if your company has developers already familiar with ActionScript and Flash. With anything new, there is a learning curve. Joseph Shomphe

Java 101

"Tools of the Trade"

Part 1: Discover the world of Java tools by exploring Jcreator

Part 2: Jtest statically and dynamically analyzes your Java code

Part 3: Install your Java programs with InstallAnywhere

Jeff Friesen

Why InstallAnywhere only?

I appreciate your walk-through of deployment strategies for Java applications, but I felt "Tools of the Trade, Part 3" was an advertisement for InstallAnywhere. I would have appreciated if you could have compared InstallAnywhere capabilities with other tools like Ghost Installer and InstallShield Multiplatform Installer.

If your only intention was for readers to understand the deployment concept and issues with Java SDK lacking support for deployment, then I would not have devoted an entire article to InstallAnywhere.

I have used more than one installer in my career, and I was a lead developer for a deployment tool. I have been writing Java applications for about five years.

Syed Tanveer

Syed, The purpose of the three-part "Tools of the Trade" series, which focuses on the JCreator, Jtest, and InstallAnywhere tools, is to provide introductory tutorials on three useful tools that simplify Java software development, testing, and installation. Although my enthusiasm for each tool undoubtedly leads one to think I am simply advertising the tools, this is not the case. I like your idea of comparing InstallAnywhere with tools like Ghost Installer and InstallShield Multiplatform Installer. Such a comparison may appear in a future Java 101 article (or at least in the InstallAnywhere article's companion study guide). Discussing the deployment concept and issues with the Java SDK lacking support for deployment was only a small (but necessary) part of the article. Jeff Friesen

"Migrating Java Applications to .Net"

Nitin Nanda and Sunil Kumar

More on the matter

I was disappointed by your article on migrating to .Net, as it seems to cater to only people who developed code in J++ (I assume no one else uses JDK 1.1.4 anymore as it is five years out of date). The great majority of Java developers today use JDK 1.3.x or 1.4.x.

My company has developed Java software and, should the demand arise, could be interested in porting some of it.

The specific subjects I would have liked you to address are:

  • Conversion from Swing: Our software heavily uses the MVC (Model-View-Controller) aspects of Swing (i.e., we manage the models, and the screen follows). We use all the event interfaces, including drag and drop.
  • Classloaders are used intensively to allow us to hot swap jar files without stopping the application. This is used more and more for applications that need to run 24-7.
  • Remote Method Invocation (RMI): All communications are handled using RMI.
  • Security: We base our security on the Java security and Java Authentication and Authorization Service (JAAS) frameworks, in some cases using Kerberos. Some data is encrypted using the Java Cryptography Extension (JCE).
  • Java Database Connectivity (JDBC) 3 enhancements.
  • Enterprise JavaBeans (EJB): We communicate back to application servers. I suppose this comes down to the RMI problem.

There are also a number of minor issues, but if the previous ones were treated, the issue would be less hazy.

Ian Griffiths

Ian, The article's objective was to provide a starting point for migration of Java applications as well as Visual J++ apps using automated tools. I agree that the majority of Java developers use JDK 1.3.x, but these tools can still be used to migrate Java applications. The advanced concepts you mention are beyond the present article's scope. We chose a simple sample application that had data access through JDBC, a user interface, and used Collections. We wanted to present a high-level picture of how to convert applications, generate upgrade reports, and manually correct code from the upgrade reports. Nitin Nanda

"Big Designs for Small Devices"

Ben Hui

Is MDisplayable mandatory?

I have no experience with Java 2 Platform, Micro Edition (J2ME)/Mobile Information Device Profile (MIDP), but I am interested in this area. Your article presented four interesting design patterns.

However, for the Cascading Menu pattern, I don't understand why you need a second interface called MDisplayable. If you are familiar with the Gang of Four patterns, two patterns would be particularly applicable in your situation: one is the Command pattern and the other is the Composite pattern.

The CommandListener interface provides the command interface, and your MenuElement should be a composite (you can define another interface for your addChild() methods), which also implements a command interface (CommandListener in this case).

If you combine these two patterns, MenuElement can be treated uniformly, and each MenuElement (e.g., ShopMenuElement and RestaurantMenuElement and all their submenu items like BooksMenuElement and DinerMenuElement) implements its own commandAction() methods so that all those tags and cases (if/else) will be removed. This will be much more maintainable and extensible.

Perhaps I've misunderstood J2ME/MIDP; otherwise, wouldn't this be a more object-oriented solution for your pattern?

Ray Ye

Ray, Allow me to further explain the usage of MDisplayable. Many mobile applications operate in two modes: navigation mode and information mode. In navigation mode, users drill down the menu system until they find an interesting topic (e.g., Main Menu -> Restaurants -> Diner). This is where MenuElement applies. Each instance of MenuElement represents one menu screen. You suggested implementing each screen in its corresponding class (e.g., RestaurantMenuElement for restaurant screen). The benefit is that this is a very structured design, but the downside is the overhead of many class files (size) and development maintenance. The MDisplayable interface is designed for the second mode of operation: information mode. When a user selects a topic of interest (e.g., Diner), the application will likely display a content page (e.g., a restaurant directory). This piece of content is not structured as part of the menu system; thus, it is not a MenuElement. It could be a TextBox, a Form, or even a Canvas screen. By implementing the MDisplayable interface, developers have the flexibility of choosing the type of screen and can receive notification from MenuElement that it is selected by the user (via the onDisplay() method). Ben Hui

"Get the Inside Track on J2EE Architect Certification "

Humphrey Sheil

Is SCEA biased?


I've been preparing to take the Java 2 Platform, Enterprise Edition (J2EE) architect certification exam for almost two months now and am amazed by how much I've already learned. I'm sure taking Part 1 will be OK, but what really scares me is Part 2. In Part 2, you must communicate your solution. You state that this section needs to be very clear, and you should avoid typos. I'm French, so English is not my mother language. Communicating my solution in English will be very difficult for me. It makes me think that SCEA (Sun Certified Enterprise Architect) certification is made for Americans. Too bad the exam is in English only, but I'll give it a try anyway.

Christophe Thepaut

Christophe, By typos, I'm talking about a candidate spelling the same component differently in multiple locations, which is sloppy in French, German, or English. I take your point in regards to English being the only supported language, but I believe that if you take the time and use tools like a spell checker, your submission should be understandable. In addition, the UML diagrams are very important in Part 2—and they transcend language barriers. For Part 3, where you cannot use a dictionary, remember that the questions are designed to test your submission, not your command of English. So if you understand your submission and review commonly used J2EE and architectural terminology before going in, you will find it easier to formulate a clear response to the questions posed. Humphrey Sheil