This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Improve uniqueness of unique ID | ||
---|---|---|---|
Product: | platform | Reporter: | Antonin Nebuzelsky <anebuzelsky> |
Component: | -- Other -- | Assignee: | Jiri Rechtacek <jrechtacek> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jcatchpoole, jchalupa, krajeswaran, mslama, pnejedly, rkubacki |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
Antonin Nebuzelsky
2007-01-23 14:14:05 UTC
Are there any data suggesting we have significant number of collisions? Statistics would say that not many people really start their IDE instance in the same millisecond (so even the millisecond may alone be good ID and in fact, it is). Look, there are 86 millions milliseconds a day, so unless we have comparable count of users, all installing their IDE just within a day after the release, the ID is unique enough. Note: simulation proved that there are no ID collisions caused by usage of Random(System.currentTimeMillis()) for a day worth of millis (Random is explicitely engineered this way), moreover JDK6 uses nanoTime(), not millis, so I'd bet there are more collisions caused by the withd of the ID (31 bits), not by the way it is generated. Moreover, I'd expect that any way of mixing IP address into the ID would stir up privacy concerns (though the connecting IP address is available to the UC anyway, but that might be a proxy) > Look, there are 86 millions milliseconds a day I see your point... > Are there any data suggesting we have significant number of collisions? There are indications that the collisions really exist. Jack could do some more research to verify how much there really are. But, given the fact that collisions are possible with the current mechanism, why not improving it??? I believe we can create a mechanism where a collision is veeeeeery improbable. As opposed to the current mechanism where the generated number is dependent only on the current time and therefore there is a certain possibility that *any two* userdirs can have the same ID. The improvement would of course include making the ID longer. A question is if this would be *two* concatenated random numbers, or a random number plus something else. I think the latter would be better. Collisions are possible but already quite unlikely. I'd much rather believe any other explanation of collision-like behaviour than the real collisions, but let's Jack tell us. Anyway, I agree that the only way how to really reduce the collision rate is to extend the ID width. But it we're about to replace the current mechanism, I'd rather go with something standard and tested, like UUID. Nothing compares to java.util.UUID.randomUUID().toString() when it comes to simplicity and safety. UUID looks interesting. Jirko, have a look at that. New code of Autoupdate module contains generating of unique ID based of proposed java.util.UUID.randomUUID().toString(). This means that ID now has the format: {pack-prefix}0{uuid} where - pack-prefix is set by installer and contains list of installed packs, i.e. NB_ENT - 0 is the delimiter for easy parsing - uuid is result of UUID.randomUUID().toString(), i.e. c7150300-ee4e-40b3-bcbf-71973cc60671 Integrated into NetBeans code line since 07/04/12. |