I didn't mean use the UUID class as the id. I meant wrap the creation. So instead of:
new User(java.util.UUID.randomUUID().toString());
we do:
new User(org.keycloak.UUID.createUUID());
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, 7 February, 2014 3:33:49 PM
Subject: Re: [keycloak-dev] Use UUID for IDs
On 2/7/2014 10:17 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Friday, 7 February, 2014 2:53:43 PM
>> Subject: Re: [keycloak-dev] Use UUID for IDs
>>
>>
>>
>> On 2/7/2014 9:33 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke(a)redhat.com>
>>>> To: keycloak-dev(a)lists.jboss.org
>>>> Sent: Friday, 7 February, 2014 2:04:24 PM
>>>> Subject: Re: [keycloak-dev] Use UUID for IDs
>>>>
>>>> Not sure why I didn't use UUID in the first place. I've used it
in
>>>> other code bases. I guess maybe I wasn't sure if UUID.randomUUID()
>>>> guaranteed that the UUID was always unique. Wasn't clear if a time
>>>> component is added to the UUID.
>>>
>>> AFAIK there's no time component, but the risk of collision is extremely
>>> small
>>>
>>
>> Hopefully no security weeny identifies that as a security risk.
>
> We can wrap it in our own UUID class, that way we'll be able to quickly
> change the underlying algorithm if some weenies complain
Why use the UUID class directly? Just use a string.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com