Applet Jazz

Remember the early days of Java? Remember how the "write once, run anywhere" used to include running on a user's desktop, in the user's browser, until the big bust-up between Sun and Microsoft put a stop to all that? Before AJAX came along, applets used to be the coolest thing on the block at least as far as building webpages that looked a bit special. After the split, though, that all went away. "No-one wants applets" has been the refrain for several years now. Even Sun put applet development on the back burner, while concentrating on server-side Java with a bit of Swing on the side. There has been no real development of applet support since about 2001.

Well, all that may be about to change. With Java FX, Sun is aiming to product a platform for advanced graphics to compete with Flash and Microsoft's Silverlight. One thing that they are keeping rather quiet about is the delivery vehicle for an application written in this new language. It's applet technology. When you build a fancy display tool in Java FX, it's compiled and built into an applet. When you include it in a web page, your user must have Java installed before it will run. The big hope is that this won't put too many people off. After all, Flash sites require their users to install a browser plug-in, and Java won't be any different. Sun are clearly aware of the problem, and the latest version of Java includes various new features to make this installation process faster and more reliable. The question is, will this be enough? Is the installation process reliable enough, and does the platform offer enough features, to tempt web developers into using it?

For the installation process, I simply don't know whether most users will find it acceptable. All we can do is to assume that Sun will do enough, or have done enough, to convince developers that it's going to work. Taking that as a given, let's look at some other problem areas that my recent experience in building an applet has shown up:

1. my applet had to be part of a very dynamic web page which used a lot of Javascript. In particular, some data had to be shown as overlays. This a very common Web 2.0 technique, but it causes problems, because some browsers will not display ordinary HTML elements over an applet. In many cases an IFRAME will do the trick, but not all. We had to resort to some browser-specific Javascript shenanigans to get it to work properly in various browsers, which is something we normally try very hard to avoid.
2. the applet does graphics its own way, without using HTML and CSS. In some ways this is a good thing; if applets can't do more than HTML and CSS, what's the point? The issue here is that we've built up a lot of expertise in working with these tools. A designer produces a static picture in Photoshop, and we know how to convert that into a dynamic web page with styling that can adapt as the content changes. If we do that for most of the pages on a site, and we want to create an applet that has a similar visual style, then we have to re-implement the look in a completely different way. When it gets a re-design, we can't simply change a few stylesheets; the applet has to be re-programmed. I haven't got a good answer is to this one, but it clearly needs to be addressed. The web has moved on since applets were first thought of, but applets haven't moved with it.
3. on a related issue, the support for displaying HTML inside an applet is very poor. It uses an old version of HTML, and doesn't seem to support CSS at all. This is simply not acceptable.
4. in Flash, you can download and use a font without needing to install it in the user's system. That's a really significant feature. In Java, you can offer the user the chance to install a font, but that creates an annoying dialog, and if they aren't an administrator on the machine, they can't do it anyway! If Flash can do this, why can't Java?

I dearly wish that Sun would fix the problems, and make applets into a viable technology again. I've tried programming in Javascript, and I hate it! It's OK for simple things, but as soon as it gets at all complicated, it becomes very difficult to write and debug. Wouldn't it be great to be able to program Web 2.1 in Java?

New Year Resolution - Read More Code!!!

When was the last time you sat down and thought to yourself, "I'm just going to spend half an hour reading this code"? Your code, someone else's code, it all counts. Given that we're always up against deadlines, and under constant pressure to produce results, why would you do something as apparently pointless as just reading code?

Reading program code is a critical part of what we do as software developers. We don't very often write something completely new. Most of the time, we are changing, fixing, enhancing, or extending something that already exists. If we're going to do that effectively, and without breaking what it already does, then we must understand what it's doing and how and, more importantly, why it's doing it. There are various ways to gain that understanding: you can run the program under a debugger; you can turn on tracing and debugging options if the program offers them; you can build tracing features if they are not already there; specific environments offer their own specific tools, such as a web server's access logs. But the simplest and fastest method is simply reading the code, if you can.

That's where the rub comes. A huge amount of the code that you meet simply cannot be read easily. You end up making heavy use of the navigation and cross-referencing features of your IDE in an increasingly desperate attempt to track the flow of control through layer upon layer of code. Stepping through with a debugger helps, but that has serious limitations: each debugging run represents one execution with one set of data, but you need to understand how the code deals with a whole range of input cases. Gaining this understanding can be a laborious business.

Reading code is something you do every day, because every time you have to debug, change, or extend an existing program, you have to read it first. So why do I say you should spend extra time reading code, on top of what you're already doing? Apart from the fact that more background information about the code you're working with is always worth having, there's another reason. We try all the time to make our programs readable, and actually reading code is the best way to understand how to do that. You need to read other people's code to get a feel for what's readable and what isn't. You need to read your own code to understand how you're living up to your own goals. That means not just reading the code you wrote yesterday, but also the code you wrote last month, and the code that you wrote two years ago. Once you've looked at the code, you can make a judgement on how well you're doing on the readbility front, and resolve to make changes to your own habits accordingly.

Why is readable, understandable code so important? For the very simple reason that if you can't understand it, you can't fix it. If you can't fix it, how can you ever deliver a working piece of software? Things are never right first time. Changing, fixing, and enhancing start almost as soon as you start coding, and they never stop. The way we write code has to be aimed at making those activities as rapid, effective, and enjoyable as possible. Failure to do that leads to broken software, unfixable bugs, missed deadlines, and huge project overruns.

Note: this applies just as strongly in today's agile environments as it ever did. Implementing this week's feature is quite likely to require refactoring and extending code that was written six months ago, or longer. If that code wasn't written with understanding in mind, you'll have big trouble!

So here's my suggestion for a New Year resolution for every programmer. Spend at least a little time each week just reading code, either your own or someone else's, and try to work out what the programmer could have done to make the code more readable. Then put those lessons into practice!

Happy New Year!!

To anyone who's reading this blog - have a happy 2009, despite all the doom and gloom that is being prophesied on every side!!