<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body style="background-color: rgb(255, 255, 255); color: rgb(0, 0,
0);" bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 02/17/2016 07:25 PM, Palo Marton
wrote:<br>
</div>
<blockquote
cite="mid:CAPWSNUkQktzVEMsu465S2GmJXtS-yq4tKw5mF_zNtfUsg0ULxw@mail.gmail.com"
type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<div dir="ltr">Another option is dissalow using T in static field
declaration, but allow use of T.erased, like this:
<div><br>
</div>
<div><span style="color:rgb(80,0,80);font-size:12.8px">class
Collection<any T> {</span><br
style="color:rgb(80,0,80);font-size:12.8px">
<span style="color:rgb(80,0,80);font-size:12.8px"> private
__SS Collection<T.erased> emptyCollection = …</span><br
style="color:rgb(80,0,80);font-size:12.8px">
<br style="color:rgb(80,0,80);font-size:12.8px">
<span style="color:rgb(80,0,80);font-size:12.8px"> private
__SS Collection<T> emptyCollection() { </span></div>
<div><span style="color:rgb(80,0,80);font-size:12.8px">
return (</span><span
style="color:rgb(80,0,80);font-size:12.8px">Collection<T>)</span><span
style="color:rgb(80,0,80);font-size:12.8px">emptyCollection;
// warning</span></div>
<div><span style="color:rgb(80,0,80);font-size:12.8px"> }</span><br>
</div>
<div><span style="color:rgb(80,0,80);font-size:12.8px">}</span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Feb 17, 2016 at 6:48 PM, Brian
Goetz <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Nice
catch. Yes, this would cause heap pollution. As would the
following Java 5 code:<br>
<br>
private Collection<?> collection = new
ArrayList<?>();<br>
public <T> Collection<T> c() { return
(Collection<T>) collection; }<br>
<br>
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.<br>
<br>
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.)</blockquote>
</div>
</div>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
<br>
There are other problematic situations, like accessing _SS members
from instance members:<br>
<br>
public class Foo<any T> {<br>
private _SS List<T> list = new ArrayList<>();<br>
<br>
public void add(T element) {<br>
list.add(element);<br>
}<br>
<br>
public T get(int i) {<br>
return list.get(i);<br>
}<br>
}<br>
<br>
<br>
Foo<String> fooStr = new Foo<>();<br>
Foo<Number> fooNum = new Foo<>();<br>
<br>
fooStr.add("abc");<br>
Number n = fooNum.get(0);<br>
<br>
<br>
...or, by analogy, accessing _SS members from generic methods.<br>
<br>
<br>
Regards, Peter<br>
<br>
<blockquote
cite="mid:CAPWSNUkQktzVEMsu465S2GmJXtS-yq4tKw5mF_zNtfUsg0ULxw@mail.gmail.com"
type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
<br>
<br>
On 2/17/2016 12:03 PM, Peter Levart wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Brian,<br>
<br>
On 02/15/2016 07:11 PM, Brian Goetz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Example:<br>
<br>
class Collection<any T> {<br>
private __SS Collection<T> emptyCollection
= …<br>
// ACC_SS field emptyCollection :
ParamType[Collection, TypeVar[T]]<br>
<br>
private __SS Collection<T>
emptyCollection() { return emptyCollection; }<br>
ACC_SS emptyCollection()ParamType[Collection,
TypeVar[T]] {<br>
getstatic ParamType[Collection,
TypeVar[T]].emptyCollection : ParamType[Collection,
TypeVar[T]]]<br>
areturn<br>
}<br>
<br>
When we specialize Collection<int>, the field
type, method return type, etc, will all collapse to
Collection<int> by the existing mechanisms.<br>
</blockquote>
<br>
This would work if the emptyCollection was actually
empty and immutable, but could you do the following:<br>
<br>
class Collection<any T> {<br>
private __SS Collection<T>collection = new
ArrayList<T>();<br>
<br>
public __SS Collection<T> collection() {
return collection; }<br>
}<br>
<br>
<br>
And then in code:<br>
<br>
Collection<String> cs =
Collection<String>.collection();<br>
Collection<Number> cn =
Collection<Number>.collection();<br>
<br>
cs.add("abc");<br>
Number n = cn.iterator().next();<br>
<br>
If cs and cn hold the same instance, we have
introduced heap corruption without compilation
warnings.<br>
<br>
So I suppose in language you could only access the _SS
members in the following way:<br>
<br>
Collection<?>.collection();<br>
Collection<int>.collection();<br>
Collection<long>.collection();<br>
Collection<ValueType>.collection();<br>
...<br>
<br>
but not:<br>
<br>
Collection<Object>.collection();<br>
Collection<String>.collection();<br>
...<br>
<br>
<br>
Like .class literals in the prototype.<br>
<br>
Regards, Peter<br>
<br>
<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
</body>
</html>