A minor mod to BTree ...

  • Alan Littleford

    Alan Littleford - 2001-11-30


      I modded BTree slightly so that it can take a null comparator. In that case it attempts to coerce keys to Comparable and then uses the compareTo() method. This means that standard types (Longs, Ints, Strings, Dates etc) don't have to have the somewhat superfluous LongComparator etc passed around.

    Changes are needed in BTree.java:

         * Find the value associated with the given key.
         * @param key Lookup key.
         * @return Value associated with the key, or null if not found.
        public synchronized Object find( Object key ) throws IOException {
            if ( key == null ) {
                throw new IllegalArgumentException( "Argument 'key' is null" );
            BPage rootPage = getRoot();
            if ( rootPage == null ) {
                return null;

            Tuple tuple = new Tuple( null, null );
            TupleBrowser browser = rootPage.find( _height, key );

            if ( browser.getNext( tuple ) ) {
                // find returns the matching key or the next ordered key, so we must
                // check if we have an exact match
                int cf;
                if (null == _comparator)
                    cf = ((Comparable) key).compareTo(tuple.getKey());
                    cf = _comparator.compare(key, tuple.getKey());
                if ( cf != 0 ) {
                    return null;
                } else {
                    return tuple.getValue();
            } else {
                return null;


    and in BPage.java:

        private final int compare( Object obj1, Object obj2 ) {
            if ( obj1 == null ) {
                return 1;
            if ( obj2 == null ) {
                return -1;
            if (null != _btree._comparator)
                return _btree._comparator.compare( obj1, obj2 );
                return ((Comparable) obj1).compareTo(obj2);


    Thanks for all the good work on JDBM

    Alan Littleford

    • Cees de Groot

      Cees de Groot - 2001-12-02

      You have the same if statement at two places. It's
      cleaner, and better style, to have a DefaultComparator that does the casting stuff and put that in place of null whereever _comparator is set. Then you don't need the two if statements, and knowledge about this 'trick' is confined to a single place.

    • Alan Littleford

      Alan Littleford - 2001-12-03


        yes I know -- I just wanted to make the change very obvious without any refactoring -- I don't know to what degree people maintaining the code want to get 'ideas' as opposed to ready-to-drop code.



      • Alex Boisvert

        Alex Boisvert - 2001-12-06

        Hi Alan,

        Sorry, I was away in Mexico last week...

        Any patch is more than welcome!  We review them before integration to ensure they pass all the unit tests and to maintain overall code quality.

        I'm working on a significantly changed codebase right now, to accomodate some other user requests.  Using java.util.Comparator and Comparable is on the list of things I'm working on and should be in the next release.  As such, your patch won't be applied directly but the result should be the same...  No need to supply a custom Comparator for any of the basic Java types.

        Thanks for your input.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks