Bugzilla – Full Text Bug Listing
| Summary: | Add encodeUUID() and decodeUUID() to EcoreUtil | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Eike Stepper <stepper> | ||||||
| Component: | Core | Assignee: | Ed Merks <Ed.Merks> | ||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | ||||||||
| Version: | 2.8.0 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
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. |
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[]).