Real World Java
Written by Shai Almog
[NOTE: Here is a link to a zip of the source code for this article. Ed] A friend of mine recently went over some resumes which arrived at his office and found out that one of the applicants listed under programming languages: C++, Visual Basic, Word and Powerpoint!
This was a matter of great amusement to us. Many people want to become programmers since they assume that anyone who knows the language can write the code, but we all know that it is more than that. The slightly obvious but desperately needed Java coding standards at http://www.AmbySoft.com/javaCodingStandards.pdf begin with the cute phrase:
A good developer knows that there is more to development than
I don't think any of us would write that we have programming experience in MS-Word on our resume but we can show lack of experience when developing real world applications.
A recent Java article in Byte describes Java as the child prodigy which can play a beautiful Rachmaninov yet is still not potty trained, the potential is there but it is still an infant.
I am now working on two Java projects. Both projects are 100% Java (no native code) and require a fast compiler, hopefully by the time they reach the market there will be better compilers.
Both projects are still in the very early stages of design and are not fully formed yet.
In the months to come I will cover the development of these 2 projects from inception, choice of tools, OO design and to the final product.
Why do I think you should care? There are quite a few Java success stories, but most of them revolve around Sun and are early development projects. In the course of my development I will examine the problems facing Java developers in today's real markets.
I would appreciate your feedback, if you spot mistakes in the conceptual or technical level or if my explanations/conclusions were not clear. It will be very helpful to tackle these problems in the development stage rather than during beta testing.
My most basic toolbox: Don't do Java without it!
I remember reading once that programming is different from every other profession because programmers develop their own tools unlike a carpenter (for example) who does not develop his own hammer. I don't agree with that suggestion (but that's irrelevant). This is a list of the tools I will use to develop these projects. It is not complete and I am testing new tools all the time.
I will probably add many tools as I go along, most noticeably I neglected to mention a storage system or an ORB (RMI or Corba). I am considering using an object database (http://www.odmg.com), and I am testing a product by poet (http://www.poet.com). The poet product seems very promising and if it will run under OS/2 I will probably start using it. Both of the products I am working with don't need any distribution features but they could benefit from their implementation, so I am examining Visigenic ORB (which ships with Netscape 4 and suite spot). I will probably not use RMI.
Anyone who was ever involved in a large scale project knows the importance of development rules to maintain a consistent code appearance, thus simplifying the work of maintainers. AmbySoft's coding standards at http://www.AmbySof.com/javaCodingStandards.pdf are OK (although very basic) and I will try to stick to them in my development.
However I do intend to divide the entire code into packages (the hierarchy of which I have not yet finalized). Sun originally standardized the commercial package name to begin with COM.companyname but they will change that with JDK 1.2 to com.companyname.
I use some rules myself (in addition to AmbySoft's rules) which are specific to Java:
I believe in design by simplification: I divide a large complex task into a group of smaller tasks which are simpler to perform, thus when designing the visual side of the first project I decided to build it out of beans. I am now developing the beans for the first project which will be 90% of my work on that project.
My second project is very VM specific and is quite complex. I am designing the class hierarchy and building the most basic classes at the moment.
There are a few CASE tools for Java but I chose not to use any of them since the programs being developed are not well suited for CASE tools.
When developing a Java design spec you must remember the open nature of Java programming. It is not unlikely that some programmers may want to make use of your program in their application. Now that I am writing my design specification I try to make it into a manual for the application and it could in the future be just that. There is no reason to do the job twice.
When designing a Java application be sure you understand what Java is all about! Corel made a mistake of trying to copy their C++ experience to the Java realm, their Java suite was painfully slow and light on features. A Java application should have the same features as a Windows application but those features need to be dynamic. The application itself should be as minimalist as possible and manage all the extra features dynamically.
The applet question
Should we write the program so it could run as an applet? I never really liked applets, they used to be slow and they lacked any useful feature. Netscape now supports signed applets and has Symantech's JIT compiler inside, this allows us to write the applet as if it was an application.
I feel that a good Java application will be able to run as a very small applet on the client so today I believe that a good Java developer should develop an application and think of an applet.
Instead of building a large JAR file containing all your class files in one mesh, separate your code into the client and the server. The client should strive for small speed and size and the server should strive for functionality. Using this and a good distributed objects policy you should be able to make every application an applet and shift to the realm of robust client server development.
Are applets useful? They might be. The network computer hasn't caught on yet but many users may want to sample your application: what better way to sample it than with an applet. The problem with many of the early Java adopters was that they did not understand Java and developed large (600K+) applets. Your application should not care whether it is running under Netscape or the JRE, it should be a small client and the server can be local or remote, and this should be invisible to the user. Many users already have Netscape but don't have the JDK or the JRE, an applet could be excellent for them since they will not have to download the full JRE code. When running locally applets have very few security limitations.
Programming in Java
I am currently working on a large C++ project and I find the change to Java to be a dramatic change in the way I think when developing patterns: In this large C++ project, the entire project is one huge mass of objects coupled together very tightly. (This is essential for speed purposes in this particular product). In my Java projects I try to make the objects as individual as possible, my patterns include many times the Class.forName() method which dynamically loads the class and thus removes the dependency for modifications in the class. Dynamically allocating classes allows me to break apart my application when needed, which increases my code reuse, eg:
When handling Component based events in my application I name the Components (using the Component.setName() and Component.getName() methods) and when an event is triggered by a Component I try to load the class whose name is in the getName() for the component which triggered the event. I usually prepend the event's package name in front of the class name.
When the event is invoked it searches, using the Class.forName() method, the class which has the same name as the name of the Component, creates an instance of it and invokes the methods setObserverClass and then the actionPerformed method on it. The class must implement actionListener (or any appropriate event interface) and the DynamicEvent interface.
This pattern solves the following problems: