Community
Participate
Working Groups
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.
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.
A thread-safe add and remove would work. More importantly, everyone has to use it for it to function properly.
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.
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.
