Community
Participate
Working Groups
If the compilation errors in question are merely warnings which Eclipse is configured to treat as errors through Preferences > Java > Compiler > Errors/Warnings, it seems logical that Eclipse could safely suppress the alert. Eclipse SDK Version: 3.2.0 Build id: I20060505-1306
If the user wants them to be reported as error, then this means these errors should be fixed. If they should be "ignored", then they should be set as warnings/ignore.
Seems there are already numerous special cases for this. For instance, Change Method Signature to remove a parameter does not produce an alert if the parameter is never used, even if that's set to be an error. Extract Local Variable will work without complaint even in the face of numerous errors. Here's an example that has maybe 5 errors (promoted warnings): package eg; import java.util.*; public class Example { public void greet(String n) { // warning: parameter never read String name = "Bill"; // warning: local never read List x = new ArrayList(); // warning(3): {{List,ArrayList} is a raw type,local var never read} System.out.println("hi"); } } Inconsistent with those above cases, a Rename refactoring on the class complains that it might fail, although it clearly won't, and the warning of course goes away if the relevant messages are demoted to warnings. The alert is merely annoying, but the warning configuration and this alert seem as if they should be fully orthogonal, with the refactoring alert reserved for non-discretionary failures.
Moving to JDT UI
Haven't checked (maybe already so), but a criteria could also be to avoid producing more diagnostics than previously. Anyhow, this belongs to UI.
Should then be fixed in rename refactoring to work better with the optional warnings.
Changing OS from Mac OS to Mac OS X as per bug 185991
