Live data from Hacker News

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

nipafx.dev

191–200 of 294 posts

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

#191
post #184

Earlier quoted context omitted.

That's a theory not happening in practice. In practice Java programs are slow and memory-hungry because of those issues when some people think that it's cheap to create small objects or that escape analysis will solve their issues without verifying that it works for their case.

Java isn’t perfect. But you underestimate the amount of software written in it. Or even things like Python and JS which are a lot more basic but have similar elements in regards to their memory model. What do you use?

I work as Java developer for the last 10 years, I perfectly understand the amount of software and other things.

I don't know much about Python and JS, but I do know that they're not using immutable model, everything is mutable in Python and in JS, so I'm not sure what's your point. The only immutable language I'm aware of is Haskell which is not used widely. Just because JVM is faster than Python or V8 does not mean that it's OK to slow it down with immutables.

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

#192

This might qualify as low-grade threadjacking, so I apologize if this is off topic, but who's actually using Java these days? Most devs I know avoid it like the plague, and only use it to maintain legacy codebases or get CS qualifications. Are there any real advantages to using Java in 2021, besides it's mature community/ecosystem/tooling?

Java? Not so much. JVM? Absolutely. The ecosystem, stability and performance is unmatched.

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

#193

Earlier quoted context omitted.

Instead of changing few bytes, now I have to copy hundreds of bytes around and add more stuff for GC to collect. Well, they have to obey Wirth's law, I guess.

You write java and worry about bytes copied?

Yes, I do. Java could be quite fast if you won't slow it down on purpose.

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

#194

This might qualify as low-grade threadjacking, so I apologize if this is off topic, but who's actually using Java these days? Most devs I know avoid it like the plague, and only use it to maintain legacy codebases or get CS qualifications. Are there any real advantages to using Java in 2021, besides it's mature community/ecosystem/tooling?

Try this list out:

https://projects.apache.org/projects.html?language#Java

There's a LOT of real interest in Java in many many industries. Saying this like "Most devs I know" just really is more of an observation of your local circle.

Big data, Finance, Government

Just to name three really big industries that are dominated by Java.

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

#195

Earlier quoted context omitted.

> except the problem of too many features Scala is a pretty simple, concise and coherent language though. Never understood why people deem it has too many features, I write it professionally and never felt so. At least comparing it to C, C++, Python. Java may be more simple, but you have tons of features added with metaprogramming via dozens of annotations generating lots and lots of boilerplate, Lombok and Spring ar…

> Never understood why people deem it has too many features I'll start with one (key)word: `implicit` I agree with your distaste for metaprogramming though.

You can use Scala without introducing implicits and even if you have to interopt with a library that does require them, it's quite easy to learn how to use them. It's also easy to abuse them but then that's not really Scala's problem.

They are changing implicits in Scala 3 though with the "given" keyword which is more ergonomic.

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

#196

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...

This is great news! I was also kind of surprised to see the article talking about algebraic data types... table stakes for ADTs is sum types and I have missed them considerably in the Java ecosystem. Kotlin has something like them with sealed classes, although I'm a newcomer to the Kotlin and Spring Boot ecosystem so I don't see explicitly how I make some simple case like JSON {"type": "left", "abc": 123} {"type": "r…

In traditional Java, you're probably using Jackson for your JSON. You can achieve those sorts of results by specifying the classes and type tags in annotations on an abstract Either class to use Jackson's polymorphic serialization feature.

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

#197

I believe the article focuses too much on "perceived/future" benefits of records, while ignoring the actual benefits that Lombok & Kotlin data classes provide today. For example, article does not mention lombok @Builder and Kotlin `copy` when talking about boilerplate. Boilerplate is not just about application code, it's also about test code! We have dozens of entities, and when unit testing them – always having to c…

yes, java records are part of jdk14, many places are still stuck with jdk8 or jdk11, hoewever everyone can use lombok (they didn't mention that detail in the article)

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

#198

Earlier quoted context omitted.

This protects you from changes to the internal representation of state in the future. Direct field access totally blows away encapsulation.

So, uh, do a usage search before changing stuff? You'll have to, anyway.

That works if your class is never used outside your own organization, but the API of published code needs to be changed more gracefully using semver.

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

#199
post #156

Earlier quoted context omitted.

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

I did not write the original solution...

Precisely: you did not write the original solution, which is where immutability shines. It's a code comprehension tool; it gives you guarantees about code you didn't write. That's a huge boon!

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

#200
post #13

Using Dark Reader extension for Chrome, all of the sample code text goes to the same color as the background so I thought I was scrolling over huge chunks of blank space.

I was surprised to encounter this as well in Firefox using Dark Mode. I'm still not 100% sure what's going on, because it's rather odd, but if I inspect the page, and add a: .language-java { opacity: 0.99999 } All content instantly renders. Interestingly: .language-java { opacity: 1 } or .language-java { opacity: 0.99999999 } /* probably same as 1 */ Blanks out the content again. Seems rather odd behaviour to me so d…

Kay. Day got a bit more quiet. I vaguely remembered running into this weirdness before. It's 'cause apparently opacity creates a new stacking context. Doing z-index:1;position: relative; does same thing. The rule that seems to be breaking everything is the one that forces a default opaque background on everything with dark text. For it to break this, there must be overlapping content, but haven't found it yet. But enough to know what was going on..
Post reply on HN