Community
Participate
Working Groups
We have a job that looks through a project to find all types inheriting from a specific class to build a model. For this purpose it uses IJavaProject#isOnClasspath. This job is executed with our own rule to prevent concurrency issues. Sometimes we get an IllegalArgumentException "Attempted to beginRule: R/, does not match outer scope rule: My Loading Model Rule" while calling IJavaProject#isOnClasspath. The problem turns out to be a container initialization. JavaCore#setClasspathContainer wants to lock the complete workspace. The problem we have now is what to do? We can't include the COMPLETE workspace rule into our own rule. Furthermore are API clients of IJavaProject#isOnClasspath expected to lock the whole workspace? This is the detailed stack trace: java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match outer scope rule: My Loading Model Rule at org.eclipse.core.internal.runtime.Assert.isLegal(Assert.java:58) at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:106) at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:200) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:80) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:170) at org.eclipse.core.internal.resources.WorkManager.checkIn (WorkManager.java:95) at org.eclipse.core.internal.resources.Workspace.prepareOperation (Workspace.java:1628) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1668) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation (JavaModelOperation.java:744) at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath (JavaProject.java:2650) at org.eclipse.jdt.core.JavaCore$3.run(JavaCore.java:3433) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation (BatchOperation.java:34) at org.eclipse.jdt.internal.core.JavaModelOperation.run (JavaModelOperation.java:700) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1673) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:3246) at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:3416) at org.eclipse.jdt.internal.launching.JREContainerInitializer.initialize (JREContainerInitializer.java:51) at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer (JavaModelManager.java:1261) at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers (JavaModelManager.java:1226) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer (JavaModelManager.java:833) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1184) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath (JavaProject.java:1888) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath (JavaProject.java:1798) at org.eclipse.jdt.internal.core.JavaProject.isOnClasspath (JavaProject.java:2130) at my.custom.code.MyRegistry.findMySpecialClassesInFolder()
Classpath related operations now don't take any lock (see ChangeClasspathOperation#getSchedulingRule()). Released for 3.3M1 in HEAD.
Verified for 3.3 M1 using build I20060807-0010