Is language support for collections is a coin feature ?

[Rémi Forax]

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
>>
>>