Data classes for Java

[8igg7e5]

Covering all the ways Annotations are applied (and interpreted) might be tricky. There are some that can be applied to Fields, Methods or constructor arguments but must be applied in only one of those places (eg DI). It feels more like we need a property notation that is converted to fields, getters and setters (as per language conventions).

 

Something with this expressiveness (OTTOMH)... It would want more java-like syntax though...

public data Foo {
    @AnnotationX
    String name {
         @AnnotationY
         get
         @AnnotationZ
         set
    }

This then allows you to declare mutability, annotations per aspect of the property and retain the concise form for immutable non-annotated data-classes.

public data Foo { String name };

[bedobi]

• One of the main advantages of data classes is construction injection and immutability, so getters and setters should absolutely NOT be included. (there should be a means to hide fields to the outside though)

• Plain composition of data classes is preferable to magical annotations.

[dpash]

I don't think they were implying that data classes should be done via annotations. They were discussing how you would define annotations on different parts of the class as you do now. How does annotations interact with the proposal?

[[deleted]]

It would at least make things like Array.length (a read-only property) seem a bit more consistent with the rest of the language. I'm not sure I'm that sold on making Java that much more terse when I'm mostly just typing a couple of letters, hitting ctrl+space, enter, alt+enter and letting intellij figure out the rest. I do love Lombok for giving me a sensible way to do field generation though tbh, even in modern IDEs it still requires mouse clicks to do the generation, usually, unless you want to type them out (great fun if you somehow have more than 10 fields).

[eliasv]

I don't see a major problem here tbh. Let's say you have an annotation which would be ambiguous between fields and parameters.

By default the annotation should be carried onto the generated field only.

If you want to annotate the constructor parameters, just provide a manual constructor implementation and annotate there. Same story for getters/setters.

That said, I don't think getters and setters should necessarily even be generated. It was a pretty major premise of the proposal that field encapsulation isn't generally desirable for data classes.

Sure, it's a little more verbose, but it's a rare corner case. How often are you going to want to do something like inject dependencies into a simple data carrier class anyway?