[Biojava-l] IndexedSequenceDB

[Matthew Pocock]

Hi. Matthew here.

Just got back from traveling - ISMB was great.

Thomas Down wrote:

> On Wed, Aug 23, 2000 at 12:04:33PM +0200, Gerald Loeffler wrote:
> > hi!
>
> Hello!
>
> > I've a few comments regarding class IndexedSequenceDB. Since the author
> > of this class is not given in the source code, i can't direct these
> > comments directly to him/her:
>
> It was written by Matthew, but he's still away at ISMB -- he'll
> be back in the mean time:
>

Yep - my fault.

>
> > o method openDB() behaves differently than it is documented in its
> > JavaDoc comment: when the given index file does not exist, it throws an
> > exception.
>
> That looks like a documentation bug to me -- feel free to fix it.
>

Doc bug - do you think that this is too restrictive? You need more invo to
create an index than to open one, so that is why I made it paranoid.

>
> > o methods such as addFile() and especially commit() should really be
> > synchronized!
>
> Yes.  I haven't got time today to do a full check on the concurrancy
> issues in this class, but again feel free to have a go if you want.
>

Definitely - I think that you should lock on the IndexedSequenceDB instance
so synchronized methods will work just fine.

>
> > o i may be completely blind here but why are the non-final fields
> > fileToReaders and idToSource initialised in a static initialiser block?
>
> They aren't.  As well as static initializer blocks:
>
>     static {
>         // initialize static fields.
>     }
>
> Java also allows object initializer blocks.  So the following:
>
>     private Set x = new HashSet();
>
> can be rewritten:
>
>     private Set x;
>
>     {
>         x = new HashSet();
>     }
>
> In fact, the compiler will (I believe) generate identical code
> for these two cases.  I know Matthew uses the second form a lot.
> I quite like it, too -- especially when you want to do something
> non-trivial on object initialization.
>
> I guess it comes down to personal preference, though -- both
> work fine.
>
> Thomas.