Project Coin: Inducing contributory heap pollution

[Neal Gafter]

On Thu, Jun 10, 2010 at 11:08 AM, Rémi Forax <forax at univ-mlv.fr> wrote:

>  Le 10/06/2010 19:54, Neal Gafter a écrit :
>
>  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.
>

So we have a whole new set of ways of breaking source compatibility... like
adding @SuppressWarnings("safe") to a varargs method (it might end up being
the second one overridden in some subclass).


>
>
>
>> > 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.
>

Then you don't need it to be inherited.