Project Coin: Inducing contributory heap pollution

Neal Gafter neal at gafter.com
Thu Jun 10 10:54:25 PDT 2010


On Thu, Jun 10, 2010 at 10:50 AM, Rémi Forax <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")?


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



More information about the coin-dev mailing list