[Biojava-l] summary of comments relating to JDK 1.4

[Humphrey Sheil]

Hi all

I have two things to talk about here:

1.  Pressures on how / when to upgrade jdk version

2.  logging in core libraries.


I've been through point 1 twice, moving from 1.1.{6,7,8} -> 1.2.1 and from
1.2.2 -> 1.3.

We always ended up moving because:


1. Sun start making noises about 'support tracks' for the JDK we're using.
This means we don't get new features, and only major outstanding bugs are
fixed.  Eventually, a vendor we rely on (e.g. BEA) makes the jump themselves
and you always want to be ahead of that decision.

2. We are comfortable with the candidate JDK.  For us, that meant running a
copy of our code in parallel on the new JDK, looking out for stability and
general flakiness issues.  That reduces the risk and gets developers up to
speed at the same time.  At the moment, we're running our J2EE app. server
on 1.4 along with other core parts of our system for a week plus, with no
problems yet (CPU usage, memory usage etc.  we're testing thread pools,
jdbc, file io, socket io, JNI and access to java.lang.Runtime).  So that is
a strong positive for us to consider going to 1.4.  Next up is a test on an
SMP box and loadtesting.

3.  Our development toolset supported the new JDK, making the move that bit
less painless.  With ant, junit etc. and lightweight IDEs, toolsets now tend
to come over easily.  If you are using Visual Age or another IDE that needs
a particular JDK, your toolset will be a source of problems.


But the main reason we upgraded was because we needed to.  Hotspot came out,
and we saw performance improvements of between 33-50% over the best JIT at
the time.  Then newer revisions of GC came around that solved pauses we were
having.  We were using BEA weblogic 4.5 and 5.1 and it became obvious that
1.2 was the preferred JDK.  Basically pressure built up from different
sources that made it clear that the newer JDK was a big improvement over our
current choice.

New apis are nice, but unless they absolutely give something you don't
already have (and need badly), they don't provide you with critical mass to
jump to the new jdk release.

Thomas, I take your point fully RE:  Tru64 support, but why would you see
MacOS X as another must-have platform?

RE:  logging, there are two groups of people who are involved with a code
library.

a. Core developers and they need logging.

b. End-users and they don't need logging.  e.g. when I use java.util.Vector,
I definitely don't want logging enabled; but if I worked for Sun and was
asked to refactor that class, I would want a logging service to be available
to my code, as part of my testing process.

So why not add logging and ship biojava with it turned off by default?

>>its pretty easy to create an aimplementation that logs and
>>delegates the real behaviour to a seperate implementation class.

This is another solution, but unless I'm reading your intentions
incorrectly, necessitates 2 times the number of core classes, the second
copy of which is there just to log?

Regards

Humphrey