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

81–90 of 294 posts

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

#81

Post by shagie »

anonymoushn wrote: post #63
shagie wrote: post #41

Earlier quoted context omitted.

The first question is "through static analysis, can you guarantee that the structs do not leave the scope?" The second question to look at is "which JVM are you using?" Different JVMs may implement this differently. This isn't something that one can say about Java . It is something that one might be able to say about HotSpot, Zulu, or GraalVM.

It's a global array of structs, let's say.

If it's a global, it's very likely allocated on the heap.

The question of "what is the representation of the object on the heap?" then open.

However, the "this is global" complicates it.

This isn't a question for Java to answer. You would need to dig into the specifics of the particular VM that you are using and how it allocates such a structure along with what optimizations it has available.

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

#83

Post by swsieber »

slver wrote: post #29
valenterry wrote: post #6

> Actually, records are even better* than tuples. EP 395 says: > > Records can be thought of as nominal tuples. They are certainly not better, that's just a sad click-bait (the author even admits that). Sometimes nominal typing is better and sometimes structural typing is better. Forcing people to always use nominal types just ends in a lot of generic or long/meaningless names - one can already see this in Java.

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?

Restrict structural types to tuples only.

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

#84

Post by the_af »

AtNightWeCode wrote: post #73

Not sure why immutable data structures have surfaced as something important. Typically you never change fields so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change.

"Typically" this means you can never be sure, which is a problem.

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

#85

Post by swsieber »

slver wrote: post #37
whatshisface wrote: post #30

Earlier quoted context omitted.

In languages without property support, reflexively writing getters and setters is the only way to make it possible to go back later and add logic to getting and setting without changing the callsites. Is this a workaround for the combined shackles of mismanaged enterprise environments where changing callsites is impossible for some reason, and legacy language environments where you have to use Java for some reason? Y…

The real question is why is the convention getFoo() setFoo(foo) and not foo() and foo(foo).

It makes for easier searching in small code bases with stuff like grep instead of needing full language server / ide support.

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

#86

Post by barsonme »

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?

Android development. Kotlin is great, but Java is still a perfectly valid choice. In particular, if you don’t have dedicated Android developers Java can be a good choice because most people are at least somewhat familiar with it and won’t have to learn a new language to be productive. That said, I think anybody who understands Java should be able to understand Kotlin with minimal effort.

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

#87

Post by Bjartr »

im3w1l wrote: post #51
anonymoushn wrote: post #35

Earlier quoted context omitted.

Can you have an array of 1 million structs, not pointers to structs?

1 million is not a lot. I'd begin by asking myselves "can I afford to chase those pointers?", because maybe you can.

That's a good question to ask when faced with a problem that could be solved that way, but a real answer to the question would be useful too.

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

#88

Post by skinkestek »

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?

> Most devs I know avoid it like the plague, and only use it to maintain legacy codebases or get CS qualifications.

All the customers I have worked with since I became a consultant 4 years ago (and a couple of the best companies I worked with in the decade before) used Java or .Net. More specifically one of them was dotnet core and the rest are JVM.

And I'm happy with that.

Java and Maven means I can focus on the problem and not on all the crazy things people who think they are too clever to use Java do.

I mean I have seen a couple of Abstract Factories in Java, but I haven't seen anyone avoiding putting passwords in the source code by writing things like this:

  rot13()
That is stuff I have found in Python code by the one consultant who was to smart to use Java or .Net.

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

#89

Post by azth »

bob1029 wrote: post #79
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?

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

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

#90

Post by switch007 »

bob1029 wrote: post #79
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?

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?

Post reply on HN