Bugzilla – Full Text Bug Listing
| Summary: | static imports are removed on "organize imports" save action if annotations can't be found on the classpath | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | David Green <greensopinion> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | andrew.eisenberg, cptwunderlich, jarthana, stephan.herrmann |
| Version: | 4.5 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
David Green
Unfortunately, we can't share the code, but I can give a more detailed description of what is happenig.
The project where this occurs in is a PDE project. There is a class in that project that is trying to load a type from another dependent project. This type is annotated by an annotation from a third project. This annotation has runtime retention. The set up looks roughly like this:
Test bundle (requires main bundle)
class AClassTest {
private AClass aClass;
}
Main bundle (requires annotation bundle)
@SomeAnnotation
class AClass {}
Annotation bundle
@Retention(RetentionPolicy.RUNTIME)
@interface SomeAnnotation{}
Now with this setup it seems like the compiler should be happy and indeed it is, but it seems like the resolver is not. And the exceptions being thrown are happening during resolve time.
Hope this helps a bit with reproducibility.
Moving to JDT core since this is not a UI bug. Hi Andrew, thanks for explanations. (In reply to Andrew Eisenberg from comment #1) > Now with this setup it seems like the compiler should be happy and indeed it > is, but it seems like the resolver is not. And the exceptions being thrown > are happening during resolve time. By resolver you mean call paths following org.eclipse.jdt.core.dom.TypeBinding.getDeclaredMethods() like above above? (which is a "side-entry" into the compiler). BTW: the stack trace above is triggered from quick assist, do you see similar exceptions also during organize imports? > By resolver you mean call paths following > org.eclipse.jdt.core.dom.TypeBinding.getDeclaredMethods() like above above? > (which is a "side-entry" into the compiler). Yes. > BTW: the stack trace above is triggered from quick assist, do you see > similar exceptions also during organize imports? I can't seem to elicit exceptions in any other way, but I have the following behavior: 1. No code hovers 2. Organize imports removes static imports, but leaves all others 3. Semantic highlighting (eg- italicizing static field references) is not working 4. Mark occurrences not working 5. Extract method fails with the following exception: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypesFor(SourceTypeBinding.java:1770) at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.methods(SourceTypeBinding.java:1464) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.availableMethods(ReferenceBinding.java:229) at org.eclipse.jdt.core.dom.TypeBinding.getDeclaredMethods(TypeBinding.java:289) at org.eclipse.jdt.internal.corext.dom.Bindings.findMethodInType(Bindings.java:360) at org.eclipse.jdt.internal.corext.refactoring.Checks.checkMethodInType(Checks.java:313) at org.eclipse.jdt.internal.corext.refactoring.code.ExtractMethodAnalyzer.checkInput(ExtractMethodAnalyzer.java:351) at org.eclipse.jdt.internal.corext.refactoring.code.ExtractMethodRefactoring.checkFinalConditions(ExtractMethodRefactoring.java:476) at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:85) at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:121) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) Oddly however, rename refactoring on a method of the class works correctly. It finds references both inside the file and outside. This issue affects me as well on Oxygen 4.7 JEE Bundle
> Eclipse Java EE IDE for Web Developers.
> Version: Oxygen Release (4.7.0)
> Build id: 20170620-1800
> OS: Windows 10, v.10.0, x86_64 / win32
The major difference is, that the annotations should be on the classpath. It is a Maven project, the two classes are in the very same package.
Saving once sometimes does nothing, but two consecutive changes + save almost certainly trigger the behavior.
(In reply to Benjmain Maurer from comment #5) > This issue affects me as well on Oxygen 4.7 JEE Bundle > > Eclipse Java EE IDE for Web Developers. > > Version: Oxygen Release (4.7.0) > > Build id: 20170620-1800 > > OS: Windows 10, v.10.0, x86_64 / win32 > > The major difference is, that the annotations should be on the classpath. It > is a Maven project, the two classes are in the very same package. > > Saving once sometimes does nothing, but two consecutive changes + save > almost certainly trigger the behavior. I forgot to mention, that my Error Log is empty. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |