Classes, specializations, and statics
Palo Marton
palo.marton at gmail.com
Wed Feb 17 18:25:16 UTC 2016
Another option is dissalow using T in static field declaration, but allow
use of T.erased, like this:
class Collection<any T> {
private __SS Collection<T.erased> emptyCollection = …
private __SS Collection<T> emptyCollection() {
return (Collection<T>)emptyCollection; // warning
}
}
On Wed, Feb 17, 2016 at 6:48 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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
>>
>>
>>
>
More information about the valhalla-spec-observers
mailing list