Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java's records, Lombok's data, and Kotlin's data classes

nipafx.dev

Post reply on HN
Print view View original

151–160 of 294 posts

Re: Java's records, Lombok's data, and Kotlin's data classes

#151

Post by jorblumesea »

grishka wrote: post #140

Curious question — why do people insist so much on fields being private and there being getters and setters, even when all that getters do is return the field and all that setters do is set it? What kind of problem does this arrangement solve? Why not just use public fields?

getters and setters prevent other objects from modifying internal properties in unexpected ways. Having that encapsulation and abstraction is important for maintainable code.

Also, getters and setters don't always modify individual values. Imagine a class where we have:

private val firstName private val lastName

fun returnFullName(): return firstName + lastName

Re: Java's records, Lombok's data, and Kotlin's data classes

#152

Post by commandlinefan »

t-writescode wrote: post #120
commandlinefan wrote: post #47

Earlier quoted context omitted.

> go back later and add logic to getting and setting Which, realistically, you're virtually never going to do - at least not often enough to justify the boilerplate and especially in the case of things like "records" which were probably auto-generated from a schema (with obligatory getters and setters) anyway. If you did , you'd end up confusing all of your callers who probably wrote client code presuming that what t…

This is true, until you're writing a library that's pulled from a repository and used in several projects. If you can't guarantee you're not going to break someone else's code by changing: foo.x to foo.getX(); then you should stick with properties. Now, for staying inside a single package, or a single compiled unit, then what you say is reasonable enough. I'd still prefer to write the getters and setters, though, esp…

It would be better if the default were to not write setters or getters for any properties by default, but instead to write a logical interface that properly encapsulates the properties. Unfortunately, that ship sailed a long time ago for Java.

Re: Java's records, Lombok's data, and Kotlin's data classes

#153

Post by _old_dude_ »

billyjobob wrote: post #14

Kotlin data classes can use Java records as their implementation if running on JVM, so it’s not like you have to choose one or the other. https://kotlinlang.org/docs/jvm-records.html#declare-records...

I wonder why, unlike a Java record, in Kotlin a data class annotated with @Record can not be local.

Being able to use local records is a useful feature in particular in unit tests.

  @Test
  void testPoints() {
     record Point(int x, int y) {}
     ...
  }

Re: Java's records, Lombok's data, and Kotlin's data classes

#154

Post by oftenwrong »

johnthuss wrote: post #4

One of the best things about Records is that they guide you to creating immutable data structures, which Lombok does not. This, along with the reduction of boilerplate, greatly reduces the cognitive load required to understand a lot of code.

The guidance is nice, but, unfortunately, Record components can still be mutable. It would be great if there was a way to have a stronger guarantee of immutability.

Re: Java's records, Lombok's data, and Kotlin's data classes

#155

Post by stickfigure »

cs-szazz wrote: post #31

I'm not sure what it's taking about for the "with" feature: https://nipafx.dev/java-record-semantics/#with-blocks In Kotlin data classes, it's already implemented (just called copy) https://kotlinlang.org/docs/data-classes.html#copying

It's also implemented nicely, today, with Lombok:

    @Value @With
    public class Pair {
        int left;
        int right;
    }

    final Pair rightIs3 = somePair.withRight(3);

Re: Java's records, Lombok's data, and Kotlin's data classes

#156

Post by slver »

AtNightWeCode wrote: post #150
slver wrote: post #123

Earlier quoted context omitted.

It takes two seconds in a hello world demo. It takes probably more in a millions of lines project.

Fields of an object should typically not change. But yes, I had to make a field of a class immutable some time ago. There was a bug and I could not read the code to figure out were the object was changed. Still, caused by bad code. Same object sent around pretty much everywhere.

So even you, the master of great code, wrote bad code. I guess immutability is worth something then.

Re: Java's records, Lombok's data, and Kotlin's data classes

#157

Post by brabel »

grishka wrote: post #140

Curious question — why do people insist so much on fields being private and there being getters and setters, even when all that getters do is return the field and all that setters do is set it? What kind of problem does this arrangement solve? Why not just use public fields?

I think I can answer that... it's all to do with a grand view that the Java original designers had about what objects should look like, in what became known as Java Beans. There's a spec[1] and everything.

They wanted to be able to write framework code that could introspect Java beans and expose them directly in a user interface, amongst other things, allowing users to modify them, create them, delete them and even compose them to create their own applications... they had even imagined there could be marketplaces where you could _buy_ Java beans to add to your program, or even to modify your other beans to give them extra power... getters and setters were part of that - they needed to know how to obtain and change the state of an Object, but how the Object internally handled such state changes were up to the Object itself (what we now call encapsulation)... this was similar to how Smalltalk worked and that was an inspiration for the Java beans specification... all this never really turned out the way they wanted, of course, but have a read of the Java beans spec to get a better idea of what they had in mind if you don't fully understand it yet.

With time, people forgot completely about Java beans, but for whatever reason, getters and setters sticked around to this day. Many Java developers today think Java beans are just classes with a bunch of getters/setters and never probably heard of PropertyChangeListener, VetoableChangeListener and the other parts of the Java beans spec (some of it lives on in Swing).

If you write Java today and just want to expose some data, yeah, just go with public fields if you can't use Java 16 records yet... if you ever need to change how you internally store information, just refactor that to a setter if you really must (it will never happen).

[1] https://www.oracle.com/java/technologies/javase/javabeans-sp...

Re: Java's records, Lombok's data, and Kotlin's data classes

#158

Post by krzyk »

adambatkin wrote: post #111
halfmatthalfcat wrote: post #23

Earlier quoted context omitted.

Scala is usually omitted for one reason or another when Kotlin is compared against Java as a better alternative, which is a shame.

Lombok and Kotlin are both much easier to integrate into existing Java applications and libraries than Scala.

Lombok is the problem not a solution (see https://github.com/projectlombok/lombok/issues/2681 regarding support for JDK 16 to understand why) and a ticking time bomb in every project that wants to move past JDK 15/16.

But why do you think Kotlin is easier to integrate than Scala? Both work on JVM.

Re: Java's records, Lombok's data, and Kotlin's data classes

#159

Post by skinkestek »

legerdemain wrote: post #149
grishka wrote: post #140

Curious question — why do people insist so much on fields being private and there being getters and setters, even when all that getters do is return the field and all that setters do is set it? What kind of problem does this arrangement solve? Why not just use public fields?

I had the same question -- why accessor methods instead of making the fields public, but final. If anything, it seems like a layer of indirection. The only answer that makes any sense is this one from Brian Goetz.[1] Namely, that it's a workaround to support mutable fields of otherwise immutable objects. To be honest, allowing you to override the methods on an immutable, auto-generated class to inject custom accessor…

> why accessor methods instead of making the fields public, but final.

The best explanation I have is that it is:

- a convention that seemed like a good idea for many people at the time, it even has a name: Javabeans

- it allows for a standard non magic way to add logic to be run when reading or updating fields

- in a time where source control tools and Java refactoring tools where not as developed as they are today it made sense to make getters and setters everywhere since changing from public fields to accessor methods after it were already in use was probably scary for large teams.

Re: Java's records, Lombok's data, and Kotlin's data classes

#160

Post by krzyk »

dlbucci wrote: post #113
bcrosby95 wrote: post #99

Earlier quoted context omitted.

It was included because changing data using records (copying it except changing the fields you need to change) is a shitty experience, so rather than showing the code you have to write, they showed you code you may or may not in the future be able to write.

Seems like an odd thing to mention. They are arguing that records are better than data classes, but part of their argument is "maybe, in the future, at some point, I don't know, it will be as easy to do this thing with records as it already is with data classes, we'll only need to add new syntax and a new keyword to the language".

Who is they?

You mean the article author? Yes, it was odd that he mentioned that, but besides that not a bad feature to have (but a bit wordy for my taste, I hope they'll change that).

Post reply on HN