I think we should go ahead and fork then inform the JDBM peeps. But the fork should not change package names so when and if the JDBM peeps update JDBM we can drop our fork if possible. I hate to have to fork but what can we do. Just make sure you commit JDBM as is then apply your changes so we can track what changes we've made to report back to the JDBM folks with diffs from our repo.
BTW there's a nasty little bug in the JDBM Browser implementation that was causing me a big headache with the Cursors. It's really a bitch to deal with but probably easy to fix in the JDBM code. The browser once I create one and start using it to advance in one direction requires to operations in the reverse direction to start advancing backwards. For example:
BTree may contain:
10 browser = btree.browse();
20 browser.getNext(tuple); => true with [1,1]
30 browser.getNext(tuple); => true with [2,2]
40 browser.getPrevious(tuple); => true with [2,2]
50 browser.getPrevious(tuple); => true with [3,3]
Notice lines 30 and 40 is where the direction change occurs and it requires two getPrevious() operations to move one tuple back. The same problem exists if we switch directions in the opposite way. So this fork gives us a chance to fix this issue.
while modifying the server (directory), I had to modify the JDBM code to add a setter for the BTree class (setValueSerializer()), simply because I need to use a specail serialize, which takes a set of data in order to be able to create deserialized objects. The fact is that if we already have a file containing some data, the BTree ressucitate the valueSerialalizer from the file, using a standard deserialization process.
I think I can modify the RecordManager in order to create a new instance of the ValueSerializer, but I find this a little bit cumbersome.
Anyway, I just want to know if we can do this modification on the JDBM code base, if there is any chance that a JDBM 1.0.1 can be release, or if we simply have to fork the project and define it as a subproject of ADS ?