Since the no-args constructor version includes a timestamp it can make unique ids until the end of time. Two machines could produce the same id, though, so they recommend adding the IP address to the UID to make them globally unique.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
"Can that (duplicate IP) cause problems?" Well.. maybe. Since the UID uses a timestamp the addition of the IP would make the UIDs unique on that network, unless there was a duplicate IP in which case you have bigger problems. If, for instance, the IP was in a private network using NAT and therefore almost certainly not unique across the Internet, but you needed to generate unique UIDs across the Internet then you would need to find some unique ID for the machine. MAC address is a possibility but it is not accessible without writing JNI or some other kind of native code. Also, the MAC address can be spoofed. Still it is almost certainly sufficient and if rules about MAC cloning can be enforced it is definately sufficient. If the domain of uniqueness can be restricted to a single application then another possibility is adding a hash of the user ID to the UID. FWIW, I've used a combination of MAC address, Object.hashCode(), timestamp, and a serial number. The MAC address for machine uniqueness, the hashCode for process uniqueness, the timestamp for time uniqueness, and the serial number for multiple UIDs within the time granularity. With the addition of the MAC address this is close to the UID generation algorithm. Our unittesting would generate 1,000,000 UIDs on 10 threads and then check them for duplicates and it never failed.