Alex Boisvert wrote:
> First, thanks for bringing that up! Without an official roadmap, I
> guess we're unofficially in maintenance mode ;)
> Cheap jokes aside, the reality is that I've done very little work on
> JDBM in the past years. I haven't declared maintenance measures yet
> for a good reason: I see plenty of work ahead! It's just that I haven't
> gotten to it!
> I'm very open to having people participate, improve and generally inject
> more life into JDBM. I've granted some CVS commit access in the past
> to promote this... and have accepted enhancement patches, bug fixes,
> etc. But agreed, it's been slow and somewhat dead for a while over here.
> I think the best place to start is to formulate specific goals as to
> what people want and what needs to be done. The use of streams in the
> TransactionManager doesn't bother me much because JDBM fits my needs,
> but if you think you can do better and want to contribute something,
> great! I'll make sure you've got (or anybody else has) the proper
> power to make it happen.
Well, I only noticed it when I had to make a batch insert of a couple of
million objects. While the computer was chugging along I read the TM
code and realized it could be made much more efficient. Did you for
example know that the ObjectOutputStream constructor is dead slow? Or
that serializing an object using the plain OOS will write tons of stuff
just for the class descriptor? Stuff like that could be much improved.
Adding a buffered stream beetween the OOS and the file stream would do
wonders as well.
Small things, but they add up pretty quickly.
On the bigger issues I would like to make a refactoring to make JDBM
more PicoContainer friendly, which essentially just means to decouple
things even more. This isn't strictly necessary, but would make it
easier to extend and compose different types of managers.
> Things that have been discussed in the past that I think are worthy:
> 1) BTree index key compression
Yes, that'd be nice.
> 2) Implement collections interfaces to follow Java idioms
+1 on this one too.
> 3) Improve concurrency and transaction management
> (JDBM is thread-safe but isn't exactly MP-friendly)
Yeah, and do more stuff to make backup management better.
> 4) Improve I/O -- think java.nio
Yeah, that'd be nice too.
Another biggie would be to have transactional support, but without the
log file. When doing batch inserts using transactions help minimize the
number of writes, but the log file makes up for a lot of unnecessary
> In all, I'd be happy to provide support and guidance for any of those
> projects. In following the open-source philosophy, I'd also be happy to
> see people scratch their own itch since mine don't itch much (or enough)
> these days. <grin>
I'll take that as a "go for it" :-)