Page History

...

A Universally Unique Identifier (UUID) UUIDURN is a 16-octet (128-bit) value which identifies an object. It usually uses the mac address and time for entropy in generating this 16 byte value. We need it for several things however replication is the biggest driver.

...

http://java.sun.com/j2se/1.5.0/docs/api/java/util/UUID.html

Some libs exist for 1.4 here but they are LGPL'd and require native libraries when anything less than jdk 1.5 are used:

http://www.doomdark.org/doomdark/proj/jug/

Also note that the APR has a routine for generating a UUID. Here's the documentation for it:

http://apr.apache.org/docs/apr-util/apr__uuid_8h.html#_details

Need to make some decisions

Problem Statement

My natural instinct was to just move to 1.5. Others will follow was my thought. However this will create problems for adoption as others have told me after asking around. We need to be backwards compatible with 1.4.2 for at least another year.

Furthermore there is no simple solution for generating a UUID on 1.4 which sounds really trivial to do. The issue is in getting the MAC address. Perhaps other algorithms can be used to generate a UUID which do not require access to the mac address of the server. Here are a few algorithms but I have not looked into what they need. From what I can see there are 4 types of UUIDs that can be generated and we may only need one which is not dependent on time. Some of this is just useful links of info:

http://www.infonuovo.com/dma/csdocs/sketch/instidid.htm
http://www.limewire.org/pipermail/codepatch/2004-May/000432.html

For backwards compat with JDK 1.4 we are going to need to make UUID generation pluggable and tap into an OS specific mechanism to generate the UUID or read mac addresses.

Existing libraries Java and other for use in JDK 1.4

There are a few ways we can approach this using a pluggable UUID generation mechanism to swap in and out different implementations. The pluggable thing definately needs to happen though. Now there are multiple choices for implementations.

1. Use JUG which has native libs and is LGPL (see if we can approach them to go ASL)
2. Use OS specific operations forking a process to get the mac address or forking a process to generate the UUID itself: a native program. Might be best to just look up the mac address using a native mechanism. We only need it once on startup so its not that wasteful.
3. Write a helper daemon to generate the UUID for us and expose it as a service - so we would need to write a UUID generator that spoke to the UUID daemon. This means more moving parts in the system.
4. The APR has a UUID generation function. We could write our own daemon or JNI based API to use this code. The APR is portable across platforms so it will work on most things. This would be a much better option than using JUG perhaps.

NOTE: I just wrote the JUG guy and email about switching the License. Let's see what he says. If he's cool with that then we just use JUG and deal with the native lib issues. Might be best to have a UUID daemon which can also act as an SSL proxy for us for JDK1.4? We can buid it in C and use the APR?