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

251–260 of 294 posts

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

#251

Post by tadfisher »

_old_dude_ wrote: post #153
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) {} ... }

I don't see the point; you're not testing code that depends on Point, as it's local, so `x to y` (i.e. `Pair(x, y)`) would work just as well.

If there's a particular language feature records enable that Kotlin doesn't with ordinary data classes in this case, I'd love to see it.

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

#252

Post by crummy »

abductee_hg wrote: post #93

sorry -java .. better? what? why would anyone use java for anything? let me give an example: from a project a while(some years actually) ago i still have a license for a php-ide(zend). its in java. no chance in hell to get it working today. meanwhile, stuff i did 2003 still runs on windows out of the box, even in wine/osx. so again: why use java for anything? https://twitter.com/abductee_org/status/711966430133026816…

Isn't java famous for backwards compatibility?

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

#253

Post by valenterry »

snuxoll wrote: post #247
valenterry wrote: post #235

Earlier quoted context omitted.

Not only that, but they offer some other features that (to my knowledge) both records and kotlin's data classes don't offer. Which is control over accessibility. E.g. when you have a "NegativeNumber" type and you need to make sure the inner value is actually negative. Then just using having a check in the constructor isn't sufficient in the existence of copy methods (like kotlin) does it.

The copy methods that Kotlin generates construct a new instance of the class with the updated fields - so any validation done in the constructor would in fact be done again.

Yes, that's correct. But instead of catching the error at that point, you would probably rather want to disable these methods from the beginning so that someone cannot even make the mistake of using them and has to go through some custom defined method instead.

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

#254

Post by fnord77 »

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?

Magic beans. They were supposed to automagically populate inside a java UI (applet?).

seriously, I think the reason is so you could override the getter to do something else, like compute a value and return it... but in practice this almost never happens.

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

#255

Post by eyelidlessness »

RcouF1uZ4gsC wrote: post #3

Trying to read in Safari iOS but most of the article text seems to be missing.

I think it does a GC pause on every scroll. If you just scroll and wait a few seconds it renders. That said it got so frustrating I stopped reading, even though I was curious :(

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

#256

Post by lmm »

lolinder wrote: post #250
lmm wrote: post #244

Earlier quoted context omitted.

You can use Java collections in Scala just as you do in Kotlin, and in fact interop is easier in Scala since you can write typeclass instances for the Java types whereas there's no equivalent for that in Kotlin. The real difference is that more of the Kotlin ecosystem uses Java's fundamentally mutable collections compared to the Scala ecosystem, and using actually immutable collections in Kotlin is extremely difficul…

I write Kotlin all day and almost exclusively use immutable types. What difficulties with using them are are you referring to?

Kotlin doesn't have immutable collection types in the standard library (it lets you use a read-only interface but the collection is really still mutable and will be seen as such by any Java code), so if you want actually immutable collections you have to use non-standard collections, and since Kotlin doesn't have typeclasses or implicit conversions it's difficult to interoperate between any non-standard collection library and other Kotlin code.

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

#257

Post by lolinder »

lmm wrote: post #256
lolinder wrote: post #250

Earlier quoted context omitted.

I write Kotlin all day and almost exclusively use immutable types. What difficulties with using them are are you referring to?

Kotlin doesn't have immutable collection types in the standard library (it lets you use a read-only interface but the collection is really still mutable and will be seen as such by any Java code), so if you want actually immutable collections you have to use non-standard collections, and since Kotlin doesn't have typeclasses or implicit conversions it's difficult to interoperate between any non-standard collection li…

Ah, fair. I've never actually seen that become a problem, but I can see how it would be if I were doing more extensive Java interop.

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

#258

Post by didibus »

valenterry wrote: post #241
slver wrote: post #29

Earlier quoted context omitted.

I've been thinking about structural vs nominal. As you say, both have use cases. How would you combine both in one language so it's not confusing?

I'm not sure, but I think I would make a language based on structural typing only, including to allow a structural type to contain names. (Scala actually already has literal types that come close) Think about the following type-level (not runtime) representation for a structural type (tuple): (String -> Integer) And the following for a structural type with where each "member" has a name: (("name" -> String) -> ("age"…

OCaml does this I believe.

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

#259

Post by jillesvangurp »

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.

Exactly. Kotlin was actually explicitly designed to be like this and is directly competing with Java as a drop in replacement for it. Consider e.g. the seamless integration into Spring and Android, which both continue to support Java as well. Writing Android applications in Scala is a bit of an uphill battle (but I've heard of people attempting it). Writing Spring applications in Scala is possible in principle, I guess, but it's just not a thing that is very common or that is supported by Spring. Spring and Android have documentation with code samples in both Java and Kotlin, and extensive Kotlin specific stuff in the form of e.g. extension functions. At this point Kotlin is the preferred language for both even though they both maintain compatibility with Java as well and will for years to come.

Spring is about half the server side JVM ecosystem. Android represents a good chunk of frontend usage. Kotlin is a first class citizen for both; Scala just isn't. It has its own frameworks of course but they are kind of niche in comparison.

I think it's great that Java is slowly evolving to have features that other languages have. Kotlin supports Java's records as of this week's 1.5.0 release via an annotation. Meaning that if you have Java code that needs to interact with Kotlin code, you can write a data class that from the Java side looks like a record if you put the right annotation on it. It's a compatibility feature that's only relevant if you are planning to use or support Java. Another notable feature that landed with this week's release include sealed interfaces (it already had sealed classes). You can use both with data classes of course.

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

#260

Post by jillesvangurp »

valenterry wrote: post #235
mumblemumble wrote: post #110

Earlier quoted context omitted.

I think that case classes are roughly equivalent to Kotlin data classes for the purposes of this comparison. In particular, one of the extra features they offer is the ability to make fields mutable. Which, in some cases, may be useful, but also means that they aren't, strictly speaking, transparent carriers of immutable data .

Not only that, but they offer some other features that (to my knowledge) both records and kotlin's data classes don't offer. Which is control over accessibility. E.g. when you have a "NegativeNumber" type and you need to make sure the inner value is actually negative. Then just using having a check in the constructor isn't sufficient in the existence of copy methods (like kotlin) does it.

A good rule is that constructors MUST not do work. Writing constructors in Kotlin is possible but not that common. Data classes are typically initialized with just value assignments. Having support for default values also means that it largely removes the need for having multiple constructors (which is very common in Java).

If you need to do validation, there are very decent frameworks that you should use for both Java and Kotlin. We are using a thing called Konform currently. Very nice.

For non negative numbers, you can use the new unsigned numeric types they added in Kotlin with the last release: https://kotlinlang.org/docs/basic-types.html#unsigned-intege...

Post reply on HN