Letters to the Editor (July 20, 1999)

Bill Day responds to a Jini request based on his Java Device Programming column; a reader takes issue with Geoff Friesen's 'The Win32-Java hybrid,'; Allen Holub's thought-provoking column, 'Building user interfaces for object-oriented systems,' garners thought-provoking commentary; and Bill Venners and a reader trade views about objected-oriented theory as it applies to Jini.

Java Device Programming: 'Program Java devices -- an overview,' by Bill Day


Java Devices: The Jini focus


I am primarily focused on how Java Device Programming relates to printing. You paint a pretty picture of how a digital camera could hook up to a home network and then print to an attached printer with Jini. It's mostly a lot of smoke and mirrors at the moment, but it's a pretty powerful concept.

Dean Pulsifer

Dean, Here are a few suggestions to get you started or further along. First, JavaWorld has a new column dedicated to Jini, Jiniology, by Bill Venners. The first installment, "Jini: New technology for a networked world," was published in June: http://www.javaworld.com/jw-06-1999/jw-06-jiniology.html I also wrote two Jini articles in my coverage of JavaOne. "The state of Jini technology," (JavaOne Today, June 1999) is a technology-oriented update: http://www.javaworld.com/javaone99/j1-99-jini.html The other, "Join the Jini community," (JavaWorld, July 1999) is all the information a Jini developer needs to know about working with the Jini community, aggregated in one place: http://www.javaworld.com/jw-07-1999/jw-07-jinicommunity.html Furthermore, be sure to check out the resource sections of each of my upcoming Java Device Programming articles. There will be some good URLs in there. Bill Day

'The Win32-Java hybrid,' by Geoff Friesen


Reader is upset about 'pure Java' and Windows; Geoff Friesen responds


I read your "The Win32-Java hybrid," article with interest because I'm doing some public domain work in this area. The article, I must say, was neither helpful nor informative. In fact, it may be dangerous for people who don't understand what's going on to use the techniques mentioned.

I'd be happy to write a much better follow-up article about the virtues and dangers of JNI, and how to use it correctly, while maintaining the 100 percent Java spirit. In fact, I have a Web site dedicated to it. Check out http://www.goman.co.il/jni.

Tal Lyron

Tal, I want to thank you for writing and expressing your opinions. Letters help to keep authors (such as myself) on their toes. I want to make it perfectly clear that I support Java's cross-platform mandate; I believe in the write-once, run-anywhere concept. I don't believe that Java should be subverted by having a version of it that specifically targets Windows, as Microsoft's Visual J++ 6.0 is designed to do. So why did I introduce my article about a Win32-Java hybrid? This article was a response to Visual J++ 6.0. That product was designed to subvert pure Java by introducing additional language keywords, providing different class implementations, and supporting the Windows Foundation Classes at the expense of Swing and AWT. I wanted to show developers that, if they need to develop Windows applications with Java, they should stick to a mixture of pure Java for the application and C++/JNI for the EXE. There is nothing magical or earth-shattering about the Win32-Java hybrid. It's just a name for a technique that shows how to build an EXE that can launch a virtual machine and run a Java program. The java.exe program does the same thing. And although I targeted Windows, the same case could be made for writing hybrid programs under the Macintosh, Unix, or other Java-supported OSs. So what's so terrible about writing a Windows application using Java as opposed to C++? I would think that Java developers would view this as a way to slap Microsoft's face and say, "Who needs MFC when we can use Java?" I personally prefer the Java language to C++. I find it simpler, more robust, and more enjoyable to work with. If I'm going to write a Windows application, I can save a lot of time and debugging trouble by using Java. Of course, I can't do everything in Java that I can do in Window, because Java was designed to be used in a cross-platform environment. Still, I can take advantage of the Java Native Interface to do things that cannot be done in pure Java. To summarize, Java should not be polluted (such as was done in Visual J++ 6.0). I believe in the cross-platform mandate of Java. However, because I prefer Java to C++, I feel that it's possible to build Windows applications using a mixture of C++/JNI for the EXE part, and pure Java for the class files part. I'm sorry that you did not find this article helpful or informative. I have received e-mails from other developers who have found this article to be quite helpful. I guess it's all a matter of perspective. Geoff Friesen

Toolbox: 'Building user interfaces for object-oriented systems, Part 1,' by Allen Holub


Object-oriented programming: reinventing the wheel, or getting back to basics?


Talk about reinventing the wheel -- this is exactly the process that any self-respecting system designer used back in the old days. Starting from the requirement for a defined set of inputs to produce a defined set of outputs with a black box in between to carry out the process, we were taught to partition a problem into subsystems using common interfaces -- and, if a new one became necessary, to make it as generic as possible. What went on in the box could be either hardware or software, or little green men using hammers. This was true in the days before computers as we now know them, back when we were working with hardwired circuits and analog structures using discrete components in racks the size of cupboards. It is encouraging to at last see someone return to first principles.

Alan Hartley-Smith

Jiniology: 'Jini: New technology for a networked world,' by Bill Venners



Jini and correct object-oriented design


There is a very good JavaWorld article, entitled "Building user interfaces for object-oriented systems, Part 1" by Allen Holub (July 1999), which I consider extremely valuable for anyone who is interested in UI design. Some points of this e-mail are based on this article:


Based on my understanding of Allen's piece, I believe that every object that interacts with the user should have its own UI, by which I mean an interface provided for the user. (Of course, objects that don't need to communicate with user can do without one.)

Note that "every object" is not limited to services only. Please refer to Allen's article for details on this.

I believe that the correct approach to creating an object-oriented UI (OOUI) would be to ask an object, "Draw yourself on somewhere" -- but not to ask an object, "Tell me all the information you have," and then construct some UI to display the received information. Remember, set() and get() methods are evil.

I believe it is also wrong to ask an object, "Give me your UI," and then display the received UI to the screen. Why should I do the job for the object instead of stepping back and allowing it to do its job by itself?

Based on my understanding of OOUI, I have some questions/suggestions about UI for Jini. I should say that some of my questions/suggestions follow Allen's proposed tailor metaphor.

First, suppose a client calls a service, and this service has its own UI (for example, JFrame). Now, the client tells the service, "Start yourself." The service then shows its window to the screen and communicates with the user, a human.

In this scenario, the client does not need to know what kind of UI the service provides. In fact, the client should not care about the UI of the service. If the client asks the service to give a UI and then the client shows the UI to the screen, this is, I believe, an incorrect approach. The client should only ask the service to do something, like "Start" or "Stop."

Now, consider another scenario. Suppose there is an object that doesn't have a window, but still has its own UI -- a textbox UI, for example.

A client calls this object. The client passes a window to the object, and says: "Draw yourself in this window." Then the object puts its textbox on the window and the data of this object is shown on that window. This approach is exactly what Allen proposed -- the tailor approach.

When the client says, "Draw yourself," the client may also tell the object what it wishes the UI to look like. (A customer can tell the tailor what he wishes his clothes to look like.)

However, it is the right of the object to decide the implementation. (The tailor has the right to decide how to make the clothes. Hence, the final look of the clothes is in the tailor's hands.)

Also, the object can ask the client a second time for more information -- screen size for example. (The tailor can ask the customer for additional information.)

Any comments or objections?

Phong Yau

Phong, I have a several comments. One of the things that Allen states as an objection to his OOUI ideas is "...different views into the same object, usually characterized by the question: 'Suppose you need to display this data as a pie chart over here and a grid over there?'" Allen continues, "Now let's get real. How often in your work has this problem actually come up? The fact is that data has meaning -- it's not just an arbitrary collection of numbers. For a given set of data, I would argue that there is only one 'best' way to represent it for a specific problem domain. If there is no 'best' way, then settle on one 'good' way. This degree of flexibility is rarely required." I, however, think serviceui is one area in which this degree of flexibility


required. A service object may land in lots and lots of different kinds of client hardware with lots of different UI capabilities. A user may want to use the same service via his or her desktop, via a palmtop, via a pager, or over the phone. All of these ways in which a human can interact with the same service represent different UIs for that service. To be able to ask a service object to present itself to a user, the client would need to either:

  1. Provide a callback mechanism that enables the service to query the client about its capabilities and the user's preferences; or
  2. Pass information to the service indicating its capabilities and preferences

To me, approach (1) is like me walking into a restaurant but not looking at the menu to I decide what I want. Rather, the waiter comes up and starts asking me questions about what I like and so on, and then brings me something that may or may not suit me. Approach (2) is indeed the tailor approach. The trouble there is that it is difficult to express everything you are looking for well enough to allow the service to decide what is right for you. The current proposal takes a halfway (shopper) approach, where the client expresses to the service (via the lookup-service methods) what interests the client. The client then potentially gets back a list of UIs, which it can sort through to make a decision about what would be best for it. Now, questions about how that UI is implemented -- or even whether or not every object has a UI -- are not really determined by the serviceui proposal. All you really get with that proposal is a UIFactory. I agree 100 percent with Allen when he says that objects should be designed in such a way that they offer services (he calls them capabilities) to clients, rather than merely being repositories for data. My idea of a UI is more of an adapter object that allows the Jini service (a bunch of capabilities) to be accessed by humans in some (not necessarily graphical) way. The factory could, in fact, ask the service object for a UI if it wanted to. However, this has a problem unique to the Jini world. The trouble with a service object knowing all the UIs it offers is that we want to avoid eager downloading of class files for all possible UIs when loading just the service object into a client. Given the way the JVM spec allows eager class loading, the fact that Jini service objects will usually be coming across a network means that JVMs on some clients may download across the network all class files referred to by a service object before that service is ever used. Thus, it is better if Jini service objects know nothing of the UIs that may adapt them for direct human use. I would expect that, if a UI needs more information than is available via the methods of the service object, access to such information should be available at the package-access level, so just friendly UI objects could get at it. Plain old clients would not be able to see the friendly methods, and to clients, the service would appear as a bundle of capabilities, not a bundle of data. But frankly, if Java code can't get at the information, why would it be shown to a user? In most cases I can think of, a UI object should not need any special privileges that aren't available to regular Java code that directly uses the normal service-object interface. Bill Venners