juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt T Stam (JIRA)" <juddi-...@ws.apache.org>
Subject [jira] Closed: (JUDDI-168) Clean up UUID code
Date Fri, 02 Jan 2009 16:41:44 GMT

     [ https://issues.apache.org/jira/browse/JUDDI-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kurt T Stam closed JUDDI-168.
-----------------------------

    Resolution: Fixed

I created a unittest for the various UUID generators and found:

1. DefaultUUIDGen: Generation of 100 UUID's took 817 milliseconds.
354A0C80-D8D2-11DD-8C80-A1CCD6EA2465

2. NativeUUIDGen: Generation of 100 UUID's took 2273 milliseconds.
F24B5CBE-ACE1-47B1-A0D2-57C4DB75E531

3. JavaUUIDGen: Generation of 100 UUID's took 13 milliseconds.
8ada24b2-a19f-47d4-b5c2-96b0c71ad8f3

Number 3 uses UUID in java (1.5+ feature)

according to the javadoc of 'DefaultUUIDGen' this one was created to increase the speed of
UUID generation, which indeed is much faster then using native (none java) solutions.

I see no reason to keep the org.apache.juddi.uuidgen package. We can always pull it back out
of source control if we really need it, but I doubt we will ever look back. 

> Clean up UUID code
> ------------------
>
>                 Key: JUDDI-168
>                 URL: https://issues.apache.org/jira/browse/JUDDI-168
>             Project: jUDDI
>          Issue Type: Task
>    Affects Versions: 3.0alpha
>            Reporter: Kurt T Stam
>            Assignee: Kurt T Stam
>             Fix For: 3.0alpha
>
>
> Now that java has a UUID generator (Java 1.5+) we can simply use that and get rid of
the home grown code.
> We can pretty much get rid of the org.apache.juddi.uuidgen package, as well as the configuration
properties.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message