Community
Participate
Working Groups
Treating unreachable code errors as warnings is a violation of the Java Language Specification, per section 14.20. From reading the JDT-Core-dev mailing list, I know that the team is aware that such behavior violates the spec, but Eclipse still allows it in the RC3 build.
All optional compiler settings are configurable. You may even get the compiler to report errors for things which do not matter at the spec level, like deprecation. By default, unreachable code is an error. Now I agree there should be some clear indication that this violates the spec.
Actually do you have an example where when the setting is turned to ERROR, we still accept unreachable code ?
No. You interpreted my comments correctly. The point of my bug report is that setting it to be a warning/ignore should be disallowed (or as you said, a very explicit indication of non-compliance), because the specification explicitly states that under no circumstances should a compiler consider such code valid. If it were up to me, I'd remove the option entirely.
I am not disagreing with you. We kept the unreachable code setting for backward compatibility with VAJ. But now it is pretty much obsolete. Should only remain settings which make our compiler stricter, not more permissive. Still post 2.1
Unresolved imports also fall into the same category.
Reopen
UI should warn user if these settings are chosen.
Since from the spec it is an error we shouldn't allow users to set the warning level to warnings. IMO we should remove it from the UI and should always treat it as an error. Philippe, why do you think we have to keep this VAJ compatibility mode. Wouldn't it make more sense to remove it ?
I believe migration is still an issue (need to check). Also for backward compatibility reason, I don't think we can remove this support, though it would indeed be desirable. John - can you please comment on the migration concerns ?
I am collecting additional feedback on the migration issue - more info later. My personal reaction: I don't find the unreachable code warning compelling. The unresolved import case doesn't justify an exception. Why we did this (my guess): If there is an error, then we only generate stubs for the method (or type for the import case). By making these warnings, we enabled development/debugging while the "problem" existed.
Just to clarify: in case an import error is detected, only static methods and constructors are turned into problem methods. The rest is just fine (if not referencing these imports). I can understand why it would be scary for some user to enable the compiler to be in a mode where we accept a superset of the language (exported source wouldn't compile with other compiler). Maybe, some clear indication that changing these settings is breaking the spec, is all we need if we still need to maintain the migration story alive.
John, do you have more information regarding the migration issue.
The migration issue is not a show stopper. There are two requirements: we need to (1) ensure that no code is lost during migration (for example, we cannot refuse to import the code if it had errors) and (2) help the user through the migration (we can do this by reporting the errors and allowing the user to fix them. If there was a quick fix (?) it could be even better). We should add this information to the 3.0 migration guide.
The compiler preference page has been redesigned fro 3.0M2 according to suggestions by Philippe. The two problematic options have been removed from the UI. Veto if that is not what you want. Philippe, I suggest you deprecate the preference constants and ignore if the value (from an old workspace) still is set to ignore or warning.
I agree.
Invalid preferences are now ignored, thus the compiler cannot violate the specs any longer. Fixed
Fixed.
Verified
