Community
Participate
Working Groups
Build: I-20040226 I have org.eclipse.pde.ui checked out from cvs into my workspace. This plug-in references external JAR antui.jar. With the open type dialog, I opened AntModel (coming from antui.jar), and I got the compiler abort error pasted below. The class file did open nevertheless. However, if I tried to do anything in it, e.g. select something and try to find references, etc, I get the same compiler abort error. Shutting down my workbench and restarting did not help. Error Feb 29, 2004 02:15:25.297 An internal error occurred during: "Java AST creation". org.eclipse.jdt.internal.compiler.problem.AbortCompilation at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle (ProblemHandler.java:94) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle (ProblemReporter.java:1034) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect (ProblemReporter.java:2110) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve (UnresolvedReferenceBinding.java:37) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage (PackageBinding.java:163) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (Scope.java:1467) at org.eclipse.jdt.core.dom.DefaultBindingResolver.resolveName (DefaultBindingResolver.java:228) at org.eclipse.jdt.core.dom.Name.resolveBinding(Name.java:89) at org.eclipse.jdt.internal.ui.search.OccurrencesFinder.visit (OccurrencesFinder.java:147) at org.eclipse.jdt.core.dom.QualifiedName.accept0 (QualifiedName.java:88) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:1663) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:1710) at org.eclipse.jdt.core.dom.ImportDeclaration.accept0 (ImportDeclaration.java:106) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:1663) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:1733) at org.eclipse.jdt.core.dom.CompilationUnit.accept0 (CompilationUnit.java:173) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:1663) at org.eclipse.jdt.internal.ui.search.OccurrencesFinder.perform (OccurrencesFinder.java:73) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.updateOccurrenceAnnotations (JavaEditor.java:2835) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$5.selectionChanged (JavaEditor.java:2859) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartLis tenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:149) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$1.run (SelectionListenerWithASTManager.java:99) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:62)
Rebuilding all the projects did not work either. Every time I did anything, I would get an instance of this error in my log and as a pop up window. I then imported org.eclipse.ant.ui as a binary project into my workspace. This resulted in removal of the reference to the external antui.jar from pde.ui (due to classpath containers), as expected. When I opened the AntModel class now, everything became normal. So this seems to be related to opening a class file from external JARs.
Need to investigate.
Raising severity... It happened again today. Trying to open type JavaUI, which is coming from an external JAR. What makes it critical is the fact that the "Error running jobs" pop up dialog, could not be dismissed. Every time I press OK or escape, it comes right back up with a new entry in it "Java AST creation error". I had to kill my workbench.
Could you please tell me what projects are in your workspace? How did you create your workspace? I cannot reproduce.
0226. pde.ui, pde.core, pde.runtime, ui.forms checked out from CVS. I try to open JavaUI, referenced by jdt.jar in my pde.ui project and bang. I'm dead. I have kill my workspace. Otherwise, the dialog keeps popping up and fills up my log.
same thing happens on I-20040302
We have a big problem. When you try to open the JavaUI type, an AST is created with bindings. The problem is this case is that it is not possible to resolve the bindings, because the Java project for the class file JavaUI.class is org.eclipse.ant.ui instead of org.eclipse.jdt.ui. Then all references to types in org.eclipse.jdt.core cannot be resolved. The error occurs in the OccurrenceFinder, because the binding resolution of qualified name is lazy and in this case it fails during the resolution of one of the import declarations. If jdt.ui is required by ant.ui, then jdt.core should be visible. But jdt.ui doesn't reexport jdt.core. This might be the problem. Or the PDE container should retrieve jdt.core....
PDE puts on a plug-in A's classpath: 0. the plug-in's own libraries. 1. all the JARs coming from dependencies it explicitly lists. 2. JARs from plug-ins reexported by A's direct dependencies. This is also exactly what goes on the runtime classpath of plug-in A. If we put anything more, then we would be giving false compilation positives, which would result in build failures and runtime classloading errors. The option that jdt.ui reexport jdt.core will artificially solve this particular problem, but is not a general or a favorable solution. The same situation could happen with arbitrary plug-ins X and Y. We can't start forcing people to reexport all their dependencies all the time.
No AbortCompilation should ever escape from JDT Core land. From our end the classpath is inconsistent, so this is expected behavior, but no binding should be provided. I haven't checked, but: org.eclipse.jdt.core.dom.Name.resolveBinding(Name.java:89) looks like it is lazily resolving more bindings. I thought this was forbidden. Just to be more explicit for the classpath inconsistency. The way PDE sets up the classpath makes it ok to resolve sources in the project, but does not ensure that required libraries have enough around to be able to resolve further. So when trying to build a DOM AST on one of their attached sources, this is likely behavior. The only solution would be to include more prerequisites in the classpath, but as you observed it would change the compilation context at the same time, which is forbidden. This is why using projects is a better way to develop, as you would get prereq libraries in their proper context. There is nothing we can do, but handle this exception in a better way (Olivier, you should look at how we trap it into the compiler).
The only lazy binding resolution is for qualified name and the subpart of a qualified name. We agreed a while ago that this is too time consuming to resolve all bindings immediately. So we have two solutions: 1) I can handle the abort compilation during the lazy binding resolution 2) I can resolve all bindings during the conversion process. What solution do you prefer?
I am catching potential AbortCompilation exceptions inside the DefaultBindingResolver. Fixed and released in HEAD.
*** Bug 54107 has been marked as a duplicate of this bug. ***
*** Bug 54290 has been marked as a duplicate of this bug. ***
Verified for 3.0 using build I200403250010.
