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

131–140 of 294 posts

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

#131

Post by slver »

marcosdumay wrote: post #94
slver wrote: post #36

Earlier quoted context omitted.

get()/set() is the same as a public property, until you change the implementation, while maintaining interface compatibility, which is the point. In C# you'd have a point, they have parametric properties and readonly properties. So you'd favor just declaring public properties. But this is why context matters. And OO design principles also depend on this context.

> until you change the implementation, while maintaining interface compatibility, which is the point How many times have you seen that done on the real world? And how many times have you seen that done, and it not creating a lot of bugs because of the behavior change without interface changes? Personally, I've seen the first one more than zero times. Not the second. Every single time somebody decided to mess with a s…

The behavior doesn’t change. The implementation does. Those are orthogonal.

And yes I see it every day. The collection interfaces in Java have countless swappable implementations. Those are basically getters and setters on a vector.

I also had to change entity storage to columnar for a project. Did that. Never had to change a line of code outside the entities.

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

#132

Post by Someone »

shagie wrote: post #26
jgrant27 wrote: post #5

They are still classes, still live on the heap and still need to be garbage collected. Compare with value types that live on the stack in other languages such as Swift, Go and Julia.

The heap is an implementation detail. With escape analysis, the compiler can allocate the data on the heap, stack, or even stick it in registers. https://www.beyondjava.net/escape-analysis-java https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacemen... https://www.javaadvent.com/2020/12/seeing-escape-analysis-wo...

Java compilers are getting more and more advanced, but I don’t think they will ever become the magical “sufficiently advanced compiler” that produces code that’s as good as humans _could_ (but often won’t, because of time constraints) write.

I don’t think anybody fully disagrees with that. At least, I haven’t heard people claim int can be removed from the language because a good compiler can produce identical code for Integers.

And yes, that can also apply to instances that do escape. A sufficiently advanced compiler could in some/many cases figure out that an array of Integer can be compiled down to an array of int. However, it’s way easier for a compiler to check a programmer’s claim “we won’t use features of Integer on these ints” than to deduce that code won’t, so a little bit of programmer effort allows for a simpler compiler that can produce faster code.

For me, records and (future) value types are examples of such “little bits of programmer effort”

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

#133

Post by jeroenhd »

smoldesu wrote: post #68

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?

The existence of Spring Boot makes Java a very good choice for loads of dev shops. Good balance between features, ease of use, performance and security, not difficult to pick up, and very well documented.

In my personal opinion, C# is a superior language these days now that most of .NET has been ported into dotnet core. However, that's only been the case for a few years and before that, Java was in a league of its own with its excellent library ecosystem and omnipresent JVMs.

Java is a very boring language. Features get added slowly compared to other languages, improvements are generally quite gradual and new concepts only rarely ever get added to the language. This will drive away many hot startups and fresh CS graduates because they want to use the latest technologies in brave new ways and explore the ecosystem.

For general businesses, boring is good. Boring is predictable, understandable and maintainable. Java is not the fastest language to write software in, but it's fast enough not to warrant teaching your staff a new language for. It's missing many features that are standard in other languages, but there's third party libraries to make up for that.

In my mind, languages like Rust and Zig are the Teslas of the software world, exciting, new, full of flaws that need to be ironed out but ready to storm the general market one day soon. Go and Kotlin are the shiny new SUVs, impressive and high quality, but packed with weird design choices and opinions on how to use them. Java and C# are the old van the company has owned for 20 years. Nothing impressive, but reliable, comfortable, predictable, and with quirks that everyone has been learning for years now. Most businesses don't need a Cybertruck, they need to get around, and what businesses already have is good enough for the next while.

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

#134

Post by vbezhenar »

kaba0 wrote: post #59
vbezhenar wrote: post #52

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.

Or you know, the JIT will trivially optimize away the old class if it is reassigned to the same variable, as you would use it inside a loop. How do you think the litany of FP languages work? Like Haskell, Scala, Clojure?

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.

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

#135

Post by bob1029 »

switch007 wrote: post #90
bob1029 wrote: post #79

Earlier quoted context omitted.

If C# didn't exist, we would certainly be a Java shop. Not only because of the ecosystem & tooling, but also because it is a language that has historically proven its ability to model incredibly complex business domains as well as support mission critical workloads without falling over on itself.

“historically proven its ability to model incredibly complex business domains” You surely can’t be talking about its type system?

I certainly prefer the type system of C# over Java, but the latest things I've seen come out of the Java camp give me confidence that I could port most of the same ideas across the way without too much friction if need be.

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

#136

Post by AtNightWeCode »

slver wrote: post #121
AtNightWeCode wrote: post #114

Earlier quoted context omitted.

Good code don't have this issue.

Good code doesn’t have concepts like “typically doesn’t mutate”. It’s either mutable or immutable.

The standard way to do it is to mutate clones as always in Java. Typically by use of libraries that provide this. You really need very bad code to have to think about if objects are mutable.

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

#137

Post by bob1029 »

azth wrote: post #89
bob1029 wrote: post #79

Earlier quoted context omitted.

If C# didn't exist, we would certainly be a Java shop. Not only because of the ecosystem & tooling, but also because it is a language that has historically proven its ability to model incredibly complex business domains as well as support mission critical workloads without falling over on itself.

How's your experience with C#/.NET been? Does it have an analogous offering to Java's JFR[0] for always-on profiling? [0] https://blogs.oracle.com/javamagazine/java-flight-recorder-a...

I am not familiar with the scope of JFR, but there have been some very recent movements around profiling in C#/.NET:

https://devblogs.microsoft.com/dotnet/introducing-dotnet-mon...

https://devblogs.microsoft.com/dotnet/whats-new-in-dotnet-mo...

My experience overall with the C# ecosystem has been fantastic. We started out on .NET Framework 4.x back in 2014-2015, and today are now talking about moving to .NET 6 and rewriting our native apps to use MAUI as November grows closer. A lot of the same code we had back in 2015 is still running today with zero modifications.

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

#138

Post by switch007 »

bob1029 wrote: post #135
switch007 wrote: post #90

Earlier quoted context omitted.

“historically proven its ability to model incredibly complex business domains” You surely can’t be talking about its type system?

I certainly prefer the type system of C# over Java, but the latest things I've seen come out of the Java camp give me confidence that I could port most of the same ideas across the way without too much friction if need be.

You said historically, by which I assumed you meant older Java versions, not later ones.

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

#139

Post by slver »

AtNightWeCode wrote: post #136
slver wrote: post #121

Earlier quoted context omitted.

Good code doesn’t have concepts like “typically doesn’t mutate”. It’s either mutable or immutable.

The standard way to do it is to mutate clones as always in Java. Typically by use of libraries that provide this. You really need very bad code to have to think about if objects are mutable.

Apparently you don’t know most immutable structures are optimized for modified cloning in ways mutables aren’t.

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

#140

Post by grishka »

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?
Post reply on HN