[Biojava-l] Serialization and 1.2

Thomas Down td2@sanger.ac.uk
Tue, 22 Jan 2002 09:00:44 +0000


On Tue, Jan 22, 2002 at 03:33:54PM +1300, Schreiber, Mark wrote:
> 
> A while ago there was some discussion of serialization of biojava
> objects and the problems of rebuilding things like alphabet indexer. Is
> it a realistic goal to get this up and running with some jUnit tests for
> biojava 1.2?

Um, I should think so.  If turns out that it's going to take
a while, we can always put it into 1.2.1 instead (aside: I'm
hoping that the 1.2 branch will be rather more active than 1.1
was -- I don't think we're going to see the same degree of core
interface changes which made porting bug fixes between branch-1_1
and the HEAD difficult).

As far as I can remember, the problem is not so much
rebuilding the AlphabetIndexes as ensuring that the serialized
form isn't dependent on the indexes.  Easiest way would
seem to be adding explicit writeObject/readObject methods,
then serializing as a list of (Symbol, double) tuples.

The alternative would be to make the AlphabetIndexes themselves
consistent (or maybe even serializable).  I don't really like
this, since if the indexes turn out to be almost (but
not 100%) stable, you'll get occasional data loss which is
hard/impossible to detect.  But I'm open to ideas.

> I wouldn't mind helping (due to considerable self interest in this) as
> long as someone can point me to some good JUnit documentation and
> suggest a way that things like alphabet indices can be reliably built.

Great!

There's some documentation about JUnit on the website:

   http://www.junit.org/

Although it's not always too easy to separate the documentation
from the Extreme Programming advocacy/propaganda.  Actually,
the tests are dead easy to write -- copy-pasting an existing
one may help.  In brief.

  - Any class in the tests/ tree with a name containing the
    word "Test" is a test-case :-).  [note, this constraint means
    that you can check non-testcase classes into the tests/ tree,
    if there's some utility code which should be shared between
    several testcases].  

  - A TestCase class should contain:

     + (optionally) setUp and tearDown methods for initializing
       any data which is used within the testcase.

     + one or more methods of the form:

        public void testFoo()
            throws Exception
        {
	    assertTrue(testedObject.somethingThatMustBeTrue());
            assertEquals(testedObject.getCounter(), 5);
            // etc...
        }

I think that pretty much covers it!

Give me a shout if you need any help with this,

    Thomas.