directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Oid class
Date Sat, 03 Jan 2015 16:59:40 GMT
Le 02/01/15 16:19, Lucas Theisen a écrit :
> I was thinking about optimizing Oid...  The Oid class represents OID
> values.  There is a relatively small finite set of OID values. 
Quite not... OID is supposed to be infinite, and was invented to
represent everything possible.

But...

>  I was
> thinking we could get rid of the constructors and use factory methods
> instead. 
Yes, that would make a lot of sense. In regard to your first sentence, I
would say we are manipoulating a very small set of OID, there is no need
to create them everytime.

So my +1 to the Factory approach.

>  One for getting an Oid by String and one by byte[].  I would then
> remove the setters, do the conversion to byte[]/String at construction
> time, store both values, and change getOid to return a copy of the byte[]
> to make it immutable.  Then, the first time an Oid is requested, it would
> be constructed, and every following request would get the same object.
> This would make comparisons faster and remove conversion time altogether
> (other than the first request).

To be frank, stroing the values in a long[] was a double mistake :
- first it's certainly not the right data structure when it comes to be
efficient in Java
- second because an OID number is supposed to be illimited, when long is
limited by nature.

I do think that storing the OID as a STring and as a byte[] makes
totally sense.
>
> The main problem of doing this is that the current methods/constructors are
> public so there is no telling if anybody is using them other than us.

Don't worry too much. Keep them, and mark them as deprecated. Keep in
mind we are still releasing milestone.

One import things though : the setOid() method is controlling that the
OID is valid, not sure it's necessary to keep it.
> Also, they would all remain in memory (though given the relatively small
> number and their small size it should be relatively negligible).

+1. You can also limit the number of OID we keep in memory, using a
cache, but taht would be overkilling, IMO.
>
> My current reason for wanting to do this is i need to check all extended
> requests to see if they are startTLS requests.  In order to do that, I have
> to wrap the connection and intercept the exteneded function and check the
> oid.  In the case where an OID object is supplied i need to verify it so I
> have to either construct an OID and use equals, or toString the oid and do
> a string compare.  Both would have cost.
>
> This is almost certainly a premature optimization, but sometimes you just
> feel like doing things as efficiently as you can think...

No, I think it's a good thing to revisite the existing class, which has
been defined 9 years ago. Actually, it's funny :
http://svn.apache.org/viewvc/directory/sandbox/trunk/asn1-new-codec/src/java/org/apache/asn1/primitives/OID.java?revision=178102&view=markup&pathrev=200000

      /**
       * Creates a new OID object.
       */
       public OID()
       {
      
       // We should not create this kind of object directly, it must
       // be created through the factory.
       }



Mime
View raw message