Bugzilla – Full Text Bug Listing
| Summary: | [1.7] @SuppressWarnings does not support "varargs" token | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Dani Megert <daniel_megert> |
| Component: | Core | Assignee: | Jesper Moller <jesper> |
| Status: | VERIFIED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | anchakrk, deepakazad, jarthana, markus.kell.r, Olivier_Thomann, srikanth_sankaran, stephan.herrmann, wearyofallthiscrap |
| Version: | 3.7 | Flags: | stephan.herrmann:
review+
|
| Target Milestone: | 4.3 M6 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=344783 | ||
| Whiteboard: | |||
|
Description
Dani Megert
Oracle's 'javac' (b145) also doesn't support that suppress token but it can be used as argument to -Xlint. However, it has not effect. Since the example given in the javac documentation reports a warning as an unchecked warning, I would close as invalid.
Eclipse compiler also reports this issue as an unchecked warning. So a @SuppressWarning("unchecked") annotation would work with both compilers.
Even if this is supposed to be handled by javac, it clearly has no effect. We can reassess once this is fixed in javac. Fixing it would mean that the annotation would not work for both compilers.
Daniel, any comment ?
JSR-334 says:
, or in the compiler reference implementation the @SuppressWarnings({"unchecked", "varargs"}) annotation can be applied.
This should be clarified in the spec before we continue, especially whether both tokens are needed to suppress the warning.
Not critical for 3.7.1.
(In reply to comment #3) > JSR-334 says: > > , or in the compiler reference implementation the > @SuppressWarnings({"unchecked", "varargs"}) annotation can be applied. > > This should be clarified in the spec before we continue, especially whether > both tokens are needed to suppress the warning. > > Not critical for 3.7.1. Where did you find this? I think it has been removed from the final version of the spec. > Where did you find this? I think it has been removed from the final version of
> the spec.
JSR 334 Proposed Final Draft Specification, v1.0 (in the discussion section).
In the final spec (integrated with the existing JLS), the mention to "varargs" is removed. So unless Oracle commits to fix the usage of @SuppressWarnings("varargs"), I would close as WONTFIX. Right now, only "unchecked" removes the corresponding warning.
(In reply to comment #6) > In the final spec (integrated with the existing JLS), the mention to "varargs" > is removed. So unless Oracle commits to fix the usage of > @SuppressWarnings("varargs"), I would close as WONTFIX. Right now, only > "unchecked" removes the corresponding warning. As I wrote in comment 1 it seems that Oracle's 'javac' is accepting the "varargs" token when passed to -Xlint (didn't test with latest version). So, we need to clarify the final state of this. (In reply to comment #7) > As I wrote in comment 1 it seems that Oracle's 'javac' is accepting the > "varargs" token when passed to -Xlint (didn't test with latest version). So, we > need to clarify the final state of this. Latest version (b147) still doesn't handle the "varargs" token as it should. It is still reported as an "unchecked" warning. I'll clarify this case with Oracle. (In reply to comment #8) > (In reply to comment #7) > > As I wrote in comment 1 it seems that Oracle's 'javac' is accepting the > > "varargs" token when passed to -Xlint (didn't test with latest version). So, we > > need to clarify the final state of this. > Latest version (b147) still doesn't handle the "varargs" token as it should. It > is still reported as an "unchecked" warning. But they still accept the token I guess, right? > I'll clarify this case with Oracle. Thanks. Ok, there are cases where javac emits more warnings than the Eclipse compiler.
import java.util.List;
public class X {
@SafeVarargs
final void m(List<String>... ls) {
Object[] o = ls;
System.out.println(o);
}
}
if you compile this code using:
javac X.java -Xlint:varargs
you get two warnings.
They can be suppressed by adding @SuppressWarnings("varargs") on the declaration of the method.
The Eclipse compiler doesn't emit any warning with the given code. This means that we would emit an unused suppress warning token when the code is compiled with the Eclipse compiler even if we add support for the "varargs" token.
Srikanth, please follow up on this.
Moving it out to later to allow for some investigation time for SE8 work. Any word on this? It's been a little over a year.
Currently, the Eclipse compiler gives multiple warnings on
void func (Generic<Something>... foo) { .... }
with complaints about heap pollution at the function definition, and complaints about "generic array created for vararg parameter" at the call site.
Neither @SuppressWarnings("varargs") nor @SafeVarargs is supported. Using @SuppressWarnings("unchecked") works, but has to be duplicated at both the definition and the call site.
(In reply to comment #13) > Neither @SuppressWarnings("varargs") nor @SafeVarargs is supported. Using The latter is supported, do you have a test case that shows it is not ? Shankha, please take a look. Shankha, Jesper has some free cycles and is looking for tasks. I'll assign this to him and find you tasks when you are complete with what you are working on. Thanks. (In reply to comment #14) > (In reply to comment #13) > > Neither @SuppressWarnings("varargs") nor @SafeVarargs is supported. Using > > The latter is supported, do you have a test case that shows it is not ? I'm traveling for a few days but that's what we were seeing before I left. If this ticket is still open when I return I'll try and hunt up a minimal testcase, but if your tests show that Indigo is supposed to support @SafeVarargs, can you post a minimum version number that we need to have installed? (In reply to comment #16) > (In reply to comment #14) > > (In reply to comment #13) > > > Neither @SuppressWarnings("varargs") nor @SafeVarargs is supported. Using > > > > The latter is supported, do you have a test case that shows it is not ? > > I'm traveling for a few days but that's what we were seeing before I left. > If this ticket is still open when I return I'll try and hunt up a minimal > testcase, but if your tests show that Indigo is supposed to support > @SafeVarargs, can you post a minimum version number that we need to have > installed? Indigo SR1 aka 3.7.1 was the first eclipse release with Java 7 support. In reply to comment #14) > (In reply to comment #13) > > Neither @SuppressWarnings("varargs") nor @SafeVarargs is supported. Using I find Eclipse's @SafeVarargs working as expected, at least in HEAD (I haven't checked 3.7.1) As for javac's handling of @SuppressWarnings("varargs"), it's a little funny, considering this program: ----------------------------------------- import java.util.List; public class X { //@SuppressWarnings("varargs") //@SafeVarargs final void m(List<String>... ls) { Object[] o = ls; System.out.println(o); } } ----------------------------------------- Compiling this with -Xlint:varargs,unchecked as is will give 'unchecked'-warnings. If I then add @SafeVarargs, it will report TWO identical varargs-warnings: ----------------------------------------- $ javac -Xlint:varargs,unchecked X.java X.java:7: warning: [varargs] Varargs method could cause heap pollution from non-reifiable varargs parameter ls Object[] o = ls; ^ X.java:7: warning: [varargs] Varargs method could cause heap pollution from non-reifiable varargs parameter ls Object[] o = ls; ^ 2 warnings ----------------------------------------- I'm guessing that's an error. It's as if the varargs-warning is an alternative to the unchecked-warning, in the sense that @SafeVarargs is overridden by the -Xlint:varargs option. Turning that on in Eclipse, i.e. requiring people to use either "@SafeVarargs @SuppressWarnings("varargs")" or "@SuppressWarnings({"varargs","unchecked"})" on such a method, surely is bad. In other words, do we really want to emulate javac's behaviour for "-Xlint:varargs,unchecked"? What should the default be? In any case, the JLS 7 text doesn't mention the "varargs" warning type, it's only present in the change note for Java 7, and in javac, in a very backwards way. Since the warning wouldn't add anything which isn't better supported by SafeVarargs, I'm proposing to close as WONTFIX. Stephan, when you have a moment, could you please review the assessment from comment#18 ? TIA. I agree with most that has been said: - the "varargs" token only occurred in the discussion section of the JSR 334 spec, mention has been dropped for the incorporation into the JLS. - ECJ correctly supports the @SafeVarargs annotations starting with 3.7.1 -> NOTE: needs compliance 1.7 for interpreting that annotation So, ECJ conforms to the spec in these regards. However, comment 10 has a valid point about a warning from javac, which is never emitted by ECJ, which helps to make @SafeVarargs methods still safer. The assignment to "Object[] o" does contribute to the heap pollution and is not covered by our "unchecked" warnings. BTW, I don't see a duplicate warning as reported in comment 18 (1.7.0_10). Interestingly, when compiling without -Xlint, javac only advertises the "unchecked" token, NOT the "varargs" token. From this I see two good solutions: (a) close as WONTFIX (as proposed in comment 18) (b) implement the additional warning AND the corresponding "varargs" token. Just, implementing only the "varargs" token doesn't seem to solve anything. (In reply to comment #20) > > From this I see two good solutions: > > (a) close as WONTFIX (as proposed in comment 18) Thanks for the assessment Jesper and the review Stephan, > (b) implement the additional warning AND the corresponding "varargs" token. This will be covered by https://bugs.eclipse.org/bugs/show_bug.cgi?id=344783 Agreed and VERIFIED. Verified for 4.3 M6 |