/* Major problem areas */

dicknetherlands · andreasprlic · commit 3d59ac41c469 · 2016-04-09T10:57:49.000-07:00
diff --git a/_wikis/BioJava3_Proposal.md b/_wikis/BioJava3_Proposal.md
@@ -147,6 +147,16 @@ Major problem areas
     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.
 
 Categories of Improvement
 -------------------------
diff --git a/_wikis/BioJava3_Proposal.mediawiki b/_wikis/BioJava3_Proposal.mediawiki
@@ -54,6 +54,8 @@ It is suggested that development stop on the existing BioJava/BioJavaX/BioJava2
 #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.
 #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).
 #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.
+#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.
+#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.
 
 ==Categories of Improvement==
 
