Community
Participate
Working Groups
in m7 this may be related to bug 163194 Somehow, someone on my project team has a setting such that @Override annotations are being added to methods in a class that are defined in an interface that the class implements. E.g., interface Foo { m(); } class Bar implements Foo { @Override m() {} } Two questions: - why is @override being added on Bar.m()? It does not override m() it implements it since m() is from an interface. More to the point, what preference setting in the JDT preferences is causing this behaviour (so we can turn it off) - Since this is very problematic for the team, we would like to be able to ignore these errors but there does not seem to be a preference for this. Is there one? I suppose a third question would be, is there some refactoring/formatting we can do to have all of these removed?
further to this original post, it seems that some people are seeing hte errors and some are not even though they have the same projects checked out. Further strangeness, I found the project setting in the code clean up that adds some @override annotations but running the clean up does not seem to be the cause of these annotations being added.
This might depend on the compiler compliance settings. I think this is an error with compliance 1.5 and it is ok with compliance 1.6.
@Override is accepted in this case in 6.0, but not in 1.5 Is someone on your team running against 6.0 ?
Re: comment 0 Indeed 1.6 treats @Override different than 1.5. As documented in bug 163194, we may introduce a new preference to trigger complaining about missing @Override in this situation, so that end user may only trigger this behavior optionally. To be specific, 1.6 tolerates @Override on method implementation, but does not mandate it. Until we add a new pref, we are doing the same. We will tolerate it in 1.6, but not request adding it. The general preference for complaining about missing @Override is defined at: Java>Compiler>Errors/Warnings>Annotations>Missing '@Override' annotation It does not control automatic addition (done by JDT/UI).
Re: comment 1 An error is reported by compiler in 1.5 mode for such code: interface Foo { void m(); } class Bar implements Foo { @Override public void m() {} } and from 1.6 on, this code has become legal. I suspect some of your users are using 1.5 compliance, where some others are using 1.6 compliance. If the project does not dictate any specifics, then it will figure compliance from workspace defaults... which may differ between users. You probably want to have the project dictate these. Assuming this clarifies the issue. Will close as INVALID, since there would be nothing wrong from JDT standpoint. Please reopen if you disagree.
Verified for 3.4 RC1.
Yes the project team has a mix of folks on 1.5 and 1.6. Interestingly, the plugin project in question has J2SE1.5 as the execution environement and the compliance settings appear to be 1.5. I am running on a 1.5 VM but the default JRE is set to a 1.6 JRE. Phew, complicated... So it appears as if the project should NOT have @Override things in it according to the JRE/compliance settings. Indeed, if I put the annotations in I get errors. The question then is, how did the @overrides get there? I can pretty much guarantee that the code authors did not add them manually. More likely it was part of the code clean up on save actions or some such. The clean up settings do have the - Add missing '@Override' annotations selected. HOwever, I would only expect these annotations to be "missing" if it was valid to have them. Even if someone was runnig on 1.6, with the EE set to 1.5 and the compliance levels at 1.5, the clean up wizard should not generate them. With reference to comment 4, that preference controls error notification if the @override is MISSING. Tath is not my problem. My problem is that it is there! It appears from the explanation that in 1.5 it is an actual issue but is it something that people could reasonably ignore (i.e., does the code run any differently)
so looking a little more it appears that the EE for the bundle project was set correctly but the classpath for the project had not been updated. As a result, someone running Eclipse on 1.6 would get the default compliance settings for the project. These in turn would be based on the default JRE which would normally be the one running Eclipse. Sigh. In the end, looks like user error.
