Bug 272587

Description Jason Sholl 2009-04-16 17:55:17 EDT

Is there any mechanism in JDT to parse a project's .classpath file in a light weight manner that does not load an JDT resources or compute the classpath?  

In WTP there are a few rather complex code paths which occasionally result in deadlocks and/or corrupted JDT classpaths, and they all see to be caused by JDT classpath code calling back into itself while it is computing.  This is because we have mechanisms for computing complex project dependencies based on .classpath information, and our classpath containers rely on these dependencies, so what could happen is while our classpath container is being loaded for a project, it needs to figure out these dependencies which in turn forces JDT to load classpath information of other projects, which in turn loads their classpath containers, which in turn goes back into the first projects classpath.  Throw in multiple threads (some loading JDT, and others parsing dependencies) and you've got a nice mess.  :)

While the above scenario may seem a bit odd, the key part is that the dependencies do not actually depend on JDT's computed classpath, but rather all we really need to get at is the contents of the .classpath file.  If we could process the raw .classpath file information (not the resolved classpath), then we could find everything we need and break the above described cycle.