Java

Six weeks without internet access can really cause you to do funny things. I for myself decided, to pass the time by finally rewriting an old project of mine, that was, to put it mildly, an embarrassment to show to anyone. I am still not quite finished with it yet, but since I haven't been able to blog for a while and there are always people searching for code examples, solving common problems, I guess, I could as well work some snippets into blog posts.

Instructions for fixing broken file bindings for Java under Microsoft Windows.

Problem description: Java application (single .JAR file) does not start, when double clicked / Clicking the JAR file just opens a directory view, in which no executable file can be found.

Today in the "can't be that hard to code" category: parsing email addresses.

Boss comes in and tells you, that some Java project will now allow the user to submit an email address. It is your task to write the sanity checks, rejecting anything, that is not compliant with the address specification found in RFC 2822. Oh, and by the way, the customer does not have the JavaMail API installed and cannot be brought to do so. Meaning, you have to re-invent the wheel.

Every Desktop application pretty much needs a GUI. No problem so far. The trouble starts however, when components have to be arranged visually in a container. The preferred method for doing this is in Java, is to use a layoutmanager instead of specifying absolute pixel coordinates for component placement.

Some things sound trivial to do, but on closer look turn out to be a formidable brainteaser. One of them is writing modular Java programs, where the core program can be extended using plugins. Such a design might be desirable, when extra program functionality is either to be licensed separately, to be contributed by third party, or generally "to be decided later".

Have you ever played the desktop puzzle? The goal of the game is to move around and resize the windows of all the applications you are currently using, to best fit the limited space available on the screen. A lot of people spend (or rather waste) a lot of time doing this and worst of all, they have to do it over and over again, as most programs forget their geometry setting after being shut down.

Three days ago, I posted a design pattern for menubars. While the article was mainly about code clarity and the clumsiness of inner classes, it also contained some remarks concerning performance and naturally this puts me in a put up or shut up situation, even though a performance discussion was not really my intention.

Ok, here is the problem: You are assigned to write a method for a Java based filemanager, that is able to delete an entire directory tree. Sounds like a trivial task, that can easily be solved by a very simple, recursive algorithm, doesn't it? Take a File object. If it is indeed a file, just delete it. If it is a directory, list it's contents and call yourself for every file contained in it. Thats it, 10 minutes of coding and taking the rest of the day off. Money earned easily.
A day later however, one of the betatesters calls in.

There is this thing about Java GUI programming, that has been irking me for quite a long time. Namely the way, a lot of people tend to write ActionListener routines, which often involves the use of inner classes. I don't really know why inner classes are so popular. Personally, I never liked them, always considered them to be defective by design and generally more helpful in obfuscating code then producing clarity.