[Biojava-dev] Java 1.5 (final chance to object)

[mark.schreiber at novartis.com]

>Stability and backward compatibility are crucial to the success of 
BioJava.
>In fact, if the code is not too complex, I often have to write it myself
>rather than
>relying on BioJava. I want to write code that will still be in production
>5 years from now.

This stems from the fact that for several years package stability wasn't 
really a design goal. This was good cause often our first attempts where 
not that good. Having said that, stability is definitely a goal now. I 
beleive there has been a great reduction in major API changes between 
recent versions. Indeed many core interfaces have not changed in a long 
time. But we do need to remain vigilent. Basic rule, do not break the core 
org.biojava.* API's!

There are some reservations to that. 1) Deprecation will happen. There is 
nothing wrong with deprecation of a bad or unsupported API and as long as 
it is flagged well before releases come out. Preferably there should be 
one or two releases where a method or class is deprecated before it is (if 
ever) finally removed. 2) New packages in CVS should never be considered 
stable. If an API has not been part of a release version I don't think we 
need to guarentee stability.

When org.biojavax is released no org.biojava.* API will be removed or 
changed. Some will be deprecated as the org.biojavax APIs may give you a 
better alternative. They are not really seperate APIs, more extensions 
that give more fexibility and sometimes do things better (like swing is to 
AWT). The part where people may see problems is interactions with BioSQL. 
Previously biojava worked with bioSQL but not in the way it should 
according to the bioSQL specs. The new version will bring it into line 
with bioSQL. The old APIs will remain should people need to access legacy 
data in bioSQL DBs created with the old API.

>I say that, not because I don't appreciate the hard work of developpers,
>but because I would like the volunteer developpers to appreciate that
>the users of the toolkit need stability. We live in production 
environments
>that will not support 1.5 for a long time. I am still living in a 1.3 
world.
>Only projects that I am starting right now can use 1.4.2_08.

The major releases from the past support the following versions, 
biojava1.3 and biojava1.3.1 work with JDK1.3.x and biojava1.4 works with 
JDK1.4.2. You should never prepare production code from versions of 
biojava in CVS. The best way to make production code is to bundle all your 
application dependencies into the application JAR. This way everything is 
in one place and no external changes affect it (and keep the required 
version of the JDK available if you upgrade to a new one). It's not 
elegant but it is bullet proof. There are other approaches that work too 
but need more management.

>I beg you, Please reconsider moving to 1.5, it's only 5% more typing to 
use
>1.4.

Sure, people just need to stop dropping 1.5 dependent code into the CVS. 
Please note though, biojava1.4 will never require java1.5, it would only 
affect future versions. Richard is planning a preview of biojavax in 
december. We may revisit the issue then.

Ps, what JDK is caBIO running on now?


Mark Schreiber
Principal Scientist (Bioinformatics)

Novartis Institute for Tropical Diseases (NITD)
10 Biopolis Road
#05-01 Chromos
Singapore 138670
www.nitd.novartis.com

phone +65 6722 2973
fax  +65 6722 2910


_______________________________________________
biojava-dev mailing list
biojava-dev at biojava.org
http://biojava.org/mailman/listinfo/biojava-dev
_______________________________________________
biojava-dev mailing list
biojava-dev at biojava.org
http://biojava.org/mailman/listinfo/biojava-dev