5 ms·

Makes absolutely no difference here, Kotlin data classes are just regular Java classes like records are - the compiler implements these methods automatically.

Makes absolutely no difference here, Kotlin data classes are just regular Java classes like records are - the compiler implements these methods automatically. Oracle literally did the minimum effort required here, Java Records don't even generate bean-compliant getters FFS.

nobleach 7y ago
I'd equate Kotlin's data clases to Lombok's @data annotation.
doctor_eval 7y ago
Agreed, the declaration syntax is awful and the generated methods aren’t idiomatic. That saidC I don’t even understand the point of generating getters in this case. The fields could just be declared public final. Java’s obsession with wrapping fields in methods has never made sense to me.
- erik_seaberg 7y ago
  Scala lets you quietly replace a field with an accessor method, but Java does not. You'd have to change all consumer code to add laziness or test mocking/spying.
  - doctor_eval 7y ago
    in my experience accessor methods are a particularly nasty kind of YAGNI. I'm not saying you never need to override a field to make it lazy, for example, but the cost of getters and setters has never, in my practical experience, outweighed the cost.
    - erik_seaberg 7y ago
      If they're generated and inlined away, what's the remaining cost?
      - doctor_eval 7y ago
        The cost is in typing effort, fluency, legibility and complexity. There is no Good reason to prefix every field access with get, and end it with (). It’s five more keys to type and makes the code more verbose. thing.getId() is longer and less readable than “thing.id”. Why does the compiler have to spend time inlining the call? Can you guarantee that it does? IMO the question shouldn’t be “what is the cost of this complexity?” The question should be, “what is the benefit?”. And in 20+ years of java dev, I just don’t see any benefit in accessor methods at all. We never wire up our components with JavaBeans introspection... so why do we keep this nonsense going?
pron 7y ago
You're confused because you don't understand what this feature is and compare it to things with different goals. https://openjdk.java.net/jeps/359 https://openjdk.java.net/jeps/359: > Records provide a compact syntax for declaring classes which are transparent holders for shallowly immutable data... While it is superficially tempting to treat records as primarily being about boilerplate reduction, we instead choose a more semantic goal: modeling data as data. (If the semantics are right, the boilerplate will take care of itself.) It should be easy, clear, and concise to declare shallowly-immutable, well-behaved nominal data aggregates... It is not a goal to declare "war on boilerplate"; in particular, it is not a goal to address the problems of mutable classes using the JavaBean naming conventions.
- thu2111 7y ago
  I think the point a lot of posters are getting at is, maybe reducing boilerplate for JavaBeans is a more useful goal, given the huge ecosystem of tools and code that assumes the JavaBean pattern. That's what Kotlin did and it's been very successful, so there's no fundamental reason why not. It's a philosophical objection of the form "mutability is bad", which feels somehow Haskellish and un-Java-like. What happened to being a blue collar language?
  - pron 7y ago
    > so there's no fundamental reason why not That another language has done it does not mean there is no fundamental reason not to do it. A fundamental reason can be that its cost/benefit ratio isn't good enough. Other languages weigh language complexity less harshly than Java. > That's what Kotlin did and it's been very successful In what sense has it been "very successful"? That the small minority of people on the Java platform that have chosen to use Kotlin like this feature? Currently, there are still more people using Scala, does that mean that all Scala features have been even more successful? In any event, that would be a different feature, and it will be judged, and then perhaps adopted, separately. > It's a philosophical objection of the form "mutability is bad", which feels somehow Haskellish and un-Java-like. What happened to being a blue collar language? That's not the objection, and Java is still blue-collar. Records don't do that not because of some "anti mutation" sentiment but because records are about something else than reducing JavaBean boilerplate. See the discussion on mutability here, https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://cr.openjdk.java.net/~briangoetz/amber/datum.html, which I'll reproduce below for your convenience: > The stricture against mutability is more complex, because in theory one can imagine examples which do not fall afoul of the goals. However, mutability puts pressure on the alignment between the state and the API. For example, it is generally incorrect to base the semantics of equals() and hashCode() on mutable state; doing so creates risks that such elements could silently disappear from a HashSet or HashMap. So adding mutability to records also likely means we may want a different equality protocol from our state description; we may also want a different construction protocol (many domain objects are created with no-arg constructors and have their state modified with setters, or with a constructor that takes only the "primary key" fields.) Now, we've lost sight of the key distinguishing feature: that we can derive the key API elements from a single state description. (And, once we introduce mutability, we need to think about thread-safety, which is going to be difficult to reconcile with the goals of records.) > As much as it would be nice to automate away the boilerplate of mutable JavaBeans, one need only look at the many such attempts to do so (Lombok, Immutables, Joda Beans, etc), and look at how many "knobs" they have acquired over the years, to realize that an approach that is focused exclusively on boilerplate reduction for arbitrary code is guaranteed to merely create a new kind of boilerplate. These classes simply have too many degrees of freedom to be captured by a single simple description. > Nominal tuples with clearly defined semantics is something that can make our programs both more concise and more reliable for a lot of use cases -- but there are still use cases beyond the limits of what they can do for us. (That doesn't mean that there aren't things we can do for these classes too -- it just means that this feature will not be the delivery vehicle for them.) So, to be clear: records are not intended to replace JavaBeans, or other mutable aggregates -- and that's OK.
krzyk 7y ago
Bean compliant getters are horrendous, most newer libraries avoid them.

nobleach 7y ago

I'd equate Kotlin's data clases to Lombok's @data annotation.

doctor_eval 7y ago

Agreed, the declaration syntax is awful and the generated methods aren’t idiomatic. That saidC I don’t even understand the point of generating getters in this case. The fields could just be declared public final. Java’s obsession with wrapping fields in methods has never made sense to me.

erik_seaberg 7y ago
Scala lets you quietly replace a field with an accessor method, but Java does not. You'd have to change all consumer code to add laziness or test mocking/spying.
- doctor_eval 7y ago
  in my experience accessor methods are a particularly nasty kind of YAGNI. I'm not saying you never need to override a field to make it lazy, for example, but the cost of getters and setters has never, in my practical experience, outweighed the cost.
  - erik_seaberg 7y ago
    If they're generated and inlined away, what's the remaining cost?
    - doctor_eval 7y ago
      The cost is in typing effort, fluency, legibility and complexity. There is no Good reason to prefix every field access with get, and end it with (). It’s five more keys to type and makes the code more verbose. thing.getId() is longer and less readable than “thing.id”. Why does the compiler have to spend time inlining the call? Can you guarantee that it does? IMO the question shouldn’t be “what is the cost of this complexity?” The question should be, “what is the benefit?”. And in 20+ years of java dev, I just don’t see any benefit in accessor methods at all. We never wire up our components with JavaBeans introspection... so why do we keep this nonsense going?

pron 7y ago

You're confused because you don't understand what this feature is and compare it to things with different goals. https://openjdk.java.net/jeps/359 https://openjdk.java.net/jeps/359: > Records provide a compact syntax for declaring classes which are transparent holders for shallowly immutable data... While it is superficially tempting to treat records as primarily being about boilerplate reduction, we instead choose a more semantic goal: modeling data as data. (If the semantics are right, the boilerplate will take care of itself.) It should be easy, clear, and concise to declare shallowly-immutable, well-behaved nominal data aggregates... It is not a goal to declare "war on boilerplate"; in particular, it is not a goal to address the problems of mutable classes using the JavaBean naming conventions.

thu2111 7y ago
I think the point a lot of posters are getting at is, maybe reducing boilerplate for JavaBeans is a more useful goal, given the huge ecosystem of tools and code that assumes the JavaBean pattern. That's what Kotlin did and it's been very successful, so there's no fundamental reason why not. It's a philosophical objection of the form "mutability is bad", which feels somehow Haskellish and un-Java-like. What happened to being a blue collar language?
- pron 7y ago
  > so there's no fundamental reason why not That another language has done it does not mean there is no fundamental reason not to do it. A fundamental reason can be that its cost/benefit ratio isn't good enough. Other languages weigh language complexity less harshly than Java. > That's what Kotlin did and it's been very successful In what sense has it been "very successful"? That the small minority of people on the Java platform that have chosen to use Kotlin like this feature? Currently, there are still more people using Scala, does that mean that all Scala features have been even more successful? In any event, that would be a different feature, and it will be judged, and then perhaps adopted, separately. > It's a philosophical objection of the form "mutability is bad", which feels somehow Haskellish and un-Java-like. What happened to being a blue collar language? That's not the objection, and Java is still blue-collar. Records don't do that not because of some "anti mutation" sentiment but because records are about something else than reducing JavaBean boilerplate. See the discussion on mutability here, https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://cr.openjdk.java.net/~briangoetz/amber/datum.html, which I'll reproduce below for your convenience: > The stricture against mutability is more complex, because in theory one can imagine examples which do not fall afoul of the goals. However, mutability puts pressure on the alignment between the state and the API. For example, it is generally incorrect to base the semantics of equals() and hashCode() on mutable state; doing so creates risks that such elements could silently disappear from a HashSet or HashMap. So adding mutability to records also likely means we may want a different equality protocol from our state description; we may also want a different construction protocol (many domain objects are created with no-arg constructors and have their state modified with setters, or with a constructor that takes only the "primary key" fields.) Now, we've lost sight of the key distinguishing feature: that we can derive the key API elements from a single state description. (And, once we introduce mutability, we need to think about thread-safety, which is going to be difficult to reconcile with the goals of records.) > As much as it would be nice to automate away the boilerplate of mutable JavaBeans, one need only look at the many such attempts to do so (Lombok, Immutables, Joda Beans, etc), and look at how many "knobs" they have acquired over the years, to realize that an approach that is focused exclusively on boilerplate reduction for arbitrary code is guaranteed to merely create a new kind of boilerplate. These classes simply have too many degrees of freedom to be captured by a single simple description. > Nominal tuples with clearly defined semantics is something that can make our programs both more concise and more reliable for a lot of use cases -- but there are still use cases beyond the limits of what they can do for us. (That doesn't mean that there aren't things we can do for these classes too -- it just means that this feature will not be the delivery vehicle for them.) So, to be clear: records are not intended to replace JavaBeans, or other mutable aggregates -- and that's OK.

krzyk 7y ago

Bean compliant getters are horrendous, most newer libraries avoid them.