Community
Participate
Working Groups
End-users now think Eclipse is not as good as other IDEs for on-the-fly error reporting. However, JDT provides many warnings which are disabled by default. They are like an hidden feature which would increase the value of the IDE if they were shown. So I suggest that all JDT rules get shown as warning by default, and let people who don't like them de-activate them.
> End-users now think Eclipse is not as good as other IDEs for on-the-fly error > reporting. Let's say *some* end users, please ;-). Blindly enable all warnings is a no go. Some really are optional and must stay disabled by default. Plus, we don't want to flood all existing Eclipse users with tons of new warnings. Just follow the JFace generics thread to see what happens if one does. Having said that, we can do a pass over our options and enable those we think are indeed useful if set to warning or even error. Another improvement would be to offer 'Set All To' buttons like we already have on the 'API Errors/Warnings' page. This is captured by bug 248306.
(In reply to Dani Megert from comment #1) > Blindly enable all warnings is a no go. Some really are optional and must > stay disabled by default. Plus, we don't want to flood all existing Eclipse > users with tons of new warnings. > Having said that, we can do a pass over our options and enable those we > think are indeed useful if set to warning or even error. And what about introducing the INFO level for thos that you think are useless? Cf bug 149334 . As I already wrote in the JFace Generics disucssion, IMO any validation provides value. And preferences can be imported/exported from an Eclipse instance to the other, so if one takes an Eclipse 4.4. with all validation reported as warnings and doesn't like it, it's easy to restore his previous configuration. Other IDEs built on Eclipse can easily override the default settings via plugin_customization.ini to make warnings more relevant to the kind of activity they target.
(In reply to Mickael Istria from comment #2) > (In reply to Dani Megert from comment #1) > > Blindly enable all warnings is a no go. Some really are optional and must > > stay disabled by default. Plus, we don't want to flood all existing Eclipse > > users with tons of new warnings. > > Having said that, we can do a pass over our options and enable those we > > think are indeed useful if set to warning or even error. > > And what about introducing the INFO level for thos that you think are > useless? Cf bug 149334 . Might be worth a discussion in bug 83548. > > As I already wrote in the JFace Generics disucssion, IMO any validation > provides value. > And preferences can be imported/exported from an Eclipse instance to the > other, so if one takes an Eclipse 4.4. with all validation reported as > warnings and doesn't like it, it's easy to restore his previous > configuration. > Other IDEs built on Eclipse can easily override the default settings via > plugin_customization.ini to make warnings more relevant to the kind of > activity they target. We don't need to reiterate on this.
