Letters to the Editor (September 3, 1999)

Java 1.1 Tutorial

‘Replace 1.1 event adapters to build better apps’

Mark Roulo

http://www.javaworld.com/jw-09-1999/jw-09-adapter.html

Mark Roulo clears up code comment confusion

Mark,

I enjoyed your JavaWorld article, but I am a bit confused by the following code comments:

// This is null if actions should be handled on
// their own threads and non-null if events
// should be handled on the AWT thread. See actionPerformed()
// and setAsynchronousHandlingEnabled() to see how this works.
//
private AsynchThread awtThreadObject;
/**
* Construct a new SophisticatedActionAdapter object that
* handles ActionEvents on the AWT thread.
*/
public SophisticatedActionAdapter ()
{
awtThreadObject = new AsynchThread(null);
}
                                    

Given the comments on the awtThreadObject field, it seems to me that the above constructor creates a new SophisticatedActionAdapter object that handles ActionEvents on its own thread, not on the AWT thread. Do I misunderstand you?

On another note, I am surprised to see that your default handling example for errors uses a GUI. Won’t that be problematic in server-side code? Is there some way your code could check to see whether a GUI is running, and only then display the error in a frame?

Ramon M. Felciano

Ramon, I think you do misunderstand just a bit. I create an AsynchThread object, but since I’m calling its AsynchThread method instead of its start() method, no extra execution thread is created. If you look at the dispatch methods, you’ll see that one part of the if calls run and the else part calls start. To answer your second question: yes, the GUI will be problematic in server-side code. This is why the design allows for the programmer to install a different handler. The default needs to do something, and since listeners are frequently used for GUIs, a GUI in the default handler seems reasonable. As for whether the code could check if a GUI is running, the answer is no. We haven’t been able to come up with anything at my office, at any rate, and we’d like to do so because we want our unit tests to be command-line driven, even though our application is GUI driven. Mark Roulo

Java Toolbox

‘Build user interfaces for object-oriented systems, Part 2: The visual-proxy architecture’

Allen Holub

http://www.javaworld.com/jw-09-1999/jw-09-toolbox.html

Will Allen Holub’s visual-proxy architecture work for complex interfaces?

Allen,

I’m sure you’re getting lots of mail on this, so I’ll try to be nice. What I don’t understand from your article is how you can construct an interface with even a moderate amount of complexity using this design pattern. I have constructed windows that contain 20 or so object classes; the same windows would have had two to three times more using your design methodology. There are many GUI behaviors on these windows that transcend the “single attribute” focus of your design pattern. Some of these complex behaviors include:

• Dependent drop-lists (the contents of one drop-list depends on the selection in another)
• Fields that change state (i.e., from read-only to editable) depending on some other object or system state
• Edit/undo capability (at a multiple-object level)
• Complex database transactions
• Complex database caching
• Synchronized tab folders

I could go on and on. The key question, I guess, is this: since each attribute’s widget is opaque (it’s a generic JComponent), how can I coordinate behaviors between multiple widgets? For a simple CRUD form I think your pattern probably works great. I don’t see, however, how it extends to cover more complicated windows with more complicated behaviors. I’m sure you’ve encountered situations like the ones I described. How do you handle them within your design pattern? Kevin Klein

Kevin, Please don’t think that I claim that a visual-proxy architecture can solve all the problems of GUI design, or that any single architecture can do so, for that matter. Design patterns solve specific problems, and this one is useful for solving certain classes of UI problems. I have built quite complex interfaces with the pattern, though, so I know it’s possible. Many of the issues that you bring up are certainly valid concerns, but I’ve found that many of what you characterize as control-interaction problems are actually model-level interaction problems. The UI talks to model-level objects, which work out the problem amongst themselves and then update their UIs appropriately. Dependent drop-down lists, for example, are often the result of the state of one model-level object being dependent on another, and this conversation can (and indeed should) occur at the model level, not between controls. Other problem class issues can be handled with a negotiation strategy, which I plan to discuss in my November column. Allen Holub

Java Device Programming

‘Program Java devices — An overview ‘

Bill Day

http://www.javaworld.com/jw-07-1999/jw-07-device.html

Advice for new Java programmers

Bill,

I am an engineer working in Singapore, and I plan to move into Java programming. Can you explain what Java skills will give me an edge compared to other Java programmers?

Shivakumar Balasubrama

Shivakumar, As you have no doubt observed, the technology landscape has shifted a great deal in the last few years. As the computing world has become more network-centric and media rich, Java technology has shifted and expanded along with it. Two or three years ago, the Java platform (Java 1.0, in the form of development kits in the JDK 1.0.x series) was still small enough that, when people asked me what they should focus on to learn Java, I could say with reasonable assurance: start with java.lang, java.util, and the other core APIs detailed in Java in a Nutshell by David Flanagan (O’Reilly, 1997); back then, this allowed you to build a decent expertise over time with all of the APIs included in the Java platform. Oh, how times have changed! In 1997, the Java 1.1 release added several additional core APIs, and Sun began to release some important extension APIs. Some of the more critical enterprise-related technologies to emerge were Java Database Connectivity (JDBC), Java servlets, database access, and Web programming APIs. For better or worse, there has been a continuing explosion of Java APIs over the last several years. The wide availability of the Java 2 platform in 1999 has added a great many more API packages to the core. In parallel with this process, a number of additional extension APIs have also been released. JDBC and servlets are still important enterprise APIs for programmers, but they have been absorbed into an ever-expanding set of Enterprise Java APIs, now a part of the Java 2 Platform, Enterprise Edition (J2EE). And on top of all of this, we have seen new initiatives such as Jini technology, a distributed service-centric computing model based heavily upon Java and the underlying infrastructure of ubiquitous Java Virtual Machines (JVMs). Given the dramatic increase in APIs and functionality in the Java 2 platform and related technologies such as Jini, where should you focus your attention? I would say the same advice still applies: get a firm grounding in java.lang and java.util, JDBC, and servlets for most any type of enterprise-oriented software development, then proceed as needed into the other areas and APIs. Once your understanding of these core Java and enterprise technologies is strong, I recommend exploring Enterprise JavaBeans (EJB) further, as they play an increasingly important role in server-based Java development. After you are comfortable with core technologies and EJB, you should be able to learn additional APIs, such as those for 3D graphics (Java 3D), CORBA access (OMG CORBA packages), or Jini technology (Jini development kits and public projects at https://www.jini.org/), without too much extra trouble. As with all things, focus on the basics, and they will serve you well. Java in a Nutshell, in an updated form, still sells for a very good reason — the basics are still important. As a final note, all this assumes that you have some expertise with good object-oriented design and programming practice. If not, I also suggest some work on those fronts, and perhaps dabbling a little bit in the Unified Modeling Language (UML) and software engineering patterns as well. Look at Rational’s UML site, and tools such as Together/J, for the former, and the venerable Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma and others (Addison Wesley, 1994) for the latter. Bill Day