Project Coin: Inducing contributory heap pollution
forax at univ-mlv.fr
Thu Jun 10 11:08:04 PDT 2010
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:
> > 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
> > 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
> all methods that override this implementation must be safe.
> Yes, they should be, but they might not be.
> If you guarantee that ...
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
If you don't guarantee that it will not compile.
More information about the coin-dev