directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hayes <>
Subject Re: [bdbje] [rms] Using int verses Integer and native key/value ordering
Date Mon, 19 Apr 2004 17:00:09 GMT
On Apr 16, 2004, at 2:17 PM, Linda Lee wrote:

>> 2). Also is there a way to not have to wrap primitive types using the
>> binding API's - basically is there some means to just setData on an  
>> entry
>> but get the binding to produce a byte[] from a int and not an Integer
>  Mark is the expert here, but you can use the tuple classes to create  
> your own custom binding. Or you could use  
> com.sleepycat.bind.tuple.TupleInput, TupleOutput  to read and write  
> primitive types to a byte buffer. See  
>  The general notion is that you create a TupleBinding, using the  
> TupleInput/Output to get you from your object to the byte array, but  
> you could also use them independently.  The Getting Started Guide has  
> some examples:  
> bindAPI.html#customTuple

There is currently no way to use bindings to operate on primitive types  
directly.  To do that, we would need to add methods for getting and  
setting each type of primitive.  Plus, in order to use bindings with  
collections, the bindings have to support the wrapper classes, since  
collection methods all take and return Objects.

As you say in your other post, the wrapper classes don't add  
significant performance overhead.  Using wrapper classes is a slight  
inconvenience, but the eventual solution to that problem is to use the  
auto-boxing feature of Java 1.5.

However, as Linda mentioned, if you want to optimize for a particular  
case you can create a custom tuple binding that had methods for get/set  
of the "int" type, for example.  I'm happy to help with that if you're  

Your questions on this have me thinking about a possible addition to  
our binding API.  Currently, TupleBinding has a static method,  
getPrimitiveBinding, that returns a binding for a given primitive  
wrapper class.  As an alternative, we could expose the (currently  
private) IntegerBinding, FloatBinding, etc, classes, and add methods to  
those classes that take "int", "float", etc, types.

Do you think that would be a worthwhile addition?  I'm not promising  
that we would do this, as I'm sure you understand, but I'm very  
interested in your opinion.


View raw message