Web application scalability

It seems infoq picked up some stuff from a comment I left on the serverside about one of my pet topics (Server side Java).

The infoq article also mentions that I work at Nokia. I indeed work for Nokia Research Center and it’s a great place to work. Only they do require me to point out that when making such comments I’m not actually representing them.

The discussion is pretty interesting and I’ve recently also ventured into using other things than Java (mainly python lately with the Django framework). So far I dearly miss development tooling which ranges from non existent to immature crap for most languages that are not Java. Invariably the best IDEs for these languages are actually built in Java. For example, I’m using the eclipse pydev extension for python development. It’s better than nothing but it still sucks compared to how I develop Java in the same IDE. Specifically: no quickfixes; only a handful of refactorings, no inline documentation, barely working autocompletion, etc make life hell. I forgot what it is like to actually have to type whole lines of code.

I understand the development situation is hardly better for other scripting languages. There’s some progress on the ruby front since Sun started pushing things on that side but none of this stuff is actually production quality. Basically the state of the art in programming environments is currently focussed primarily on statically compiled OO languages like Java or C#. Using something else can be attractive from for example language feature point of view but the price you pay is crappy tooling.

Python as a language is quite OK although it is a bit out of date with things like non utf-8 strings and a few other things that my fellow country man Guido van Rossum is planning to fix in python 3000. Not having explicit typing takes some getting used to and also means my workload is higher because I constantly have to use Google to look up stuff that eclipse would just tell me (e.g. what methods and properties can I use on this HttpResp object I’m getting from Django; what’s the name of the exception I’m supposed to be catching here, etc). In my view that’s not progress and leads to sloppy coding practices where people don’t bother dealing with fault situations unless they have to (which long term in a large scale server environment is pretty much always).

OSGi: some criticism

Over the past few weeks, I’ve dived into the wonderful world called OSGi. OSGi is a standardized (by a consortium and soon also JCP) set of java interfaces and specifications that effectively layer a component model on top of Java. By component I don’t mean that it replaces JavaBeans with something else but that it provides a much improved way of modularizing Java software into blobs that can be deployed independently.

OSGi is currently the closest thing to having support for the stuff that is commonly modeled using architecture description languages. ADLs have been used in industry to manage large software bases. Many ADLs are homegrown systems (e.g. Philips’ KOALA) or simply experimental tools created in a university context (e.g. XADL). OSGi is similar to these languages because:

  • It has a notion of a component (bundles)
  • Dependencies between components
  • Provided and required APIs
  • API versioning

Making such things explicit, first class citizens in a software system is a good thing. It improves manageability and consistency. Over the past few weeks I’ve certainly enjoyed exploring the OSGi framework and its concepts while working on actual code. However, it struck me that a lot of things are needlessly complicated or difficult.

Managing dependencies to other bundles is more cumbersome than handling imports in Java. Normally when I want to use some library, I download it; put it on the classpath; type a few letters and then ctrl+space myself through whatever API it exposes. In OSGi it’s more difficult. You download the bundle (presuming there is one) and then need to decide on which packages you want to use that it exposes.

I’m a big fan of the organize imports feature in eclipse which seems to not understand OSGi imports and exports at all. That means that for one library bundle you may find yourself going back and fort to the manifest file of your bundle to manually add packages you need. Eclipse PDE doesn’t seemt to be so clever. For me that is a step backwards.

Also most libraries don’t actually ship as bundles. Bundles are a new concept that is not backwards compatible with good old jar files (which is the form most 3rd party libraries come in). This is an unnecessary limitation. A more reasonable default would be to treat non OSGi jar files as bundles that simply export everything in it and put everything it imports on the import path. It can’t be that hard to fish that information out of a jar file. At the very least, I’d like a tool to that for me. Alternatively, and this is the solution I would prefer, it should be possible to add the library to the OSGI boot classpath. This allows all bundles that load to access non OSGi libraries and does not require modifications to those libraries at all.

Finally, I just hate having to deal with this retarded manifest file concept. I noticed the bug that requires the manifest to end with a empty line still exists (weird stuff happens if this is missing). This is equally annoying as the notion of having to use tabs instead of spaces in makefiles. I was banging my head against the wall over newline stuff in 1997. The PDE adds a nice frontend to editing the manifest (including friendly warning of the bug if you accidentally remove the newline). But the fact remains that it is a kludge to superimpose stuff on Java that is not part of Java.

Of course with version 1.5 there is now a nicer way to do this using annotations. Understandably, OSGi needs to be backwards compatible with older versions (hence the kludge is excused) but the way forward is obviously to deprecate this mechanism on newer editions of Java. Basically, I want to be able to specify at class and method level constraints with respect to import & export. An additional problem is that packages don’t really have first class representation in java. They are just referred to by name in classes (in the package declaration) but don’t have their own specification. That means it is difficult to add package level annotations (you can work around this using a package-info.java file).

ubuntu breezy to dapper upgrade

I still have my old pc sitting next to my new pc. A few months back I installed ubuntu on it. Since then it has just sat there doing nothing. Occasionally I boot it into windows to retrieve some file I forgot to migrate. These occasions are getting very rare now. Soon it will be time to dispose of the box.

Anyway, I’ve been reading that ubuntu breezy is soooo 2005 and that ubuntu dapper is all hot and new. So I’ve attempted an upgraded. Forget about user friendly-ness. The procedure for this requires command line usage. But I’ve handled Debian before so that does not scare me. It’s not like the ubuntu installation is important to me anyway (and yes, I managed to mangle quite a few Debian installs attempting stuff like this. In my experience apt-get dist-upgrade is dangerous stuff).

For the record, it’s a vanilla ubuntu install with the kubuntu package installed and the kdm login manager installed. It should work just fine. Other than that, I did nothing to it other than trying to get it to work properly (which I eventually managed to do as reported earlier) and install Java and eclipse.

Here’s the proper procedure: use ctrl+alt+function keys to find a non graphical console. The update procedure will include all your X, Gnome and KDE stuff. Replacing it while it is running is not a good idea IMHO (it might actually work but I didn’t care to find out the hard way this time).
OK, now login. Fix /etc/apt/sources.list by replacing all occurances of ‘breezy’ with ‘dapper’. Type sudo apt-get update. This updates your package database with the dapper packages. Now (fingers crossed) type sudo apt-get dist-upgrade. Apt-get now asks you if you are sure that you want to download 750MB (in my case) and really want to install or upgrade 1000+ packages. I said yes, you should say no unless you are sure you want this. Since then it has been downloading and installing stuff by itself. Cryptic messages about packages installing and configuring themselves fly by way to fast to read. Clearly, stuff is happening!

Now, I’m writing this while it is happening. Since that takes quite some time, let me elaborate on my expectations. As said earlier. I’ve dist-upgraded debian installs before. Usually to testing and I even got to unstable once (bad idea, it really was unstable). Usually it works fine, provided both the starting source and target of the procedure are stable (Debian testing by definition is not so your mileage will vary). Worst case for me was ending up with a situation where nothing worked anymore. Best case, it just worked. Ubuntu claims to be enterprise ready. If it fails here it is not.

OK, it finnished. The whole process took about an hour (excluding download). I did a sudo reboot (I’m a windows user).

Problem #1: ubuntu boots nicely to the text console. Solution: it’s not a bug but a feature, ubuntu remembered that I was on a text console when I rebooted. Good thinking?!

Whoo, new kubuntu login screen. No more nasty shades of shitty brown. Oh wait this is just the default KDE look (nice). Log out, login into gnome. Looks like shitty brown is back on the menu :-(.

In short, the upgrade seems to have worked just fine. The little preferences I had seem to have migrated. Including my x settings; my manual install of java and eclipse; and a terminal icon I dragged to the desktop.

Other than this. My main points in my previous review still stand. Despite some slight improvements, menu layout is a mess; the theme looks shitty and the commandline is still required for non trivial stuff like performing an upgrade or configuring X properly (though admittedly I did not try the new installer; merely assuming it doesn’t do a better job than the previous version).

Some afterthought. I installed koffice. The icons only show up in the menu when I use KDE. I guess this unified menu shit is only skin deep.

jedit plugin manager

I tried to install some plugins in jEdit, my favourite programming editor (for things other than Java, for that I use eclipse of course). I got some IO errors trying to install some plugins in the plugin manager. Since this has happened before, I looked into it and found a solution to the problem:

  • go to Utilities->Global options
  • Select plugin manager
  • click ‘update mirror list’
  • select one of the alternatives

Apparently the problem is that the default repository url in jEdit is no longer ok. Changing it to another one fixes that problem. Since the whole point of jEdit is using the many plugins that are available this is a pretty critical thing to fix.

Anyway, I’m glad to see that development for jEdit seems to be picking up again. I noticed that the 4.3pre4 release is fairly recent. Also the sourceforge page shows that there is a healthy activity on the core jEdit source code. I’m glad because it started to feel like this project was more or less dead. Jedit is pretty unique, all the other editors have (much) less features.

why cvs sucks

Having worked with subversion quite extensively, I know what to expect from a proper versioning system. However, I’m currently working in a project with a cvs server. Here’s a few of my observations:

  • I can’t seem to get tortoisecvs and eclipse to work together on the same checked out repository. Reason: tortoisecvs does not support eclipse’s custom extssh stuff. Duh, ssh is only the most common way to access a cvs repository these days.
  • I’m unable to put things like directories under version management, only the contents.
  • I don’t seem to have an easy way of getting the version history for a directory of files with the commit messages ordered by date.  I’m sure there are scripts to do this  but it is definately not supported natively (and likely to bog down the cvs server).
  • Each file has its own version number
  • Commit messages do not specify what files were committed (unless you paste this information in the message of course)!
  • I managed on several occasions to do a partial commit. That is some files were committed and some weren’t
  • Each time I refactor, I lose version history because cvs considers the result of a copy, move or rename to be a new file.
  • My attic is full of files that now have a different name
  • Branching and tagging create full serverside copies of whatever is being branched or tagged

Subversion doesn’t have any of these problems. CVS seems to actively discourage refactoring, is dangerously unreliable for large commits and does an extremely poor job of keeping version history. The fact that I encounter all of these problems on a toy project says a lot about CVS.
This is why CVS should not be used for serious projects:

  • Refactoring now is a key part of development. Especially (good) java developers refactor all the time.
  • The versioning system should never ever end up in an inconsistent state due to partial commits. There is no excuse for this. A version management system without built in protection against should be considered seriously broken.
  • Being able to keep track of version history is crucial to monitoring project progress. I’ve been a release manager. Only now I’m starting to realize how much my job would have sucked if we’d be CVS users. I feel sorry for all these open source people who still continue to use CVS on a voluntary basis.

Netbeans 5.0 first impressions

With much fanfare (at least on the various Java news sites), Sun has launched its latest edition of netbeans. Netbeans 5.0 is a significant improvement over 4.x. 4.x basically improved the UI to the point where it was reasonably fast and usable. 5.x consolidates the improvements by adding (a lot of) depth to the featurework in 4.x. A new component that is mentioned in every review is Mattisse, the GUI builder. I had a brief session with this thing with one of the betas a few weeks ago. It’s definately a very nice tool. Unlike most GUI builders (including most previous generations of netbeans and the eclipse GUI builder) this one doesn’t suck, most of the time. I’ve had too much exposure to Swing over the past decade to not code my GUIs manually but for someone not so familiar with Swing this is actually quite usable.
Last week I downloaded and installed the release at work. Since I now work for Nokia I, decided to give the mobility pack a spin. The rest of this review is about my impressions using this part of netbeans. The mobility pack basically includes sun’s toolkit (libraries, emulator) and integrates this into netbeans. Overall it is a pretty impressive thing. I have had exactly 0 experience with building J2ME stuff. Just to see where I would end up I started a hello world mobile project.

I was positively surprised at the level of usability the mobile pack offers. The project setup generates a build file for you that basically does all the difficult stuff (like creating a deployable jar that you can install on midp phone). Buildfiles in general are well integrated into netbeans (unlike eclipse). Basically building your project means calling the appropriate ant target. You can do this by selecting the option from the menu, right clicking on your project, etc.

After completing the new project wizard, netbeans had generated a nice Visual Midp class for me. The word visual means that you can edit the midp client in a visual environment. This environment is pretty powerful and will probably suit most basic needs. Essentially you drag and drop a various types of screens in a flow. Then you add actions to each of the screens and finally draw some arrows between the screens. At this point you can actually run the application in the emulator (or a real phone) and you will be able to navigate through the screens that were just defined. For the record, you don’t need to write any code to get to this point.

The flow view has a nice other use: it is a perfect companion to a functional specification. Just add a little information on the semantics of all the actions and you’re basically done (with the functional spec). It’s also great for prototyping. You can just click a bunch of screens together and have a live demo on a mobile phone in no time.

Then  we come to library dependencies. Basically any java project will end up using several external libraries. In eclipse they have to be in your project and then you can add them to the classpatth, alternatively you can define external libraries. In Netbeans there’s the library manager where you define libraries. A library may be a project (in which case netbeans automatically figures out that it should use the jar in the dist dir) or a jar file you downloaded. You can also associate source folders and javadoc with the library. Once you have libraries defined, you can edit the project properties and add library dependencies. That’s it. If you do a build of your (mobile) project, netbeans will automagically pull together all libraries and generate one big jar file with everything in it. It will even build projects if the source code is newer than the library. Nice. Eclipse sort of has the same functionality but the netbeans UI for this is simply much better and usable.
So far, I really like Netbeans 5.0. Now we come to the parts that are not so fun. Coding. The code editor in netbeans still sucks. Sure, it has been improved over netbeans 4.x. It is noticably faster with things like autocompletion. The problem is that it is pretty stupid compared to what I am used to: eclipse. Eclipse has whole bunch of editor features that are simply missing from netbeans. You can’t do the “extract local expression” refactoring (alt+shift+l) which means that you have to do that manually (which I never ever do in eclipse). This probably my number 1 missing feature. Several other refactorings are missing. Then there are no quick fixes. So if you write some code that throws an exception you cannot add a catchblock to the try catch you already have. Neither can you add a throws clause. These are just two of the many quickfixes that eclipse has. Templates are implemented but much less functional. I just love typing for and then ctrl + space to generate a foreach for some collection (or select alternative means to iterate over whatever is iteratable in your code). It’s just not there. It will generate a for loop but you still have to fill everything in yourself. There are lots of other features that anyone familiar with eclipse will miss.
In short if your primary task is writing code, stick to eclipse. If you need wizards (mobile and supposedly the J2EE stuff is excellent as well), netbeans may be a better option. You’ll be spending much more time on your code but may still be more productive due to all the convenient stuff that netbeans does for you.

Personally, I’m still in the eclipse camp. It’s just that I am working on this toy midp client at work so I prefer netbeans for this project. For netbeans to win me over permanently they will basically have to add tons of features to the code editor. This being said, the improvements in netbeans are worth some attention from any java developer. It’s nice to see some stuff working that is basically broken (or unsuable, which is the same thing practically) in eclipse. Both projects still have a lot to learn from each other.

Unchecked Exceptions

This article presents an elaborate and IMHO misguided approach to handling exceptions: ONJava.com: An Exception Handling Framework for J2EE Applications

The author poses the problem that handling exceptions is tedious and leads to lots of boilerplate code. His proposed solution is to use unchecked, run.time exceptions. His reasoning is flawed for a number of reasons:

  • Most Exceptions come from external components. When bad stuff happens, you’re supposed to do stuff (other than just logging). Thinking that bad stuff won’t happen is naive, it will. In most cases, the reason that you get an exception is either that your assumptions were wrong (add some if statements to check) or there is a real problem (like something is misconfigured, the db is down, network is down, …). In some poorly designed code there may be a third reason: the software is wrapping state information in an exception. Don’t do this, ever.
  • You shouldn’t create new exception types if you can reuse existing types. That leads to less boilerplate code and more clarity. Nothing worse than having to figure out the cause of the cause of the cause of the exception that tomcat logged.
  • A good IDE makes handling exceptions really easy (eclipse ctrl+1 will give you handy quickfixes like “add throws declaration” “add catch clause for exception”). If you’re typing all this stuff manually, you’re doing something wrong. That leaves the problem of code readability. Poorly written code tends to be unreadable. Lots of exception handling code is a symptom, not a cause. If it’s unreadable: refactor it. In general if your methods don’t fit on a 1600×1200 screen you might want to start thinking about refactoring. If your classes regularly exceed 500 lines of code you’re having design issues. What makes code really unreadable is excessive coupling and lack of cohesiveness. Refactoring is the solution.
  • Unhandled exceptions either end up in front of the user, in the log or both and can leave your application in an unexpected state. Basically all these things are bad. Users should never see any stacktrace and should always get some kind of response from the application. Nothing worse than clicking next and ending up on the same screen because some runtime exception prevented the server from doing anything useful with the request (I see this a lot).

So in short, use a decent IDE (generate the boilerplate code) and handle the exception instead of throwing it to the caller if you can. If your code is still unreadable, don’t make it worse by throwing unchecked exceptions.

Generic event code

Better late than never. I’ve been trying my hand at using Java generics to solve a nice little problem. For years I’ve been annoyed by the stupid copy paste reuse involved with JavaBeans event handling. If you are unfamiliar with it, stop reading now or learn about it elsewhere because this post is about a replacement based on Java generics, which is also a topic you should know about before reading further.

You have been warned.

First of all my generic replacement is not a drop in replacement because it breaks the JavaBeans spec. It has to do that because the folks that produced this spec embedded typenames into method names and interface names (instead of using generics which was not part of Java at the time). This is roughly how it works now:

  • Create a subclass of EventObject (there is no interface!!!): FooEvent
  • Create an interface FooEventListener with a method foo(FooEvent e)
  • Now in the class that produces the FooEvents, add two methods: addFooEventListener(FooEventListener l) and removeFooEventListener(FooEventListener l)
  • Also add a fireEvents method that iterates over all the listeners and calls the foo method

The problem(s) with this approach:

  • The three methods you add to the event producer are always the same, except for the name which has the name of the Listener interface embedded!
  • Worse they should be threadsafe. Many developers actually don’t know this and produce thead unsafe code!
  • Oh and the Listener interface has the type of the event embedded in its name as well!

All of this is mandated by the JavaBeans spec and tools actually depend on this (through reflection) to hook event sources up to event sinks.

Java 5 has an interesting new feature called generics which is otherwise known as parametrized types. With parametrized types you can do nice stuff like this:


public class GenEvtMgr<LT, T> {
	private final List listeners = new LinkedList();

	public void fire(T e) {
		for (EvtListener i : listeners) {
			i.eventFired(e);
		}
	}

	public void addEventListener(LT l) {
		listeners.add(l);
	}

	public void removeEventListener(LT l) {
		listeners.remove(l);
	}
}

public interface EvtListener<ET> extends EventListener {
	void eventFired(ET e);
}

public interface GenEvtProducer {
	GenEvtMgr getEventManager();
}

What this does is actually pretty simple. It defines a reusable GenEvtMgr to handle the bureaucracy of handling all the
Listeners. It’s a generic class with two parameters, a LT and T where T is the actual event type and LT is an EvtListener parametrized with T again.

EvtListener is a generic event listener with only one method to handle events of type T. Finally producers of T events need to be able to provide a manager so there’s a GenEvtProducer interface as well.

And some code to test the above …


public class EventTester implements GenEvtProducer {
	private final GenEvtMgr<EvtListener, SomeEvent> mgr =
		new GenEvtMgr<EvtListener, SomeEvent>();

	public GenEvtMgr<EvtListener, SomeEvent> getEventManager() {
		return mgr;
	}

	public void go() {
		mgr.fire(new SomeEvent(this));
	}

	public static void main(String[] args) {
		EventTester test = new EventTester();
		GenEvtMgr<EvtListener, SomeEvent> eventManager
			= test.getEventManager();
		eventManager.addEventListener(new EvtListener () {
			public void eventFired(SomeEvent e) {
				System.err.println("Foo");
			}
		});
		eventManager.addEventListener(new EvtListener () {
			public void eventFired(SomeEvent e) {
				System.err.println("Bar");
			}
		});

		test.go();
	}
}

So we create implementation of GenEvtProducer. The implementation has a GenEvtMgr object parametrized with SomeEvent which is our EventObject subclass (not listed above). We can add listeners, remove listeners and fire events simply by calling the manager. Finally in the main method two listeners are created and calling the go method produces foo bar as expected.

Is this ideal? No. There’s several problems.

  • It’s not threadsafe, that’s easy to fix.
  • The type of GenEvtMgr is a bit complicated, eclipse makes it easy though with infer type and autocomplete.
  • All users of the manager class have access to the fireEvent method as well which is something you may not necessarily want to expose.
  • The Listener interface only has one method, the JavaBeans specallows for more than one.

The last problem might be a bit hard to solve but you might wonder how desirable that is. It’s sort of logical to have one handler per event. Most of the time, Listeners with multiple methods are in fact an attempt to avoid having to deal with implementing multiple events and the associated bureaucracy of having to create all sorts of code for registering and calling listeners. With the code above this is now a lot easier. Some trivial extensions of the code above are to create an event producer that can produce events of multiple types, each with their own manager and listeners (e.g. use a map of T.class to GenEvtMgr). But I’ll leave that sort of thing as an exercise to the reader.