[lang] UUIDUtils

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[lang] UUIDUtils

Jörg Schaible-3
Hi fellows,

any objection to add UUIDUtils to lang (LANG-778)?

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] UUIDUtils

garydgregory
Hi,

What about http://commons.apache.org/sandbox/id/ ?

If IDs are important, this project should be in play on its own or folded
into [lang].

Thoughts?

Gary

On Tue, Nov 22, 2011 at 8:16 AM, Jörg Schaible
<[hidden email]>wrote:

> Hi fellows,
>
> any objection to add UUIDUtils to lang (LANG-778)?
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [lang] UUIDUtils

Jörg Schaible-3
Hi Gary,

Gary Gregory wrote:

> Hi,
>
> What about http://commons.apache.org/sandbox/id/ ?

This is something different. That component provides a UUID implementation
(somewhat obsolete now since Java 5) and the concept of id generators.

> If IDs are important, this project should be in play on its own or folded
> into [lang].

That has been proposed before and is IMHO valid for the the generator stuff.

> Thoughts?

It's completely independent of the proposed functionality of UUIDUtils.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] UUIDUtils

Ralph Goers
Actually, UUID implementations aren't really obsolete. The Random UUID generated by Java can't be guaranteed to be unique, just that the probability that it is is very high.  In many circumstances it is desirable to have a UUID where the uniqueness properties are known - such as a type 1 UUID. For that reason I had to implement my own UUID class at https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/helpers/UUIDUtil.java.  I can think of other circumstances where a Type 1 UUID may not be quite sufficient and the algorithm will need to be modified somewhat.

FWIW, In my research on UUIDs I ran across http://johannburkard.de/software/uuid/ which would be a good implementation of a type 1 uuid - except it isn't thread safe. See my comments at http://wiki.apache.org/cassandra/TimeBaseUUIDNotes

Ralph

On Nov 22, 2011, at 6:24 AM, Jörg Schaible wrote:

> Hi Gary,
>
> Gary Gregory wrote:
>
>> Hi,
>>
>> What about http://commons.apache.org/sandbox/id/ ?
>
> This is something different. That component provides a UUID implementation
> (somewhat obsolete now since Java 5) and the concept of id generators.
>
>> If IDs are important, this project should be in play on its own or folded
>> into [lang].
>
> That has been proposed before and is IMHO valid for the the generator stuff.
>
>> Thoughts?
>
> It's completely independent of the proposed functionality of UUIDUtils.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

[id] UUID (was: [lang] UUIDUtils)

Jörg Schaible-3
Hi Ralph,

Ralph Goers wrote:

> Actually, UUID implementations aren't really obsolete. The Random UUID
> generated by Java can't be guaranteed to be unique, just that the
> probability that it is is very high.  In many circumstances it is
> desirable to have a UUID where the uniqueness properties are known - such
> as a type 1 UUID. For that reason I had to implement my own UUID class at
>
https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-
core/src/main/java/org/apache/logging/log4j/core/helpers/UUIDUtil.java.
>  I can think of other circumstances where a Type 1 UUID may not be quite
> sufficient and the algorithm will need to be modified somewhat.

The reason for id never see the light of a proper release was SANDBOX-53
i.e. the requirement of the component to be added to the jre/lib/ext library
(it does not *have* to be added there, but it shoudl be *possible*).
Therefore it was IMHO a mistake in this context to add more functionality to
the component than pure UUID generation without additional dependencies. If
we move the generic identifier generation into lang, strip off any
dependency, it would be a real improvement and it can be used in the
described context.

> FWIW, In my research on UUIDs I ran across
> http://johannburkard.de/software/uuid/ which would be a good
> implementation of a type 1 uuid - except it isn't thread safe. See my
> comments at http://wiki.apache.org/cassandra/TimeBaseUUIDNotes

AFAICS id delivers all this.

Cheers,
Jörg



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [id] UUID

Phil Steitz
On 11/22/11 8:38 AM, Jörg Schaible wrote:

> Hi Ralph,
>
> Ralph Goers wrote:
>
>> Actually, UUID implementations aren't really obsolete. The Random UUID
>> generated by Java can't be guaranteed to be unique, just that the
>> probability that it is is very high.  In many circumstances it is
>> desirable to have a UUID where the uniqueness properties are known - such
>> as a type 1 UUID. For that reason I had to implement my own UUID class at
>>
> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-
> core/src/main/java/org/apache/logging/log4j/core/helpers/UUIDUtil.java.
>>  I can think of other circumstances where a Type 1 UUID may not be quite
>> sufficient and the algorithm will need to be modified somewhat.
> The reason for id never see the light of a proper release was SANDBOX-53
> i.e. the requirement of the component to be added to the jre/lib/ext library
> (it does not *have* to be added there, but it shoudl be *possible*).
> Therefore it was IMHO a mistake in this context to add more functionality to
> the component than pure UUID generation without additional dependencies. If
> we move the generic identifier generation into lang, strip off any
> dependency, it would be a real improvement and it can be used in the
> described context.
>
>> FWIW, In my research on UUIDs I ran across
>> http://johannburkard.de/software/uuid/ which would be a good
>> implementation of a type 1 uuid - except it isn't thread safe. See my
>> comments at http://wiki.apache.org/cassandra/TimeBaseUUIDNotes
> AFAICS id delivers all this.

Right, the other reason that we could never get [id] out of the
sandbox was that the original developer of the UUID code went on to
other things and we did not have anyone ready and willing to verify
spec compliance, complete documenting and developing tests for the
code and stick around at least for a little while to support it.
The non-UUID generators and the API have some practical value, so it
would be great to get at least that stuff released somehow.  If you
and Ralf want to sign up to finish the UUID code, that would be
great as well.  I am +1 to promote if we have volunteers to work in
this thing.  I am -0 for pulling the non-UUID stuff back into
[lang], for pretty much the same reasons that this component was
created in the first place.

Phil


>
> Cheers,
> Jörg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [id] UUID

Adrian Cumiskey
I have a professional interest to get out a release of UUID as my current
project would like to adopt it.  I'd be more than happy to volunteer to
help out/finish off the project so we can get it released.

Cheers, Adrian.

On 22 November 2011 13:55, Phil Steitz <[hidden email]> wrote:

> On 11/22/11 8:38 AM, Jörg Schaible wrote:
> > Hi Ralph,
> >
> > Ralph Goers wrote:
> >
> >> Actually, UUID implementations aren't really obsolete. The Random UUID
> >> generated by Java can't be guaranteed to be unique, just that the
> >> probability that it is is very high.  In many circumstances it is
> >> desirable to have a UUID where the uniqueness properties are known -
> such
> >> as a type 1 UUID. For that reason I had to implement my own UUID class
> at
> >>
> >
> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-
> > core/src/main/java/org/apache/logging/log4j/core/helpers/UUIDUtil.java.
> >>  I can think of other circumstances where a Type 1 UUID may not be quite
> >> sufficient and the algorithm will need to be modified somewhat.
> > The reason for id never see the light of a proper release was SANDBOX-53
> > i.e. the requirement of the component to be added to the jre/lib/ext
> library
> > (it does not *have* to be added there, but it shoudl be *possible*).
> > Therefore it was IMHO a mistake in this context to add more
> functionality to
> > the component than pure UUID generation without additional dependencies.
> If
> > we move the generic identifier generation into lang, strip off any
> > dependency, it would be a real improvement and it can be used in the
> > described context.
> >
> >> FWIW, In my research on UUIDs I ran across
> >> http://johannburkard.de/software/uuid/ which would be a good
> >> implementation of a type 1 uuid - except it isn't thread safe. See my
> >> comments at http://wiki.apache.org/cassandra/TimeBaseUUIDNotes
> > AFAICS id delivers all this.
>
> Right, the other reason that we could never get [id] out of the
> sandbox was that the original developer of the UUID code went on to
> other things and we did not have anyone ready and willing to verify
> spec compliance, complete documenting and developing tests for the
> code and stick around at least for a little while to support it.
> The non-UUID generators and the API have some practical value, so it
> would be great to get at least that stuff released somehow.  If you
> and Ralf want to sign up to finish the UUID code, that would be
> great as well.  I am +1 to promote if we have volunteers to work in
> this thing.  I am -0 for pulling the non-UUID stuff back into
> [lang], for pretty much the same reasons that this component was
> created in the first place.
>
> Phil
>
>
> >
> > Cheers,
> > Jörg
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [id] UUID

Phil Steitz
On 11/22/11 1:21 PM, Adrian Cumiskey wrote:
> I have a professional interest to get out a release of UUID as my current
> project would like to adopt it.  I'd be more than happy to volunteer to
> help out/finish off the project so we can get it released.

Great!  I will kick off a promotion vote.

Phil

>
> Cheers, Adrian.
>
> On 22 November 2011 13:55, Phil Steitz <[hidden email]> wrote:
>
>> On 11/22/11 8:38 AM, Jörg Schaible wrote:
>>> Hi Ralph,
>>>
>>> Ralph Goers wrote:
>>>
>>>> Actually, UUID implementations aren't really obsolete. The Random UUID
>>>> generated by Java can't be guaranteed to be unique, just that the
>>>> probability that it is is very high.  In many circumstances it is
>>>> desirable to have a UUID where the uniqueness properties are known -
>> such
>>>> as a type 1 UUID. For that reason I had to implement my own UUID class
>> at
>> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-
>>> core/src/main/java/org/apache/logging/log4j/core/helpers/UUIDUtil.java.
>>>>  I can think of other circumstances where a Type 1 UUID may not be quite
>>>> sufficient and the algorithm will need to be modified somewhat.
>>> The reason for id never see the light of a proper release was SANDBOX-53
>>> i.e. the requirement of the component to be added to the jre/lib/ext
>> library
>>> (it does not *have* to be added there, but it shoudl be *possible*).
>>> Therefore it was IMHO a mistake in this context to add more
>> functionality to
>>> the component than pure UUID generation without additional dependencies.
>> If
>>> we move the generic identifier generation into lang, strip off any
>>> dependency, it would be a real improvement and it can be used in the
>>> described context.
>>>
>>>> FWIW, In my research on UUIDs I ran across
>>>> http://johannburkard.de/software/uuid/ which would be a good
>>>> implementation of a type 1 uuid - except it isn't thread safe. See my
>>>> comments at http://wiki.apache.org/cassandra/TimeBaseUUIDNotes
>>> AFAICS id delivers all this.
>> Right, the other reason that we could never get [id] out of the
>> sandbox was that the original developer of the UUID code went on to
>> other things and we did not have anyone ready and willing to verify
>> spec compliance, complete documenting and developing tests for the
>> code and stick around at least for a little while to support it.
>> The non-UUID generators and the API have some practical value, so it
>> would be great to get at least that stuff released somehow.  If you
>> and Ralf want to sign up to finish the UUID code, that would be
>> great as well.  I am +1 to promote if we have volunteers to work in
>> this thing.  I am -0 for pulling the non-UUID stuff back into
>> [lang], for pretty much the same reasons that this component was
>> created in the first place.
>>
>> Phil
>>
>>
>>> Cheers,
>>> Jörg
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [id] UUID (was: [lang] UUIDUtils)

Ralph Goers
In reply to this post by Jörg Schaible-3
I took a quick look at id.  I'm not a fan.  First, despite the javadoc for
VersionOneGenerator saying that a config file is not necessary my test
failed without one. Other issues include:

1. It should use java.util.UUID and not invent its own UUID class.
2. It seems extremely overly complicated. This impacts performance (see
below).
3. It is synchronized.
4. It doesn't use MAC addresses unless they are explicitly configured (as
far as I was able to tell).
5. I'm sure there is more - I only spent 10 minutes.

I ran a performance test and got

a) The UUIDUtil class I created for Log4j 2
Elapsed for 200 UUIDS = 165000 Average = 825 ns
b) Using VersionOneGenerator with the uuid1.state configuration in commons
id
Elapsed for 200 UUIDS = 58035000 Average = 290175 ns

In short, what I'd like added to commons lang is just a few UUID generators
for java.util.UUID that are fast, efficient, and have known
characteristics. I'd be OK with allowing a configuration to eliminate using
a random number to uniquely identify JVMs on a single server.

Ralph

On Tue, Nov 22, 2011 at 7:38 AM, Jörg Schaible
<[hidden email]>wrote:

> Hi Ralph,
>
> Ralph Goers wrote:
>
> > Actually, UUID implementations aren't really obsolete. The Random UUID
> > generated by Java can't be guaranteed to be unique, just that the
> > probability that it is is very high.  In many circumstances it is
> > desirable to have a UUID where the uniqueness properties are known - such
> > as a type 1 UUID. For that reason I had to implement my own UUID class at
> >
>
> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-
> core/src/main/java/org/apache/logging/log4j/core/helpers/UUIDUtil.java.
> >  I can think of other circumstances where a Type 1 UUID may not be quite
> > sufficient and the algorithm will need to be modified somewhat.
>
> The reason for id never see the light of a proper release was SANDBOX-53
> i.e. the requirement of the component to be added to the jre/lib/ext
> library
> (it does not *have* to be added there, but it shoudl be *possible*).
> Therefore it was IMHO a mistake in this context to add more functionality
> to
> the component than pure UUID generation without additional dependencies. If
> we move the generic identifier generation into lang, strip off any
> dependency, it would be a real improvement and it can be used in the
> described context.
>
> > FWIW, In my research on UUIDs I ran across
> > http://johannburkard.de/software/uuid/ which would be a good
> > implementation of a type 1 uuid - except it isn't thread safe. See my
> > comments at http://wiki.apache.org/cassandra/TimeBaseUUIDNotes
>
> AFAICS id delivers all this.
>
> Cheers,
> Jörg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>