Running a Java 1.3.1 JDK on Debian

By Confusion on Monday 1 September 2008 09:29 - Comments (4)
Categories: Java, Software engineering, Views: 3.200

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.

Volgende: Waterkoker of fluitketel 09-'08 Waterkoker of fluitketel
Volgende: An XSLT to turn XML into CSV 08-'08 An XSLT to turn XML into CSV

Comments


By Tweakers user merlijn85, Monday 1 September 2008 13:45

So why not use a newer JDK and specify -target 1.3 (or target="1.3" in the Ant build.xml), this is the out of the box method for compiling stuff that should be compatible with older versions of java.

By Tweakers user Gerco, Monday 1 September 2008 18:44

Because "-target 1.3" only compiles for JDK1.3, but will not allow you to validate the program against the JDK1.3 class library. You would not be able to test whether you really had fixed the bug or not.

By Tweakers user Confusion, Monday 1 September 2008 21:02

@merlijn85:
Exactly: 'should' :). I'd rather err on the safe side of caution and compile the code with, and test the code versus, a real 1.3.1 JDK.

One example why you may run into problems, is because people sometimes use classes whose future isn't guaranteed. For example, in Java 6, you have the java.text.Normalizer class, which is immensely useful for normalizing text containing diacritical marks. However, in Java 5, this class was already available as sun.text.Normalizer. Using it wouldn't have been 'the right thing' to do, but it may have been a pragmatical thing to do, especially if you don't expect the code ever having to run on two different JVM's at the same time.
edit:
On second thought, this isn't a good example, since in that case, you would only compile and run the code on JVM's where that class was available anyway

[Comment edited on Monday 1 September 2008 21:05]


By Tweakers user merlijn85, Tuesday 2 September 2008 10:10

@Gerco,
Testing against every jvm is generally a good idea, but on many occasions it simply isn't manageable. These days the Sun JVM is very popular, while with the old versions there was more competition between Sun, MS, blackdown and other implementations of the JVM.

With other implementations you must be wary about things like cryptography, as they may use different naming scheme's or not implement certain algorithms at all.

For bugfixing you mostly won't need special functionality. So in 99% of all cases, it is safe to assume that if it works on your JVM, it will work on any the original worked on as well.

@Confusion,
Doing this gives you the big downside that you cannot use code that does work in newer versions of the JVM. Here is a snippet of code that would tell you if you can use a certain function or not. Note that System.nanoTime() is only available from 1.5 and up.

boolean available;
try {
System.nanoTime();
available = true;
} catch (Throwable t) {
available = false;
}

This bit of code will compile only on JDK 1.5+, but if compiled with -target it will work on any JVM. You could use this as well with sun.text.Normalizer, however even Sun recommends leaving these classes alone. Also you should provide a backup method or spawn an error if it is unavailable.

Comments are closed