Project Coin: Inducing contributory heap pollution

[Rémi Forax]

Le 10/06/2010 19:54, Neal Gafter a écrit :
> On Thu, Jun 10, 2010 at 10:50 AM, Rémi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     Le 10/06/2010 19:06, Neal Gafter a écrit :
>     > Re:
>     http://blogs.sun.com/darcy/entry/projectcoin_inducing_contributory_pollution
>     >
>     > I thought technical documents for project Coin were supposed to be
>     > published here?
>     >
>     > A nit: the @Inherited annotation "has no effect if [...] used to
>     > annotate anything other than a class", and so can't be used for the
>     > purpose described.
>     >
>
>     I have never understood why ?
>
>
> What if a method overrides more than one method, and one is annotated 
> @InheritedAnnotation("Foo") and the other @InheritedAnnotation("Bar")?

why not @InheritedAnnotation("FooBar") :)
More seriously, it should not compile.
It's like trying to override a method but with the wrong visibility 
modifier.

>     > Inheriting the diagnostic-suppression annotation would be a
>     great way
>     > to induce contributory heap pollution.  All you have to do is
>     extend a
>     > class with a warning-suppressed varargs method, providing an unsafe
>     > overriding implementation, and voila!  Heap pollution without a
>     > warning.
>     >
>     >
>
>     I think that the idea is to say, if an implementation is tagged as
>     safe,
>     all methods that override this implementation must be safe.
>
>
> Yes, they should be, but they might not be.
>
>     If you guarantee that ...
>
>
> How?

Me because I will use an annotation saying that explicitly.
The idea is if you tag a method with @SuppressWarnings("unsafe")
all methods that override that method must also be tagged with this 
annotation.
If you don't guarantee that it will not compile.

Rémi