Brennan’s Blog

No Fluff, Just Stuff was a great conference. Thanks to Jay Zimmerman for putting on a great show. It was great because of the critical and sometimes negative comments that came from the expert panel. I have seen other conferences where it is just a lovefest which tends to generate a reality distortion field which causes everyone to ignore the issues that need to be addressed. The expert panel openly discussed them and coverered practical workarounds and solutions. An overriding concern seems to be the ever expanding bloat that is J2EE. Bruce Tate was the harshest critic about the monolithic nature of this massive beast and provided great stategies for reducing bloat. The symposium lasted all weekend and I attended many sessions, such as...

(
I work for SpiderLogic and we proudly sponsored the event. We also prepared many whitepapers which are now available online.
)

Naked Objects - Dave Thomas

The most anticipated speaker of the weekend may have been Dave Thomas. Everyone tells me he is always very entertaining and they always learn a great deal whenever they have a chance to attend his sessions. After attending Naked Objects, I have to agree. He explained that in recent years we tend to use object encapsulation to simply hide data, not implement the full behavior of the represented real-world object. With Naked Objects all behavior should be implemented and exposed to the user. He demostrated that all behavior defined by the object is exposed to the user through the Naked Object view framework.

The framework has a high cool factor but it truly shows what can be done with object behavior. One feature that I found impressive is that objects can implicitly define relationships with other objects. An internal collection which is managed by the Naked Objects framework handles the collection and if a property changes it can automatically notify related objects which could then take action. To do so it takes advantage of reflection and an inherited base class called NakedObject.

Countinuous Performance Testing - Mike Clark

In this session Mike Clark discussed strategies for continually testing performance. He explained tools like JUnitPerf and JMeter can be used to gather the necessary metrics of normal usage as well as generate load tests. His key point was that too often developers make the mistake of premature optimization. It is not necessary to optimize a process which takes 10 seconds if it only runs that process once every 24 hours. It is the processes which take 19 milliseconds which run 100 times a minute which yield the real benefit. It is best to profile an application throughout the development cycle and address concerns as they emerge.

Advanced Version Control - Dave Thomas

I have dealt with setting up and managing CVS repositories quite a bit the last few years, so I was looking to learn a few new things. The #1 tip that I got was the use of modules. Dave Thomas provided a great explanation about the 3 types which he calls alias module, regular module and ampersand module. With this feature I could create an alias mapping which works well for an IDEA user and another for an Eclipse user but have them point to the same codebase. I could also create a set of aliases for developers who work on a codebase which uses multiple components, but perhaps some developers on the entire codebase while others work on specific sub-components while use Jars to represent the other base components.

Better, Faster, Lighter Java - Bruce Tate

I like how Bruce Tate thinks. He does not get sucked into the promises of EJB and other large frameworks which tend to introduce more issues then they resolve. I have had that opinion for a long time, but his books Bitter Java and Bitter EJB get into great detail about the problems with bloat and what to do about it. A key issue he addressed is that some critical enterprise frameworks suffer from poor testability, so unit testing is difficult and too often unimplemented. A tool to evaluate a codebase which Bruce Tate recommends is JDepend. He also explained that a healthy software project will allow for a plugin framework to allow users to extend the base features of the system to allow for a project to grow. In this way the core product can stay small and organized and users can use plugins as they choose and not be forced to download a monolithic beast.

GUI Development with SWT and JFace - Ben Galbraith

Since I was attending the previous session with Bruce Tate, I missed Ben Galbraith's talk on Swing, so I attended this session since I am interested in creating better desktop interfaces. I do not plan to use SWT for quite a while, but his explaination of how JFace simplifies the work in SWT was very helpful. One thing that I did not know before is that you can actually take control of the event-loop which runs the GUI in SWT. That could be very useful. But for now I plan to do Swing, least until reviews for SWT on MacOS X and Linux are more favorable.

Java Reflection Intro - Stuart Halloway

Stuard Halloway sees things differently than most people. When everyone else is just coding away in the normal fashion with constructors, getters and setters, private properties and inherited classes he is thinking up ways to use reflection and class loading to do it differently. He has some scary ideas, but they are worth considering. After he spoke about reflection and his ideas about what you can do with it I changed my mind about what I was going to attend for the next session and came back to see more of what he had to say.

Meta Programming - Stuart Halloway

This topic covered software which generates software. He showed how to decouple systems so that factories could return implementation classes with unique behavior, perhaps by loading a class dynamically with a classloader. He created a generic class called SmartFactory which used the InvokeHandler interface to return an Object which could be any implementation class. It was powerful and could potentially replace every other factory that has been created with less than 20 lines of code, but the downside for me is that I would have to cast the Object to the concrete class so that I can use it. I already do not like using Collections because I have to cast items off the Iterator, often having to make sure I am casting to the right concrete class because I got the Collection from some getter method which may be doing some unusual things to populate the Collection. Making instances returned generic Objects also makes it a little harder to navigate the code in an IDE. But still, a generic factory is something worth considering. He also mentioned AspectJ as a part of implementing tricky behavior to powerful things. I am intrigued.

Taming Your Build Process - Craig Walls

This session covered using Maven to handle the build process. I have known for a long time that most Apache projects use Maven, but I did not know that it currently works on top of Ant to carry out much of it's work. It provides many default targets, such as compile and clean, which work well by default but could also be customized as needed. Maven also can automatically manage 3rd party dependencies using a remotely accessible Maven repository of Jar files which you can specify locally with a simple configuration. If you need a file during the build process it simply pulls it down. Simple. Maven can also generate documentation similar to Javadoc, but it also includes the code so you can essentially browse the Javadoc as well as the code. That could be very useful. And lastly, the configuration for Maven can be used to generate the project files for Eclipse and IDEA, so starting up a new workspace is greatly simplified.

The downside of Maven is that it is poorly documented which leads people to criticize it for Maven being hard to use. Craig Walls refuted the opinions of others that it was hard to use, but I have to say that he is wrong. I do not care what system it is, anything that provides a considerable amount of features without being properly documented will be a hard system to use. So the Maven developers should take a week to write up some documention. I think it is ironic that a project which is used to generate so much useful documentation for the projects that it manages is so poorly documented itself.

Class Loading - Stuart Halloway

Back to my favorite speaker for the weekend, we all sat in amazement at what we were watching. Stuart Halloway showed the difference between implicit and explicit class loading. I have had issues in the past where Websphere uses some funky class loading sequence to load common dependencies for many applications and now I think I will understand it the next time it comes up. But just to be sure I bought is book on the topic, Component Development for the Java Platform which covers class loading, reflection, serialization and metaprogramming. One area he touched on briefly was sealed libraries. I started reading his book last night and I feel I am starting to gain a deeping understanding of how containers work, and hopefully I will develop a rich understanding of hot deployment.

Unit and Acceptance Testing - Cobbie Behrand

This session was covered by a local superhero, someone I find to be a great asset to the Milwaukee area. Sure he is competent at software development, but what I value more about him is that he has an amicable presence and is always open to new ideas. Those are what I consider the highest virtues a consultant can have. With that said, Cobbie covered unit testing using an array of free utilities, such as HttpUnit, jWebUnit and JMeter. Another local hero, Vinny Carpenter spoke up many times about JMeter. He really, really likes it. There was considerable discussion among those attending the session and it was very helpful. Cobbie was pleased with the give and take that was taking place.

What I took away was that unit testing is good, but I often feel that it has become overly stressed and encouraged. Sure it will help you discover problems long before the release date, but there should be consideration that unit tests should not slow down the development process without sufficient benefit. Also, unit tests should not be trusted as the one true way to determine that an application is bulletproof. Tests that can be coded are just as susceptible to human error as the code that it tests. My general approach is to test critical pivot points within the codebase, perhaps heavily used interfaces and factories and connection points between components. The flaw I find in unit testing is that you can predict where there could be problems and create tests to check for them and code around the problems, but it is the scenarios you do not predict that will bite you. So my take is good defensive programming, regular code reviews and design contracts will greatly complement (not replace) continuous unit testing. Many times unit testing replaces code reviews and does not make the distinction between testing for failures and testing the design contract for compatibility between releases. Unit testing is still in it's infancy.

z