Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 544081

Summary: ImportRemover.PROPERTY_KEY should be guaranteed to be unique
Product: [Eclipse Project] JDT Reporter: Fabian Pfaff <fabian.pfaff>
Component: UIAssignee: Fabian Pfaff <fabian.pfaff>
Status: VERIFIED FIXED QA Contact: Jeff Johnston <jjohnstn>
Severity: normal    
Priority: P3 CC: jarthana, jjohnstn, kalyan_prasad, Lars.Vogel, loskutov
Version: 4.11   
Target Milestone: 4.23 M1   
Hardware: PC   
OS: Linux   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=542653
https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/183145
https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=e56e75c944f48b7ec8f283c0b6b31c611df16692
Whiteboard:

Description Fabian Pfaff CLA 2019-02-03 21:57:53 EST 
Currently the PROPERTY_KEY is generated by calling System.currentTimeMillis().
This doesn't have enough precision on a fast machine to avoid collisions.

Code that produces the problem:

	ImportRemover remover= new ImportRemover(context.getCompilationUnit().getJavaProject(), context.getASTRoot());
	ImportRemover remover2= new ImportRemover(context.getCompilationUnit().getJavaProject(), context.getASTRoot());
Comment 1 Lars Vogel CLA 2019-02-26 04:14:26 EST 
@Fabian, can you provide a Gerrit fix?
Comment 2 Eclipse Genie CLA 2021-02-16 13:47:29 EST 
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 3 Eclipse Genie CLA 2021-07-18 09:47:26 EDT 
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/183145
Comment 4 Jay Arthanareeswaran CLA 2021-07-20 00:18:28 EDT 
This might be a naive question - do you think System.nanoTime() would address this issue?

And moving to jdt.ui as the code in question belongs there.
Comment 5 Andrey Loskutov CLA 2021-07-20 00:26:56 EDT 
(In reply to Jay Arthanareeswaran from comment #4)
> This might be a naive question - do you think System.nanoTime() would
> address this issue?

Nanotime doesn't guarantee it grows, although theoretically it is less probably to get collisions. If you need unique numbers, counter could be an option?
Comment 6 Jay Arthanareeswaran CLA 2021-07-20 00:30:07 EDT 
(In reply to Andrey Loskutov from comment #5)
> Nanotime doesn't guarantee it grows, although theoretically it is less
> probably to get collisions. If you need unique numbers, counter could be an
> option?

Good idea! +1 for a counter
Comment 7 Fabian Pfaff CLA 2021-07-20 11:55:47 EDT 
(In reply to Jay Arthanareeswaran from comment #6)
> (In reply to Andrey Loskutov from comment #5)
> > Nanotime doesn't guarantee it grows, although theoretically it is less
> > probably to get collisions. If you need unique numbers, counter could be an
> > option?
> 
> Good idea! +1 for a counter

Thank you for your input! I thought along the same lines as well.
Please check out https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/183145 where I proposed a solution using a counter, although we're currently not sure if it meets all the requirements. (Does it need to be thread-safe? Is the property key ever written to storage?)
Comment 9 Jeff Johnston CLA 2021-12-03 13:43:59 EST 
Released for 4.23 M1
Comment 10 Jeff Johnston CLA 2022-02-17 12:40:48 EST 
Verified for 4.23 M3 using I20220216 build