Is language support for collections is a coin feature ?

[Eamonn McManus]

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