Bugzilla – Full Text Bug Listing
| Summary: | recompile doesn't happen | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Lee Breisacher <lbreisacher> | ||||
| Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | vladgri | ||||
| Version: | 2.0 | ||||||
| Target Milestone: | 2.1 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 2000 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 1868 [details]
a small eclipse project
We are not detecting a structural difference in a class when a default abstract method is replaced by a real implementation of the method. There is no signature change so we could handle this case differently if we knew the subtype hierarchy... but we don't currently. Ignore the previous post... the actual problem is in the MethodVerifier.
Using this simple example:
public interface I{
void a();
}
class X implements I {}
class Y extends X implements I {}
class Z extends X {}
X is correctly tagged with an error since it does not implement I.a()... but so
was the Y, which is wrong. Y inherits from X and should inherit an
implementation of I.a() from X even though Y says that it also implements I.
By simply adding a space to the type Y and recompiling, its error disappeared
because the binary type X (picked up from the class file) included a default
implementation of the method a()... but the source copy of X did not.
Updated the MethodVerifier to only tag the uppermost non-abstract class with
the error.
Verified. |
I think I have found a case where eclipse does not recompile something when it should. I made a change in one file that should have caused several other files to be recompiled, but they were not. Instead I see compile errors in those other files. When I did a project "Rebuild", the errors went away (or if I manually edit and save the other files, that also works, but I'd rather not do that because these files are in CVS and non-edits are a pain). Anyway, eclipse has always been very good about recompiling until this. I've managed to reproduce it in a small test case which is attached to this report. To make the problem appear, do this: 1. Add a method to AnInterface, e.g.: void c(); 2. Observe that (correct) compile errors appear in ASuperclass.java and AClass.java. 3. In AStaticClass (which is inside ASuperclass.java), add an implmentation for this new method, e.g.: public void c() {} 4. This should make all compile errors go away, but observe that AClass.java still shows errors. If you simply do a project Rebuild at this point, the errors go away. Or if you make a non-edit/save in AClass.java, the errors go away.