Wednesday, April 30, 2003

Be careful of JDK 1.4 First there was the memory leak in StringBuffer in JDK 1.4 (which is fixed in 1.4.1) there is also a backwards incompatible change to javac. Then as Costin found recently, if you're not careful a build on JDK 1.4 will fail on earlier JVMs. Basically javac has a target option, which on all JDKs since 1.1 used to default to the value "1.1" which means create JDK 1.1 compatible bytecode. However from JDK 1.4 onwards Sun decided, (badly) to change this value to default to 1.4. So hey presto any build that uses javac will create bytecode that doesn't work on some pre-JDK 1.4 JVMs. Note that targetting JDK 1.4 specific bytecode, as Costin says, will include new JDK 1.4 method calls when concatenating Strings and Objects. So this option has nothing to do with your code calling JDK 1.4 specific features. To avoid Maven developers from tripping up over this (I can imagine few people wish to target only JDK 1.4 with their code base), I patched Maven to default to 1.1 so that a Maven build will behave the same, by default, when ran on JDK 1.2, 1.3 or 1.4. If you really wanna build a JDK 1.4 only code base, then you can specify the maven.compile.target property to override this. This might be a nice change to make to Ant as well. JDK 1.4 seems to have been a fairly bad release for backwards compatibility. I don't remember hitting any issues moving from 1.0 to 1.1 to 1.2 to 1.3. Then 1.4 comes along and all kinds of things go weird :). Lets hope 1.5 is an improvement. 4:04:22 PM    comment []

More on Ted's techies and modelers I enjoyed Ted's thoughts on techies and modelers. I tend to sit on both sides of the fence depending on the part of a system I'm working on at the time. Without being a techie its hard to be a good modeler otherwise you end up creating leaky abstractions. Wearing both hats can help round your viewpoint & skills. Focussing too closely on being a techie sometimes (i.e. caring too much about the low level details, bits & bytes) can sometimes make you loose sight of what you're actually trying to do and force you to optimise the wrong thing. Being a modeler helps you to focus on the end user of your code, what the public API looks like rather than overly worrying about how you happened to have implemented it today. The Java language and runtime provides a nice elegant model (abstraction) under which JVM techies can do all kinds of wierd and wonderful things (HotSpot, JRockit, IBM's JVMs etc) for garbage collection, JIT, synchronization, RTTI etc yet it provides a solid, stable, abstract foundation for us all to build. The same modeling abstractions are vital at points in our infrastructure too to allow techies to optmise implementations. e.g. APIs like JDBC, JNDI, JMS, JTS are all vital to raising the abstraction level and providing competition. I won't try to defend EJBs though :) Like most things in IT (and life I suppose), the trick is in getting the right balance. 2:18:57 PM    comment []