I had to do some significant work in order to get jdbm to
persist the serializer state. I would suggest that you look at the code
more carefully rather than just rolling it back. Assuming that xstream
uses a stateful serializer, you are going to want to preserve the integration
By "stateful" serializer, I mean one that maintains
persistent state NOT recorded in the individual serialized records. extser
factors out what serializers are declared, the class ids (int's) assigned to
each class for which there is a registered serializer, and the corresponding
serializer version(s) and puts that all into a persistent record accessed off of
one of the named roots for the store. This makes it extremely compact when
serializing object graphs. The shared state is all factored out.
In order to support that I had to put in a bunch of hooks that you will
want to keep around.
Another issue with versioned serializers is that they
basically have to be inner classes in order to access the various fields (unless
you want the overhead of reflection during serialization!). One of the
changes that I introduced with the extser integration was transparently
versioning for the btree nodes and leaves for stores that choose to enable
extser. If that forward versioning is important then you are going to wind
up with something that's tightly coupled regardless.
If the broader issue is the dependency, then Cees already
imported extser and I "authorize" its relicensing under the license for the jdbm
[mailto:firstname.lastname@example.org] On Behalf Of Mark
Sent: Tuesday, June 10, 2008 12:54 PM
Cc: 'Cees de Groot'; email@example.com;
Subject: Re: [Jdbm-general] extensible
Bryan Thompson wrote:
it's not so much the overhead, its
the extra dependency. Even if you don't use it you are forced to include it,
because Serialiser extends it. So if we are to use it, it needs to be
"plugged" in, so that it's optional.
Well, easy come, easy go - but you might want to see
who's using it before you drop it out.
There is zero overhead when extser is not
The LGPL is a wierd issue,
basically Apache takes a stand against LGPL and will not allow any of it's
projects to depend on an LGPL dependency. This would force Apache DS to have
to fork JDBM to maintain a version without that LGPL dependency. It's not that
they think that LGPL is causing any wierd violation, they just don't like some
of the ambiguity, and thus fall on the side of caution.
Cees de Groot
Great, I'l update and look over it.
For me I just want JDBM to write my byte, I don't want it to go anywhere
near a serialistion method call, I'm currently just trying to find out if
that is possible.
On Mon, Jun 9, 2008 at 4:24 PM, Cees de Groot <firstname.lastname@example.org> wrote:
I grabbed the extensible serializer source code and added it to the
source tree - the original project doesn't seem to exist anymore so I
thought this was the quickest way to get rid of a binary-only
On second thought, I agree it's not good to have JDBM depend on a
single serializer. So I'm removing the dependency (rolling back to the
pre-extser tag in CVS and checking what happened after that)