RFR 7118066: Warnings in java.util.concurrent package

[David Holmes]

On 6/12/2011 12:14 PM, David Holmes wrote:
> On 6/12/2011 11:45 AM, Rémi Forax wrote:
>> On 12/06/2011 02:12 AM, David Holmes wrote:
>>> Is the reason for constructs like this:
>>>
>>> HashEntry<K,V>[] tab = (HashEntry<K,V>[])new HashEntry<?,?>[cap];
>>>
>>> that we can't utilize diamond? Otherwise it would nicely reduce to:
>>>
>>> HashEntry<K,V>[] tab = new HashEntry<>[cap];
>>
>> This should not compile because otherwise you can write
>
> This compiles fine:
>
> @SuppressWarnings("unchecked")
> public class TestGenerics<K,V> {
>
> static class HashEntry<K,V> { }
>
> public void m() {
> HashEntry<K,V>[] newTable = new HashEntry<>[1];
> }
> }
>
>
> I don't know exactly what the type inference code does but I assumed it
> effectively converted the above to:
>
> HashEntry<K,V>[] newTable = (HashEntry<K,V>[]) new HashEntry[1];
>
> and not to:
>
> HashEntry<K,V>[] newTable = new HashEntry<K,V>[1];
>
> which of course does not compile.

Hmmm. Perhaps this is a compilation accident? I don't see anything in 
the spec that allows diamond to be used with array creation expressions.

David
-----

> David
> -----
>
>
>> HashEntry<String,String>[] tab = new HashEntry<>[12];
>> Object[] o = tab;
>> o[1] = new HashEntry<Integer, Integer>();
>> The VM should reject the line above by throwing an ArrayStoreException
>> but because of the erasure, it will not. So creating an array of
>> parameterized type
>> is only possible if you create a reifed type that inherits from an array
>> of parameterized type.
>>
>> By example, this code is valid:
>> enum Foo { foo }
>> Enum<Foo>[] enums = Foo.values();
>>
>> Rémi
>>
>>>
>>>
>>>
>>> On 6/12/2011 1:36 AM, Chris Hegarty wrote:
>>>>
>>>> Cleanup warnings in the j.u.c. package.
>>>>
>>>> This is a sync up with the warning fixes in Doug's CVS. There are
>>>> also a
>>>> few style cleanups, import fixes, trivial local variable renaming,
>>>> typos, etc. But nothing too surprising!
>>>>
>>>> http://cr.openjdk.java.net/~chegar/7118066/webrev.00/webrev/
>>>>
>>>> -Chris.
>>>>
>>>> P.S. I have already reviewed this, and the contribution is of course
>>>> from Doug.
>>