Community
Participate
Working Groups
Build 20020619 Eclipse will consistently report a VM error after the following steps: 1) Start with 2 versions of the same jar file. (I used old and new versions of xalan.jar) 2) Create a project with the old version of the jar. Check it into CVS and version it (v1). 3) Replace the jar file with the new version and version it again (v2). 4) Add the new jar to Ant's classpath on the Ant preference page. 5) Run any Ant script. 6) Remove the jar from Ant's classpath. 7) On the project containing the jar, select Replace With->Version, and pick v1 from the list of possibilities. This will load the old jar into the workspace. 8) Try to browse the jar in the packages view. This will cause the VM error. The error does not occur unless an Ant script is run with the updated classpath.
Created attachment 1510 [details] Error dialog generated
Created attachment 1511 [details] Log file
I can't reproduce the problem but this looks like a corrupt jar file problem (see bug 19537). Moving to jdt core to see if they can / want / need to protect against this problem.
Catching Errors is usually not a good idea... Jerome - can you reproduce it and see if we can do anything reasonable?
I cannot reproduce either. However java.lang.InternalError is the symptom of a bug in the class library you're using. Even if the .jar file was corrupt, a ZipException should be thrown. You should report this error to your VM vendor. Closing.
Reopening as a file descriptor on the internal jar is left open.
In the process of searching for classes to load, AntClassLoader opens the internal jar and leaves it open (until finalize is called). This prevents the jar to be replaced or to be deleted. Moving back to Ant
moving to M4
We are no better or worse than any other plugin classloader (in fact we are just inheriting this behavior). We are planning to add an option on the Ant launch configurations to discard / re-init the classloader on each launch (see bug 27440). Currently the classloader is cached unless the classpath changes. It is unlikely we will do any more on this issue. Comments?
Darin, isn't the problem that Ant runs in-process (as other plugins) but it has jars which are in the workspace on its classloader's classpath (and other plugins don't)?
Yes this is what more readily exposes the problem to the user. If you want to replace/delete the jar you will have to set to discard the ant classloader. If you remove the jar from the ant classpath, the classloader will be discarded as well and then you can delete.
Marking as a possible later.
Since builds occur by default in a separate VM, nothing more planned.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
