Bug 22635 - recompile doesn't happen
Summary: recompile doesn't happen
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.1 M1   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 24514 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-08-21 09:58 EDT by Lee Breisacher CLA
Modified: 2002-10-08 14:08 EDT (History)
1 user (show)

See Also:


Attachments
a small eclipse project (3.21 KB, application/octet-stream)
2002-08-21 09:59 EDT, Lee Breisacher CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lee Breisacher CLA 2002-08-21 09:58:29 EDT
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.
Comment 1 Lee Breisacher CLA 2002-08-21 09:59:37 EDT
Created attachment 1868 [details]
a small eclipse project
Comment 2 Kent Johnson CLA 2002-08-30 15:34:30 EDT
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.
Comment 3 Kent Johnson CLA 2002-09-03 16:36:33 EDT
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.
Comment 4 David Audel CLA 2002-09-19 06:41:03 EDT
Verified.
Comment 5 Kent Johnson CLA 2002-10-08 14:08:52 EDT
*** Bug 24514 has been marked as a duplicate of this bug. ***