Is language support for collections is a coin feature ?

[Jonathan Gibbons]

It would seem there is room for two distinct features here:

1) language support for collection literals
2) JVM support for large arrays

Logically, they are distinct, but either would be enhanced by the 
availability of the other.

-- Jon


On 09/24/2010 09:43 AM, Rémi Forax wrote:
> Le 24/09/2010 17:35, Eamonn McManus a écrit :
>    
>>   Hi,
>>      
> Hi,
>
>    
>> Without commenting on your conclusions, I don't think your premises
>> are correct. First of all, I don't think collection literals will be
>> limited to constant values, so they couldn't in general be stored in
>> the constant pool even if the classfile format were extended to allow
>> that.
>>      
> It depends how you design the new constant pool attribute. I can be a
> tree of constants (like the annotation values)
> plus some placeholders for storing values sent during the execution if
> by example some local variable values
> are needed.
>
>
>    
>> Secondly, if the 64K limit on the size of methods is a concern,
>> nothing stops the compiler from creating a private synthetic method
>> that creates and returns the collection, in the same way as it used to
>> create one for Foo.class literals, and even doing that recursively for
>> really big literals. The situation is anyway exactly the same as for
>> array literals today.
>>      
> What you describe for a collection is applicable for an array,
> but the current compiler fails if the array of literal is too big.
> Splitting a method is far from obvious because you can have side effect and
> the number of method parameters is limited to 255.
>
> This code is legal in Java:
>       int i =0;
>       int[] array = {i++, i};
>       System.out.println(i);
>
>
>    
>> Regards,
>>
>> Éamonn McManus  --  http://weblogs.java.net/blog/emcmanus
>>
>>      
> regards,
> Rémi
>
>    
>> On 24/9/10 4:32 PM, Rémi Forax wrote:
>>      
>>>     In the list of feature deferred to JDK8 [1]
>>> "Language support for collections" is listed as a coin feature,
>>> I think it's an error.
>>>
>>> There is no way to store a constant array in the bytecode [2],
>>> If we add supports for collections literal, hitting the 64k limit will
>>> be easier. So this feature also require to modify the classfile format
>>> to store constant array as constant in the bytecode.
>>> As far as I remember, a coin feature can't modify the classfile format.
>>>
>>> Moreover, supporting only collection literal is in my opinion a half
>>> baked feature,
>>> we all know JSON [3] and how powerful this kind of literal syntax is.
>>>
>>> User user = {
>>>      firstName: ''remi",
>>>      lastName: "forax",
>>>      addresses: [
>>>         {
>>>            zipcode: "30785"
>>>         }, {
>>>            zipcode: "67899"
>>>         }
>>>      ]
>>> };
>>>
>>> is better than
>>>
>>> User user = new User();
>>> user.setFirstName("remi");
>>> user.setLastName("forax");
>>> Address addr1 = new Address();
>>> addr1.setZipCode("30785");
>>> Address addr2 = new Address();
>>> addr2.setZipCode("67899");
>>> user.setAddresses([ addr1, addr2 ]);
>>>
>>> But to support this syntax, we need to introduce properties in the
>>> language.
>>> Also note that if you have property in your language, you can write
>>> a decent binding API. From here, the new JavaFX API is not far :)
>>>
>>> So a JSR is a better place for this feature.
>>> But it seems we are short in term of new JSR :)
>>> In my opinion, the best is to hijack the JSR 295 [4],
>>> sorry I mean to reactivate JSR 295.
>>>
>>> Rémi
>>>
>>>
>>> [1] http://openjdk.java.net/projects/jdk7/features/#deferred
>>> [2] Terence Parr: Java Parsers
>>>          http://wiki.jvmlangsummit.com/Image:Parr_Java_Parsers.pdf
>>> [3] http://json.org/
>>> [4] JSR 295: Beans Binding
>>>          http://jcp.org/en/jsr/detail?id=295
>>>
>>>
>>>        
>
>