Project Coin: Inducing contributory heap pollution

[Joe Darcy]

Neal Gafter wrote:
> On Thu, Jun 10, 2010 at 10:15 AM, Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>         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 was thinking that the spec for the annotation would allow
>     compilers to issue errors if they could prove bad things actually
>     happen in an implementation of a so annotated method.
>
>
> That's conservative in the wrong direction.

Yes, I understand that such a proposal would not be sound with respect 
to heap pollution.

>   Allowing errors [sic; warnings] isn't good enough.  You have to 
> require them when there's any possibility of heap pollution.

Unless the heap pollution contract is changed.  (There is already a 
small hole in the contract due to a few core reflection methods with 
signatures like "public TypeVariable<Constructor<T>>[] 
java.lang.reflect.Constructor.getTypeParameters()".)

The checked exception analysis is another analysis with a contract with 
a few holes; "Java Puzzlers" -- Puzzle 43 "Exceptionally Unsafe" gives 
two examples.  Recent discussion on lambda-dev give a few more.

>   In other words, you'd have to require the diagnostic unless the 
> compiler can prove that bad things won't happen.  For code 
> portability, you'd have to specify what "the compiler can prove" 
> means, precisely.  And if we could do that, then we wouldn't need any 
> of these annotations in the first place.

It is technically feasible to define another dataflow-style analysis 
that would recognize a (hopefully useful) subset of the "definitely 
safe" uses of arrays from varargs, as Reinier as started sketching out.  
Similarly, a "definitely unsafe" analysis could be defined too.

Here is a strawman version of the new annotation type, name for 
discussion purposes only:

@Documented // Part of the method's public contract
@Target(ElementType.METHOD) // Only meaningful on methods & constructors
@Retention(RetentionPolicy.RUNTIME) // Could get away with SOURCE, but 
might want runtime checking
public @interface TrustMeOnVarargs {}

Since the annotation type is only usable on methods and not classes, 
annotation inheritance is not applicable since only annotations on 
classes can be inherited.  (So my blog post was incorrect to call for an 
@Inherited annotation on a method; when writing the entry I had 
forgotten about the class inheritance only restriction.)

The lack of inheritance might not be much of an issue in practice if 
most of the methods that would be useful to annotate are static methods 
or constructors.

-Joe