Name | Value | Size |
---|---|---|
Base UUID Value (Used in promoting 16-bit and 32-bit UUIDs to 128-bit UUIDs) | 0x0000000000001000800000805F9B34FB | 128-bit |
SDP | 0x0001 | 16-bit |
RFCOMM | 0x0003 | 16-bit |
OBEX | 0x0008 | 16-bit |
HTTP | 0x000C | 16-bit |
L2CAP | 0x0100 | 16-bit |
BNEP | 0x000F | 16-bit |
Serial Port | 0x1101 | 16-bit |
ServiceDiscoveryServerServiceClassID | 0x1000 | 16-bit |
BrowseGroupDescriptorServiceClassID | 0x1001 | 16-bit |
PublicBrowseGroup | 0x1002 | 16-bit |
OBEX Object Push Profile | 0x1105 | 16-bit |
OBEX File Transfer Profile | 0x1106 | 16-bit |
Personal Area Networking User | 0x1115 | 16-bit |
Network Access Point | 0x1116 | 16-bit |
Group Network | 0x1117 | 16-bit |
Uuid
s are equal if they have the same 128-bit value. Uuid
instances can be created using the static methods of the {@link UuidFactory} class.The design of this class is intended to support the use of universally unique identifiers that
Uuid
as a capability. Note that not all defined Uuid
values imply a generation algorithm that supports this goal. The most significant 64 bits of the value can be decomposed into unsigned integer fields according to the following bit masks:
0xFFFFFFFF00000000 time_low 0x00000000FFFF0000 time_mid 0x000000000000F000 version 0x0000000000000FFF time_hi
The least significant 64 bits of the value can be decomposed into unsigned integer fields according to the following bit masks:
0xC000000000000000 variant 0x3FFF000000000000 clock_seq 0x0000FFFFFFFFFFFF node
This specification defines the meaning (and implies aspects of the generation algorithm) of Uuid
values if the variant field is 0x2
and the version
field is either 0x1
or 0x4
.
If the version
field is 0x1
, then
time_low
, time_mid
, and time_hi
fields are the least, middle, and most significant bits (respectively) of a 60-bit timestamp of 100-nanosecond intervals since midnight, October 15, 1582 UTC, clock_seq
field is a 14-bit number chosen to help avoid duplicate Uuid
values in the event of a changed node address or a backward system clock adjustment (such as a random number when in doubt, or the previously used number incremented by one if just a backward clock adjustment is detected), and node
field is an IEEE 802 address (a 48-bit value). As an alternative to an IEEE 802 address (such as if one is not available to the generation algorithm), the node
field may also be a 48-bit number for which the most significant bit is set to 1
and the remaining bits were produced from a cryptographically strong random sequence.
If the version
field is 0x4
, then the time_low
, time_mid
, time_hi
, clock_seq
, and node
fields are values that were produced from a cryptographically strong random sequence.
Only Uuid
values with a version
field of 0x4
are considered computationally difficult to guess. A Uuid
value with a version
field of 0x1
should not be treated as a capability.
A subclass of Uuid
must not implement {@link Externalizable}; this restriction is enforced by this class's constructor and readObject
methods.
@author Sun Microsystems, Inc.
@since 2.0
The values in the system catalog held in ID columns with a type of CHAR(36) are the string representations of these UUIDs.
A UUID implements equals() and hashCode based on value equality.
By default class caches the string presentations of UUIDs so that description is only created the first time it's needed. For memory stingy applications this caching can be turned off (note though that if uuid.toString() is never called, desc is never calculated so only loss is the space allocated for the desc pointer... which can of course be commented out to save memory).
Similarly, hash code is calculated when it's needed for the first time, and from thereon that value is just returned. This means that using UUIDs as keys should be reasonably efficient.
UUIDs can be compared for equality, serialized, cloned and even sorted. Equality is a simple bit-wise comparison. Ordering (for sorting) is done by first ordering based on type (in the order of numeric values of types), secondarily by time stamp (only for time-based time stamps), and finally by straight numeric byte-by-byte comparison (from most to least significant bytes).
This class represents a universally unique identifier, consisting of two long integral values.
This identifier is supposed to be unique both spatially and temporally. It is based on version 4 IETF variant random UUIDs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|