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.
Unique ID of the userdir is currently generated as an integer in a very simple way: Random RANDOM = new Random (); int id = RANDOM.nextInt (); if (id < 0) { id = - (id + 1); } return id; The default constructor of Random takes System.currentTimeMillis() as the seed for the random generator. It means there is a real danger of repeated unique IDs for different users. I suggest that we improve the algorithm by combining this number with something completely unrelated to the current time, like the machine's IP network address.
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.