Java seems to get more powerful the more you use it. Doing research into possible methods to solve problems I’ve come across over the past few days, I’ve discovered the power that a well-designed, object-orientated language can give you.
Take reflection, for example. This is the process of looking at already compiled Java classes to determine methods & interfaces supported, fields and other information about a class. I had never really delved into this before, but you can learn just about anything you want to know about a class via this reflection technique at runtime. I am using it mainly in a plugin architecture to determine which classes are plugins via querying the interfaces that they support. It seems far cleaner and more reliable than some of the methods I’ve used before to try work out which files are valid plugins.
Another facet to this side of the language is custom class loaders. These allow you to override the standard Java class loader with your own. The thing about this is that it allows you to load any byte-code into the Java VM. This means that, among other things, you can dynamically write your own class at runtime in response to events. I know this is possible with other languages, but, along with other language features, you can easily implement this in an efficient and secure manner.
The thing I’m finding is that these features of the language, which I’d considered somewhat of a black-art, are really not that hard. They also offer extremely neat ways of doing things that before I would have had to resort to a nasty, convoluted hack to do. I wish I’d have known more about these techniques when writing code for our group project last year; some of it would have been far easier and far more flexible.
For server tasks, I am really beginning to see why Java is so popular. I still don’t think of Java, however, as a desktop, GUI-orientated language. Having worked with quite a number of Swing applications, I find Java on the desktop still rather slow and clunky. I believe that the new release of Java, 1.5, features a speed-up (of between 10 and 50%) for Swing.
Whilst this is a good thing, of course, I have to agree with the many people that say that the problem with Swing is that it tries to be so platform-neutral that it ends up being unfamiliar to users of any given platform. What I want, as a user, is a GUI that performs the same as the rest of my desktop. From a developer’s perspective, a single, cross-platform GUI is great, but for the user, it just doesn’t work.
New kid on the block SWT may well go a long way towards fixing this issue. It goes back to the AWT way of doing things: use native controls for your GUI. However, AWT went for the lowest common-denominator approach, which left it being very under-powered and not very useful. SWT takes the approach that we want a fully-featured system, so going lowest common-denominator doesn’t work.
The SWT idea is to do as much as possible with native controls, but to fill in the gaps in native controls with Java coded controls, much in the same manner that Swing does. This is intended to give a best-of-both-worlds approach: the speed of native controls as much as possible, but the large array of GUI-building tools that Swing offers. I look forward to working more with SWT in the future to see if it can deliver on this promise. If it can, I look forward to Java finding a much larger foothold in the desktop market.