Is language support for collections is a coin feature ?

[Reinier Zwitserloot]

Advocate of the devil mode:

User user = new User()
    .firstName("Remi")
    .lastName("Forax")
    .addAddress().zipCode("30785").done()
    .address(new Address().zipCode("30785"));

Note the two styles for address - you can pick either, whichever you think
is nicer (don't, obviously, add both methods to the API!)

As near to the cleanliness as the JSON syntax as makes no difference, and
perfectly doable in java today. It does mean User and Address can't be
immutable and that's a bit of a shame. Fixable though:

User user = User.make()
    .firstName("Remi")
    .lastName("Forax")
    .addAddress().zipCode("30785").done()
    .address(Address.make().zipCode("30785").build())
    .build();

Moving away a bit from the cleanliness, but still sufficiently nice to
question the need for major language change to address this stuff.

For extra zing, though this is delving a bit deep into language hackery, you
can even do this, in today's java. The below works with immutables, and
unlike the JSON example, supports a lot more safety features - typoing any
of the keys will result in an as-you-type error, as does assigning a value
of the wrong type:

User user = new UserBuilder() {{
    firstName = "Remi";
    lastName = "Forax";
    addresses.add(
        new AddressBuilder() {{
            zipCode = "30785";
        }},
        new AddressBuilder() {{
            zipCode = "67899";
        }});
}}.build();

Sure, there's opportunity for cleanup. But I don't think it should be high
priority. Especially because, even with the superfluous need for the double
braces, the call to build(), and the need for an add method for 0-*
'fields': This beats the JSON example, because of all the safety measures.

Now, that's API use. Writing the boilerplate to make the above code
possible, _THAT_ is a right mess. It's something Roel and I are looking at
generating with lombok. I got the vibe from some of the reports at JavaOne
(I'm not there myself) that there's a plan to take lombok's @Data annotation
and make it part of java itself. In that case, well, while you're at it...
:)

NB: Expanding builders to support compile-time reporting of forgetting to
set required fields is possible but all approaches I can think of do not
scale. If its deemed important, then the only way to get there that I can
see, is to add syntax support for it.

 --Reinier Zwitserloot



On Fri, Sep 24, 2010 at 4:32 PM, Rémi Forax <forax at univ-mlv.fr> 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
>
>
>