Community
Participate
Working Groups
Eclipse 4.5 M7 - I20150430-1445 - Create two Java projects P1 and P2. - Enable annotation-based null analysis for P1. - Set the location for external annotation attachment in P1 as the workspace location for P2. - Now, create a class in P1. We get the following error in Error log view. Any operation like content assist in class C gives the same error after that and does not complete. Could not retrieve declared methods java.lang.IllegalArgumentException: Path must include project and resource name: /P2 at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:2075) at org.eclipse.core.internal.resources.Container.getFile(Container.java:192) at org.eclipse.jdt.internal.core.ClassFile.setupExternalAnnotationProvider(ClassFile.java:391) at org.eclipse.jdt.internal.core.ClassFile.getJarBinaryTypeInfo(ClassFile.java:369) at org.eclipse.jdt.internal.core.ClassFile.existsUsingJarTypeCache(ClassFile.java:218) at org.eclipse.jdt.internal.core.NameLookup.seekTypesInBinaryPackage(NameLookup.java:1051) at org.eclipse.jdt.internal.core.NameLookup.seekTypes(NameLookup.java:1019) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:769) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:663) at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:622) at org.eclipse.jdt.internal.core.SearchableEnvironment.find(SearchableEnvironment.java:103) at org.eclipse.jdt.internal.core.SearchableEnvironment.findType(SearchableEnvironment.java:283) at org.eclipse.jdt.internal.core.CancelableNameEnvironment.findType(CancelableNameEnvironment.java:50) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:144) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:99) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:187) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypesFor(BinaryTypeBinding.java:1453) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.availableMethods(BinaryTypeBinding.java:366) at org.eclipse.jdt.core.dom.TypeBinding.getDeclaredMethods(TypeBinding.java:302) at org.eclipse.jdt.internal.corext.codemanipulation.StubUtility2.getUnimplementedMethods(StubUtility2.java:825) at org.eclipse.jdt.internal.corext.codemanipulation.StubUtility2.getUnimplementedMethods(StubUtility2.java:807) at org.eclipse.jdt.internal.corext.codemanipulation.AddUnimplementedMethodsOperation.run(AddUnimplementedMethodsOperation.java:197) at org.eclipse.jdt.ui.wizards.NewTypeWizardPage.createInheritedMethods(NewTypeWizardPage.java:2657) at org.eclipse.jdt.ui.wizards.NewClassWizardPage.createTypeMembers(NewClassWizardPage.java:255) at org.eclipse.jdt.ui.wizards.NewTypeWizardPage.createType(NewTypeWizardPage.java:2207) at org.eclipse.jdt.internal.ui.wizards.NewClassCreationWizard.finishPage(NewClassCreationWizard.java:71) at org.eclipse.jdt.internal.ui.wizards.NewElementWizard$2.run(NewElementWizard.java:118) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:729) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2241) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:5409) at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:106) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
Just to clarify: the bug title speaks of renaming, how does this relate to the steps in comment 0?
(In reply to Stephan Herrmann from comment #1) > Just to clarify: the bug title speaks of renaming, how does this relate to > the steps in comment 0? Sorry, missed the step. After step 3 in comment #0, rename P2. Then, create a class in P1 as mentioned in step 4.
After bug 466879 has been filed, this bug will only cover the immediate issue: not to break content assist etc. after the broken configuration has been detected. I'll have to see if we can restrict the logging to once per broken external annotation location - not sure if that is possible.
outch, by accidentally setting target to 4.4RC2 this bug escaped my attention. Thanks for putting it back on track. Might be a candidate for 4.5.1, let's see.
Tentatively pulling into 4.6 M1
The immediate problem doesn't even relate to the renaming: the call root.getFile(externalAnnotationPath) doesn't admit a project path (absolute, one-segment). TODO: (1) decide whether project root is a valid external annotation path - adjust UI, to add corresponding validation, if necessary (2) protect against immediate IAE (3) consider caching bogus annotation paths in ClasspathEntry to avoid floods of identical log messages. (4) decide if more validation is needed in some central location. I have WIP re (2) and (3) in my workspace
New Gerrit change created: https://git.eclipse.org/r/61928
(In reply to Stephan Herrmann from comment #6) > (1) decide whether project root is a valid external annotation path > - adjust UI, to add corresponding validation, if necessary UI admits project root & there's no fundamental problem with this (it just looks a bit weird to configure it that way) - so lets not change this. > (2) protect against immediate IAE Done via https://git.eclipse.org/r/61928 > (4) decide if more validation is needed in some central location. I believe for validation we can simply extend ClasspathEntry.validateClasspathEntry(). This should then obsolete item (3) above.
New Gerrit change created: https://git.eclipse.org/r/62159
(In reply to Eclipse Genie from comment #9) > New Gerrit change created: https://git.eclipse.org/r/62159 This change adds validation for the external annotation cp attribute. ---------------------------------------- @Jay, do you want to review this change? ---------------------------------------- Contained: * 1 new API Constant in IJavaModelStatusConstants * 2 more triggers into ClasspathValidation.validate() The new control logic is as follows: ClasspathEntry.validateClasspathEntry() triggers a new method: validateExternalAnnotationPath() - effect is only by returning a JavaModelStatus as all validations do. When ClasspathEntry.getExternalAnnotationPath(..resolve=true) encounters a problem, we signal invalidExternalAnnotationPath() with two possible outcomes: - if we already have a buildpath problem for the current project: no-op - otherwise trigger ClasspathValidation.validate() to create a new marker When checking JavaBuilder.isClasspathBroken() and if we find a marker with the new problem ID CP_INVALID_EXTERNAL_ANNOTATION_PATH, we re-validate using ClasspathValidation.validate() and try once more. I manually tested that this indeed updates the new error marker (build path problem) on all relevant events. OTOH, projects not using external annotations should see no penalty from these new validations. I guess I should write a bunch of tests for o.e.j.c.tests.builder, other than that I believe we are done here ...
(In reply to Stephan Herrmann from comment #10) > ---------------------------------------- > @Jay, do you want to review this change? > ---------------------------------------- Looks good Stephan.
Gerrit change https://git.eclipse.org/r/62159 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=cdb3e8d99e2ddf40df3afd879c65627abb3809dc
Thanks, released for 4.6 M4
Verified for Eclipse Neon Version: Neon 4.6M4 Build id: I20151208-0800
For posterity: (In reply to Stephan Herrmann from comment #8) > (In reply to Stephan Herrmann from comment #6) > > (2) protect against immediate IAE > > Done via https://git.eclipse.org/r/61928 This has been pushed directly (on 2015-12-05) as http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=10d9ee7d6cd7cd29aebe50986af8fcc7cd9d4e32
