Community
Participate
Working Groups
Created attachment 199836 [details] Patch v1 I need the ability to base64 encode and decode the byte arrays that are populated by EcoreUtil.generateUUID(byte[]).
If you generally agree with this patch we could optimize the static footprint a little by stripping off some leading and trailing zero elements from the BASE64_INDEX array.
XMLTypeFactory already has support for base64 encoding and decoding (because there's a data type for that in XML Schema. I'm just curious why you'd need something specific to EMF's UUID class; you could use the above utilities stripping/adding the leading _. In particular, in what situations can you ever really assume you're dealing with a UUID as opposed to some arbitrary String representing any old ID?
(In reply to comment #2) > XMLTypeFactory already has support for base64 encoding and decoding (because > there's a data type for that in XML Schema. Oh, I didn't know that one. Since there's this generateUUID() method on EcoreUtil with the String return value I thought it would be good to use the reverse of that particular encoding in my own I/O. > I'm just curious why you'd need something specific to EMF's UUID class; you > could use the above utilities stripping/adding the leading _. In particular, > in what situations can you ever really assume you're dealing with a UUID as > opposed to some arbitrary String representing any old ID? In CDO I'm currently adding support for client-side assigned object IDs. They must be "system wide" unique without contacting any master authority. The actual ID value generation is pluggable and the values are stored in a CDOID subclass with a byte[] field (side note: because in a CDO system there's a considerable number of CDOID values I'm even considering to use 16 single byte primitive fields or 2 long fields instead to spare a pointer and some heap fragmentation). At some places in the CDO framework, for example, the database mappings, I need String de/encoding of the bytes. So I thought it may have some value to use the same en/decoding that users wold see in their XML or other resources.
Created attachment 199871 [details] Patch v2 This version makes the nested UUID class public and adds the ability to pass a node address. If no node address is passed then the class tries to determine the hardware address (jre6 needed) or, if that fails, a random 6 bytes sequence. The decoder's static footprint contribution has been reduced from 1024 to 78 bytes.
v2 assumes that a jdk6+ is used to compile EMF. If that's not true then reflection must be used to invoke the NetworkInterface.getHardwareAddress() method.
Not really needed.
