Bug 119152

Summary: IJavaProject get and set classpath API not thread-safe
Product: [Eclipse Project] JDT Reporter: Theodora Yeung <tyeung>
Component: CoreAssignee: Jerome Lanneluc <jerome_lanneluc>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: frederic_fusier, jgarms
Version: 3.1.1   
Target Milestone: 3.3 RC4   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Theodora Yeung CLA 2005-12-02 20:46:03 EST 
IJavaProject.getClasspath() and IJavaProject.setClasspath() APIs not thread-safe.

Order of events in a multi-threaded environment:
Thread0 getClasspath()
Thread1 getClasspath()
Thread0 setClasspath() // add folder x to classpath
Thread1 setClasspath() // add folder y to classpath

Result: classpath entry from thread0 gets over-written by thread1.
Comment 1 Jerome Lanneluc CLA 2005-12-06 10:30:27 EST 
The contract of setRawClasspath(...) is to simply set an array of classpath entries, without preserving the existing ones.
It sounds like you want to add/remove classpath entries in a thread-safe way.
Comment 2 Theodora Yeung CLA 2005-12-12 18:56:54 EST 
A thread-safe add and remove would work. More importantly, everyone has to use it for it to function properly.
Comment 3 Philipe Mulet CLA 2005-12-13 05:24:28 EST 
That wouldn't be practical. Not every client wants to perform incremental add/remove to classpath.

I hate considering adding a lock to (get/set)RawClasspath given possible consequences.
Comment 4 Jerome Lanneluc CLA 2007-06-20 04:52:34 EDT 
Considering that we cannot prevent client to use the existing API setRawClasspath(...) even if we deprecated it, adding a new API would not solve the issue.
No action planned.