Letters to the Editor (August 20, 1999)

Java Tips

'Java Tip 75: Use nested classes for better organization'

Ramnivas Laddad

http://www.javaworld.com/javaworld/javatips/jw-javatip75.html

Nested classes with JavaBeans -- a good idea?

Ramnivas,

I just read your article, "Java Tip 75: Use nested classes for better organization" -- a very good, informative piece. I have just one question regarding your use of nested classes for JavaBean events: Do nested classes mess up the JavaBean design pattern so that bean builder tools can't recognize the appropriate events and listeners?

Mark Kinzie

Mark, I looked at the JavaBean specification and found that the use of nested class/interface for events and listeners should not prohibit them from use in builder tools. Because a top-level nested class acts just like any top-level class, and because the JavaBeans specifications regarding events and listeners do not mandate any naming conventions, any JavaBeans component using nested classes should work just fine. The JavaBeans specification, however, requires that the

beaninfo

class provided by a bean must follow a naming convention (for example, it must be of the form

<BeanName>BeanInfo

). My suggestion is to still use nested classes for

beaninfo

classes (they really pass the test mentioned at the end of article) and have another top-level class extend it with empty body. For example:

public class MyControl { 
// listeners, events and beaninfo classes as nested types 
...
/**
* Nested class to provide beaninfo for the enclosing JavaBean.
* This class is not directly usable as beaninfo because
* it does not confirm to <BeanName>BeanInfo naming convention. 
* Create a top-level class with name MyControlBeanInfo and make
* it extend this nested class. Keep the body for 
* MyControlBeanInfo empty.
*/
public static class BeanInfo extends SimpleBeanInfo { 
//... 
} 
} 
/** 
* Bean info class for MyControl JavaBean.
* This class exists only to satisfy the JavaBean specification
* that requires a beaninfo class associated with a JavaBean
* be of the form <BeanClassName>BeanInfo.
* All real work is done inside the base class MyControl.BeanInfo
*
public class MyControlBeanInfo extends MyControl.BeanInfo { 
// empty body... 
} 
                                    

This way you can have your cake and eat it too. Ramnivas Laddad

Java Device Programming

'Program Java devices -- An overview'

Bill Day

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

Java 2 Micro Edition not quite ready

Bill,

I'd like to know where I can download the J2ME (Java 2 Platform, Micro Edition).

Maq

Maq, J2ME is a work in progress. It will consist of virtual machines, plus device- or market-specific profiles (APIs and implementations) built to sit on top of the underlying VMs. As of now, you can download Personal Java from the Sun Web site. This includes a classic VM, plus the implementation of the Personal Java APIs, a.k.a. the Personal Java profile. All this is available at: http://java.sun.com/products/personaljava/ Alternately, you can download an early preview version of the K virtual machine (KVM) for Palm devices from the KVM-interest mailing list archives. You can access the instructions for doing this, a growing list of KVM applications and tools, and a Java Device Programming FAQ with KVM tips, all from the KVM archive at: http://www.billday.com/KVMArchive/ (Note: No KVM-based profiles have been released at this point.) The best thing to do, in addition to keeping up to date by reading future Java Device Programming columns, is probably to watch the J2ME homepage for more information: http://java.sun.com/j2me/ Bill Day

KVM: Where to find information, tips

Bill,

When can the rest of the Java developer community get hold of the Palm V SDKs?

If there is any chance of influencing Sun by saying so, I'd be happy to pay the usual 0 or so for a CD.

As for your column, it would be interesting if you could provide information on how best to write really small Java programs for running on these devices.

Paul Freeman

Paul, In fact, several users on the KVM-interest group have posted copies of the JavaOne KVM and its development kit (SDDK) to the list. These are now archived in the KVM-interest mailing list archive on Sun's site. They can be downloaded for free, if you know where to look. For instructions on where to go, please visit my new KVM application archive: http://www.billday.com/KVMArchive/ There are several list members' KVM apps available in the archive as well, so you will have a few applications and a tool or two with which to get started. I hope to see many more list members submit their apps and hope to have many of the JavaOne Hackathon apps submitted as well. I hope the aforementioned archive can help you with tools as a starting point. For docs, one starting place is the SDDK itself, plus the KVM white paper (linked to from the KVM homepage at http://www.java.sun.com/products/kvm/, and from my archive). Bill Day

WAP vs. J2ME -- some information

Bill,

I'd like to express my great desire for you to summarize, in your opinion, the pros and cons of both the technical features and market opportunities for WAP (Wireless Access Protocol) as opposed to J2ME. It seems that WAP is available today on a variety of handheld phones, but is less functional and probably not very useful for set-top boxes.

Scott Zimmerman

Scott, I will certainly dig deeper into this in the mobile phone series of columns, but in general:

  • WAP is mobile phone/wireless communicator specific. This allows for some cool optimizations compared to HTTP/HTML, but it also means other types of devices cannot use it (absent is some sort of gateway or transcoder). Deployment looks to be quite widespread in the next generation mobile networks (millions of devices), but nil in other sorts of devices (set-tops, for instance).
  • HTTP/HTML is the Internet standard, which gives it all of the advantages in portability, interoperability, and so on with which we are familiar. And J2ME and the KVM will be available to make all sorts of different devices (phones, set-tops, pagers) Net-ready and capable of handling HTML.

These are two of the major high-level distinguishing factors. I will drill down into many more pros and cons in future columns. Bill Day

Java Toolbox

'Building user interfaces for object-oriented systems, Part 1'

Allen Holub

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

Allen Holub misinformed about MVC?

Allen,

I think you either misunderstand MVC or you are misrepresenting it in your article, "Building user interfaces for object-oriented systems, Part 1." In the article, you state: "This extract-data-then-shove-it-elsewhere approach requires you to know way too much about how the model-level objects are implemented."

But this is exactly contrary to actual MVC, where the point is to keep the UI from having to know too much about how the model is implemented. You give examples of dealing with Unicode and Chinese and multiple ways of representing some data element, but then you expect a single object to handle all possible representations of itself!

An object-oriented system should be, above all, a cooperative effort among its objects -- each performing its particular role. Therefore, it does not break encapsulation for a Widget to ask an Adaptor for some value in an understandable format and for that Adaptor to talk to the model object in its own lingo to get that value. MVC provides the architecture for making this type of collaboration easy and scalable.

And, speaking of scalability, I have seen these monolithic objects that understand how to do everything, which you suggest as ideal, built-in practice. They are definitely not scalable. If you truly want to build scalable systems, you have to learn to factor your objects into small sets of functionality (I agree with your suggestion to focus on functionality rather than data). These objects work together to accomplish a task. Then, when you have to display that piece of information in Chinese, you simply create a new DisplayRepresentation object (or whatever) and you have isolated the change to some new object without disturbing the other objects in the system. By not modifying preexisting (and presumably working) code, you have lowered your debugging and maintenance costs exponentially.

I hope that you do not continue to slander the good name of MVC by suggesting that in any way MFC or Visual Basic or JBuilder or Cafe are implementing MVC. To paraphrase your own words:

"Don't be fooled, by the way, by products billed as using 'MVC' or by claims that 'there are lots of ways to define MVC.' Translate this sort of marketing hype as follows: 'Our product isn't really doing MVC -- we know that, but you probably don't, and your manager (who's making the purchase decision) almost certainly doesn't -- so we'll throw up a smoke screen and hope nobody notices.'"

Ron

Ron, I did not say that an object has to know how to handle all possible representations of itself, though I did argue that within the context of a specific problem domain, the set of reasonable representations are usually quite small (that is, one). The notion of "possible representations" is irrelevant. In any object-oriented design that's done right -- starting in the analysis phase with a well-defined problem statement and modeling of that problem statement -- you are modeling a very restricted problem domain, not the real world in all its richness. As a consequence, I/O choices should be limited to the choices mandated by the current problem domain. The object should be able to accommodate other environments, of course, but that's a very difficult problem in the real world. I don't really believe in the notion of a "component architecture" except in the context of trivial implementations of such things as widgets. I simply don't believe that a key analysis-level abstraction like "Employee" can be modeled in such a way that it can be plugged into every program that anyone who needs an employee abstraction will ever write. I'll talk more about this in next month's column. I really do believe that MVC doesn't scale well to classes larger than widgets. The architecture that I use is called Presentation/Abstraction/Control. It's written up reasonably well in Buschmann's book, Pattern-Oriented Software Architecture: A System of Patterns (John Wiley & Sons, 1996). Allen Holub