[Biojava-dev] BioJava code freeze, modularization and action items for sub modules

Tue Aug 25 17:36:45 UTC 2009

I agree with all that has been said so far. The Sequence/Feature model
is definitely not good enough and well, also does not work for protein
structures.  (There can be alternate positions and the numbering can
be non-sequential and have negative positions.)

Still the question is, do we need to throw away the backwards
compatibility? The new modularization will allow a plug and play
architecture and we could easily have two generations of code in
different modules. That way legacy code could depend on the older
"core" (perhaps we should find a different name) while newly written
code will be based on biojava-sequence, which would contain Richard's
new code. That way we could prepare the code for the future, while
still embracing the past.

One example that heavily uses the Sequence and Distributions APIs is
NestedMica. It is a pretty cool machine learning software and I was
hoping that we could bring that closer to biojava. (a machine learning
module in BJ would be cool, no?)

Andreas

On Tue, Aug 25, 2009 at 1:45 AM, Jules Jacobsen<jacobsen at ebi.ac.uk> wrote:
> I think Mark has a good point here - there are certain aspects of
> BioJava which are considered to be un-necessarily over-complicated and
> these things have been deal-breakers for the people concerned - I
> remember a couple of cases from the EBI where they have implemented
> their own system instead of using and supporting BioJava.
>
> Fixing areas of confusion, simplifying and moving forwards without
> maintaining backwards-compatibility might be a good idea for
> increasing user numbers and elevating the general perception of the
> project, whilst potentially risking alienating some existing users.
>
> I think his idea of maintaining compatibility within point releases
> and stating that full version releases may not have backwards
> compatibility would make it clearer for users as to what to expect
> from a release. It may also help the developers stay on track with the
> task and general design focus for that release by constraining them to
> the current system during a point release whilst highlighting
> confusing areas which can be dealt with in a more satifsfactory manner
> in the next full release.
>
>  Jules
>
> On Tue, Aug 25, 2009 at 7:58 AM, Mark Schreiber<markjschreiber at gmail.com> wrote:
>> I would agree with Richard on this. I think the changes being proposed
>> are not compatible with the current API. There are a couple of things
>> wrong with the current model (such as the Feature, Strand, Location
>> issues). There are also several areas where best-practices of the past
>> (parts of BioJava are 10 years old) are not considered best practices
>> now (some like Singletons are often thought of as anti-patterns these
>> days).
>>
>> Add to that the fact that we have never been truly backwards
>> compatible (expept maybe 1.3 and 1.3.1 ?)  and I think we can
>> justifiably try and avoid the claim that BJ1.7 should be backwards
>> compatible.  We can continue to make older Jars available for people
>> who need them although most likely people who have a need for legacy
>> support already have the Jars that they need bundled up with their
>> apps. Shared libraries have very much fallen out of favor in recent
>> years in almost all languages and system wide classpaths are asking
>> for trouble.  Hard-drives are cheap so it is no big deal to have a
>> dedicated version of the BioJava jar bundled with each app that needs
>> it.
>>
>> We could adopt the idea that backwards compatible builds get
>> minor-version numbers eg 1.1 while other builds get major version
>> numbers. I guess this would mean we are at BioJava 7 ?
>>
>> Backwards compatibility would be great to have but not if the effort
>> required hinders innovation.
>>
>> - Mark
>>
>> On Tue, Aug 25, 2009 at 12:32 PM, Richard Holland
>> <holland at eaglegenomics.com> wrote:
>>>>
>>>>
>>>> What I mean is that we should try not to disrupt things as much as is
>>>> reasonable. I am all for a pragmatic approach. While trying to be
>>>> conservative I guess refactoring should be discussed on a case by case
>>>> basis. To give an example: an area where I am supporting re-factoring
>>>> is the blast parser. The package name is confusing and we probably
>>>> need some code changes to expose more details of the parser. Are you
>>>> thinking of any other situtations, where you think breaking backwards
>>>> compatibility will be inevitable?
>>>
>>> Almost all the parsers would fit this category, as would any realistic attempt to 'fix' the sequence model by moving bits of the APIs around (for instance, Sequences have Features which have Strands, but Locations do _not_ have Strands - which is all wrong, because Strand is a Location-level concept, not a Feature-level concept).
>>>
>>> My original plan was to not even attempt to make new versions backward compatible, and instead to have a separate module which coerced the new objects into complying with the old API interface declarations (by using the facade model).
>>>
>>> cheers,
>>> Richard
>>>
>>>> Andreas
>>>>
>>>> _______________________________________________
>>>> biojava-dev mailing list
>>>> biojava-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>>>
>>> --
>>> Richard Holland, BSc MBCS
>>> Operations and Delivery Director, Eagle Genomics Ltd
>>> T: +44 (0)1223 654481 ext 3 | E: holland at eaglegenomics.com
>>> http://www.eaglegenomics.com/
>>>
>>> _______________________________________________
>>> biojava-dev mailing list
>>> biojava-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>>
>> _______________________________________________
>> biojava-dev mailing list
>> biojava-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>>
>
>
>
> Jules Jacobsen
>
> UniProt-PDB Integration
> EMBL-EBI
> Wellcome Trust Genome Campus
> Hinxton
> Cambridge
> CB10 1SD
> UK
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>