Is language support for collections is a coin feature ?

[Joe Darcy]

Hello.

Eamonn McManus wrote:
>   Hi,
>
> Without commenting on your conclusions, I don't think your premises are 
> correct. 

Yes, the assumptions are not necessarily valid.

First, the Coin proposal for collection literals [1] desugars into a 
sequence of calls to new methods.  No JVM change is needed; although 
such a design is possible of course.  The lack of ability is store, say, 
pre-initialized arrays is a long-standing shortcoming of the class file 
format.  However, I doubt collections literals would do much to 
exacerbate that problem.

Cheers,

-Joe

[1] http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001193.html

> 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. 
> 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.
>
> Regards,
>
> Éamonn McManus  --  http://weblogs.java.net/blog/emcmanus
>
>
> 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
>>
>>
>>     
>
>