JSR 308 and @SuppressWarnings

[Paul Benedict]

I was wondering if it is technically possible to add @Target.TYPE_USE
to @SuppressWarnings so that it's no longer necessary to declare a
variable to suppress an unchecked warning?

Given a method like this:
static void doSomething(Collection<? extends Something> coll);

I would like to do this:
@SuppressWarnings("unchecked") doSomething(Collection.class.cast
(otherCollection));

This example I have generalized from my code, but my real code has
proven the cast safe due to other preceding checks.

Right now, I am left with two options:
1) Use a private helper method to capture the wildcard. This is found
in Joshua Bloch's Effective Java 2E #28. Workable and doable, but its
strange to invoke another method for the sake of purely resolving a
compiler time issue.
2) Declare a local variable and suppress at that assignment.

Thoughts?

[Michael Ernst]

Paul-

I agree that it is irritating that Java forbids attaching @SuppressWarnings
to an arbitrary statement. This limitation yields ugly workarounds like
the ones you noted in your email.

> I was wondering if it is technically possible to add @Target.TYPE_USE
> to @SuppressWarnings so that it's no longer necessary to declare a
> variable to suppress an unchecked warning?
>
> Given a method like this:
> static void doSomething(Collection<? extends Something> coll);
>
> I would like to do this:
> @SuppressWarnings("unchecked") doSomething(Collection.class.cast
> (otherCollection));

This does not work because a method invocation is not a use of a type.
Even if @SuppressWarnings had ElementType.TYPE_USE in its @Target
meta-annotation, @SuppressWarnings still could not be written before a
method invocation.


The right fix to this would be to permit annotations on statements.
It would permit @SuppressWarnings to be used in a cleaner way, and would
have many other advantages besides.

Implementing annotations on statements should not be technically difficult.
However, it would require a concerted engineering effort to implement and
-- especially -- test the required changes. I don't have time to take the
leading role in that. I would be supportive of others who want to do that.
Although many people have expressed a desire for annotations on statements,
and have offered design input, no one has stepped forward to provide
substantive help. That's why this feature remains unimplemented and not a
part of JSR 308.

So, I'll ask again for volunteers: if anyone would like to take the lead
on the annotation-on-statements feature, please let us know.

-Mike