Is language support for collections is a coin feature ?

Rémi Forax forax at univ-mlv.fr
Fri Sep 24 07:32:55 PDT 2010


  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




More information about the coin-dev mailing list