Classes, specializations, and statics

[Brian Goetz]

Nice catch.  Yes, this would cause heap pollution.  As would the 
following Java 5 code:

     private Collection<?> collection = new ArrayList<?>();
     public <T> Collection<T> c() { return (Collection<T>) collection; }

The trouble is, the unchecked warning is in the library implementation, 
not the user code.  In the case of an immutable collection, we happily 
suppress the warning knowing that everything is safe.  If we were 
returning a mutable collection, it would be unsafe to suppress the 
warning, and doing so would be a library bug.

We have several ways out of this hole; one is to restrict invocation, as 
you suggest.  Another is to add some unchecked warnings.  (Another 
possible path is to treat signatures of erased __SS members, when 
accessed from outside, as if they contained capture variables.)




On 2/17/2016 12:03 PM, Peter Levart wrote:
> Hi Brian,
>
> On 02/15/2016 07:11 PM, Brian Goetz wrote:
>> Example:
>>
>> class Collection<any T> {
>>    private __SS Collection<T> emptyCollection = …
>>    // ACC_SS field emptyCollection : ParamType[Collection, TypeVar[T]]
>>
>>    private __SS Collection<T> emptyCollection() { return 
>> emptyCollection; }
>>    ACC_SS emptyCollection()ParamType[Collection, TypeVar[T]] {
>>        getstatic ParamType[Collection, TypeVar[T]].emptyCollection : 
>> ParamType[Collection, TypeVar[T]]]
>>        areturn
>>    }
>>
>> When we specialize Collection<int>, the field type, method return 
>> type, etc, will all collapse to Collection<int> by the existing 
>> mechanisms.
>
> This would work if the emptyCollection was actually empty and 
> immutable, but could you do the following:
>
> class Collection<any T> {
>    private __SS Collection<T>collection = new ArrayList<T>();
>
>    public __SS Collection<T> collection() { return collection; }
> }
>
>
> And then in code:
>
> Collection<String> cs = Collection<String>.collection();
> Collection<Number> cn = Collection<Number>.collection();
>
> cs.add("abc");
> Number n = cn.iterator().next();
>
> If cs and cn hold the same instance, we have introduced heap 
> corruption without compilation warnings.
>
> So I suppose in language you could only access the _SS members in the 
> following way:
>
> Collection<?>.collection();
> Collection<int>.collection();
> Collection<long>.collection();
> Collection<ValueType>.collection();
> ...
>
> but not:
>
> Collection<Object>.collection();
> Collection<String>.collection();
> ...
>
>
> Like .class literals in the prototype.
>
> Regards, Peter
>
>