[Biojava-dev] The future of BioJava

[Mark Schreiber]

> You cannot kill biojava and it is not vista; you cannot force people to use it. I have a project with hundreds of classes using biojava and working without a glitch and the choice of either keeping with it or switching to a bj3 in the middle of a rewrite of around 1500 classes that may take months or years to complete. I may just never switch to the new biojava. Most likely, a lot of people are going to be in a similar situation and most likely bj3 will also have to have support old biojava classes - great!
>

If a new version of biojava came out that was not compatible there
would be nothing to stop you from keeping the olb bj1.5 jars in your
lib directory and letting your application work off them. I've never
been a fan of global class paths.  Additionally if you don't need to
switch there would be little point. There is little point in switching
from bj1.4 to 1.5 unless you need some new feature or bug fix.  Bj1.4
and 1.5 were also the first to even attempt backwards compatibility so
I'm not totally convinced we need to support old classes and
interfaces.

I would hope the motivation for a switch would be a cleaner and easier
to use code base. Your correct, we can't force people to use it.

> I agree that you cannot change interface but you can deprecate them and toss them after one release cycle or put them into a deprecated module that is not included in releases.
>

Dropping a deprecated interface is about the same as changing it in
terms of backwards compatibility. Although you do have the advantage
of a little more warning.

> The question becomes: what are the fundamental problems of biojava that truly justify a rewrite from the ground? Certainly, need for a new symbol model could be one; maintenance and testing are not; modular structure is not; and use of generics is not - they do not break old code.
>
> George
>

I would say the main argument is improving ease of use and getting
away from the singleton symbol model.

With generics I am interested to know what happens when you take an
interface that requires List and change it to require List<Symbol>
such as.

public void foo(List l);

to

public void foo(List <Symbol> l)

Due to erasure this may not break, old code would still run, however
old code would probably no longer compile.

- Mark