Coding in an absurd reality

A thorn in the side of every GWT developer must be the ridiculous URLs it produces. Please, come and visit our wonderful webapp at ... very attractive... Of course, you can have http://company.com/thisapp/ redirect there, but still.

Fortunately, there is an easy way to shorten the URL, as explained in this not so aptly named thread in the Google Groups group on GWT. If you choose a decent module name, you end up with
http://company.com/module/Module.html, which is acceptable.

If you use the maven-gwt plugin to build your project, you need to modify both the compile targets and the run target to

code:

1 2 3 4

<compileTargets> <value>Module</value> </compileTargets> <runTarget>Module/Module.html</runTarget>

Today I was researching the obstacles I would encounter while upgrading the Resin Application Server from 2.1 to 3.1. One of the things that came up was that OpenSSL support is no longer supported in the open source version: you would have to buy a license to enable the JNI bindings to OpenSSL.

However, JSSE is also supported as the SSL connection handler, so I decided to find out what was involved in switching from OpenSSL to JSSE. That proved to be quite easy, with a Java 6 JDK that already includes a configured JSSE library. The largest problem was converting the certificate + key to a Java keystore. For everyone that may one day have to solve this problem:

First put the certificate and the key in a pkcs12 keystore:

code:

1	openssl pkcs12 -export -out dev.pkcs12 -in dev.crt -inkey dev.key

then convert the keystore to a JKS keystore, using the Java keytool:

code:

1 2	keytool -importkeystore -srckeystore dev.pkcs12 -srcstoretype PKCS12 -destkeystore dev.keystore

This example involves a self-signed certificate; if you need to include CA certificaties or certificate chains, the process is slightly more complicated, but probably not very, as you can use openssl to perform all the hard steps. If I encounter any problems when I do that, I will let you know .

On a sidenote: Java keystores are terrible things and I dread the moments when I discover they are once again inevitable in reaching a certain goal.

Last week it struck me that I've never really used exceptions in Java properly, despite having written thousands of lines of Java code over the last three years. Of course I have written plenty of try-catch blocks, logged, chained and wrapped exceptions in my own custom exceptions, but ultimately, I hardly ever use them like they were intended: as a replacement for result codes and a means to easily propagate 'failures' up the stack. Instead of using exceptions, I often use result objects that simply wrap the actual result object, together with a boolean indicating whether the call was succesfull and an optional failureMessage.

The question that immediately followed is: why? Why has it taken me so long to realize the way in which exceptions are meant to be used? I think the problem is twofold:

• The name feels wrong and
• Nonlocal behaviour is hard to grasp

The first one is simply this: when a method fails, this often isn't exceptional. For instance, someone requests the order with ID 1529, but no order with that ID exists. The method fails and I could throw an 'OrderDoesNotExistException', but that just feels wrong, because the situation simply isn't exceptional. I think this can be mitigated by simply changing the name of such a custom Exception to 'OrderDoesNotExistFailure' or the even simpler 'OrderDoesNotExist'.

The second is a more subtle problem, which I think has to do with the fact that code is easier to understand when you handle the result of a method call immediately, even if that consists only of 'inspect the boolean in the wrapped object and branch'. When throwing an exception, the flow continues somewhere far from the original method call and this is less intuitieve. However, one can develop an intuition for it, if one properly designs the use of exceptions beforehand. And that is the ultimate problem: I've never thought deeply enough about the way one should/could use exceptions.

Today I needed to fix a bug in an application that runs at a number of different sites, some of which are still stuck at Java JRE 1.3.1. Therefore I downloaded the appropriate JDK from Sun and happily typed

code:

1	./build all

only to be greeted by

code:

1 2 3

/usr/local/jdk1.3.1_20/bin/i386/native_threads/java: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory

What's wrong is that the linux version of this JDK depends on a pretty old version of libstdc++. Luckily, a compatible library is still available from the Debian archives.

Sun, in the Java EE 5 tutorial:

The Application Server supports iterative development. Whenever you make a change to a Java EE application, you must redeploy the application.