BioJava 3 has been released

This page was used while starting the discussions for creating the new version. BioJava 3.0 has been released on Dec. 28th 2010.

BioJava3_project

Executive Summary

It is suggested that development stop on the existing BioJava/BioJavaX/BioJava2 aggregation and start afresh as BioJava3.

General reasoning

Proposal

Data structure

Action plan

  1. Please modify this page and the Talk page as you see fit in order to flesh out details and/or make new points.
  2. Tentative Singapore meeting to get the ball rolling on the final design and initial coding front.

Previous work on the subject

  1. Michael Heuer’s proposal for static generic symbols/symbol lists.
  2. Matthew Pocock’s BioJava2 proposals.

Major problem areas

  1. The singleton symbol model is hard to use and understand. It needs simplification.
  2. Strand is specified on feature and not on location. This is not biologically logical.
  3. Sequence and Feature objects are tightly bound - Features can’t exist without also loading and assigning the appropriate Sequence object. This slows things down and uses memory.
  4. In general, most operations require a Sequence object underlying whatever object you are manipulating. At the time BioJava was designed and written, this was fine as most biologists were interested in sequence manipulation. Now they have moved on and are more interested in sequence meta-data such as features or protein structures or microarray experiments or phylogenetics. To enforce having to load the sequence for every feature in a region of interest before doing even basic analysis is wasteful of resources, and illogical. BioJava needs to lose the Sequence-centric view of the world.
  5. Interfaces that have already been deprecated in the 1.5 release need removing entirely. Many of them are heavily used within the existing code base, e.g. Sequence. To remove them would require a rewrite of almost the entire codebase anyway, and also a rewrite of most client code (e.g. to use RichSequence as the default replacement for Sequence, which would no longer exist).
  6. The code base doesn’t take advantage of the possibility of threading for multiple CPU’s. Dual core cpu’s are now standard on everything. Quad cores are common on servers. If code is threaded the JVM can easily make use of these extra cores. Additionally many parts of the code base are currently not thread safe.
  7. Most of the code is not bean-like and therefore cannot easily be used in any of the modern Java EE frameworks such as Spring or Hibernate.
  8. Equals, compareTo and hashCode methods are inconsistent and often inaccurate, e.g. customised to suit a certain behaviour pattern (e.g. the BJX extensions assume that nulls are allowable for the purposes of Hibernate, whereas really they shouldn’t be and Hibernate doesn’t need them either). Changing these would change the behaviour of the object model particularly when it comes to collections and maps.
  9. Localisation causes mistranslation of strings from lower to upper case. For instance, in Turkish, the lower and upper case i/I do not match those in the English localisation. This causes protein sequences to be mistranslated or misrepresented. BioJava needs to be modified to take this into account.
  10. BioSQL interaction is good but there are still issues - particularly to do with case conventions for naming things such as alphabets. A BioSQL mini-hackathon has been suggested as one way to nail down exactly how BioSQL should be used, right down to details like this, so that all projects may be able to fully interact without knowledge of which tool was used to write the data to BioSQL.
  11. Gapped sequences and alignments need closer attention. Currently there are two ways - a SimpleSymbolList with ‘-‘ symbols, or a SimpleGappedSymbolList with proper block definitions and coordinate translation and access to the ungapped sequence. The MSF alignment parser uses the former which is counter-intuitive as programmers reading alignments would expect simple access to the ungapped sequence. There is no easy way to translate between them if you need the more advanced features such as coordinate translation from gapped to ungapped sequence. By allowing gap symbols directly in SimpleSymbolList, it is impossible programmatically to enforce whether a method accepts gapped or ungapped sequences.

Categories of Improvement

Initally suggested by Andreas this attempts to group the currently recognized issues surrounding Biojava. See also UsageAnalysis.

Category A

How to work with core concepts of BioJava:

Category B

Functionality; taking on concepts/practices from Category A and applying them to a bioinformatics problem.