Bugzilla – Full Text Bug Listing
| Summary: | Strange suppress warning tokens | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Dirk Baeumer <dirk_baeumer> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | martinae |
| Version: | 3.1 | ||
| Target Milestone: | 3.2 M5 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
They will likely never get standardized. If we do not support them, who will ? "unchecked" is the keyword used to allow accesses to raw types. IMO is 'unchecked' too generic. Longer, more precice keywords are much better for the readability. IMO, it would be much more friendlier to use a Eclipse specific prefix, e.g. 'e_' for all keywords introduced by us. Sun will add more and more keywords for the standard compiler. Users are going to want support for these 'default' keywords. If one of these words happens to clash with one of our keywords, things will get messy. We scaled our warning tokens set down to a reasonable portion. See documentation for actual list. |
RC1: I had the following source code: @interface Annotation { public String description() default ""; } class Sub implements Annotation { } - quick fix offered me a suppress warning which introduced: @SuppressWarnings("intfAnnotation") First of all the key word "intfAnnotation reads strange since users will try to read it as int for integer, f and Annotations. Furthermore I think we should restrict ourselves to the absolutly minimum of supress warning keywords. Since they aren't standardized yet I think it will be confusing for the users. Especially if we have key words for our own compiler warnings.