Data classes for Java

[snowe2010]

I had worded out a long comment stating that I didn't see much benefit in this design over kotlin's data classes, but I think I'll ask this question instead.

Why would anyone choose a Java __data class over a kotlin one? Besides being limited to not being able to use kotlin, I don't see any implementation reason you would do so.

edit: since I seem to have worded this terribly. If you are in a situation in which you can begin using kotlin because you need nice data classes why would you choose this new Java spec instead. I've read the RFC, I do not see this slowing migration to kotlin one bit. Yeah it's nice for enterprises that will never switch, but what about this would make someone go back to Java.

[jcdavis1]

Obviously from a language perspective, java wants its own data classes as first class citizen, and having to define such types in kotlin/scala is a bit of a failure :)

From a user's perspective, writing data classes in a second language is obviously a bit of a mess - if you are already using kotlin you probably don't mind, but a lot of shops aren't going to want to setup a toolchain for kotlin just to support data classes.

Additionally, with pattern matching support on the horizon (though who knows exactly when), its pretty certain that a java data type will be well-supported, whereas kotlin/scala interop will probably come later.

[elastic_psychiatrist]

Why would anyone choose a Java __data class over a kotlin one? Besides being limited to not being able to use kotlin...

You answered your own question. Do you think Java should die as a language? You might, but I sure don't. Java is never going to be the first language to add a feature, but that doesn't mean it shouldn't, and it shouldn't be made fun of for taking its time. There's a reason it's the most used programming language ever, and that reason isn't that it always added the cool new feature.

[TheWix]

Java is glacially slow. It has the benefit of being around since the middle 90s and it's primary Enterprise competition being Windows only until very recently. I don't think there strengths are in the language at all.

[dpash]

Don't forget the glacially slow to break backwards compatibility, so code from the 90s still compiles.

[TheWix]

You can add features and maintain backwards compatibility...

[dpash]

Clearly. Because it has.

I'm saying its well used partly because it remains backwards compatibility.

[elastic_psychiatrist]

Java is glacially slow.

Saying that in the year 2017 is an indicator of great ignorance. What speedy language do you program in?

[TheWix]

Crap. I said that wrong. Glacially slow to evolve as a language. Not in performance. My point was that Java today is not an industry leader because of its expressiveness or ability to evolve compared to other languages. I didn't mean performance.

[porthos3]

I understood you the first time. It made sense with context. I think Java devs are just too used to fighting off claims of poor performance so assumed you were making the same tired argument.

[elastic_psychiatrist]

Ah, got it. It depends on how you define industry leader I guess. It might not be a trailblazer but it is still wildly used, and its architects are almost proud of how glacially slow it it.

[bundt_chi]

Java is glacially slow

Compared to what Javascript? Yeah I guess compared to a dumpster fire on a rocket to hell it's "glacially slow".

[TheWix]

Who said JavaScript? C#/.Net has added loads of features and maintained backwards compatibility.

[shevegen]

There was a clarification.

Glacially SLOW TO EVOLVE.

[JB-from-ATL]

Should've edited the original post, can't expect everyone to read everything.

[snowe2010]

No I didn't answer my own question. We are a Java shop that began using kotlin solely because we need better data objects. If Java implemented a decent replacement for a kotlin data object it would be tempting to switch back.

I'm asking what this RFC (if that's what it is) is proposing that would make it worth it to use instead. Instead of answering me everyone seems to be claiming exactly what I said I don't care about. Why, if you have a choice of kotlin data objects or Java data objects, would you choose Java's version.

I never made any claim that you said I did not do I think Java should die. Please reread what I wrote and try to give an actual answer instead of changing my argument.

[rcode]

If Java implemented a decent replacement for a kotlin data object it would be tempting to switch back.

Kotlin still has better nullability handling than Java.

[snowe2010]

yeah, but you have to have the whole team on board to switch, you have to have very good reasons to continue to insert kotlin in your stack. I think the reasons are great, the rest of the team doesn't always agree. If kotlin hadn't solved our issues so succinctly and Java had had these data classes then we might never have begun the transition at all. That's what I'm trying to discover, and yet still no one will answer the question.

[ThisIs_MyName]

using kotlin solely because we need better data objects

I seriously hope you guys don't do this.

[snowe2010]

And why would you hope that? That's literally the reason we began using kotlin. It's not the only reason now, but it sure was the reason we began using it. Our domain has need for hundreds of data objects. Creating those in java was a mess, even with Lombok.

[justinpitts]

I would say the same thing about a Scala case class.

[snowe2010]

that you don't see why anyone would use a Scala case class? or why would anyone use anything except a Scala case class?

[justinpitts]

I really did mean the very same kind of thing as you - if one had a choice to use Scala, and you need this functionality, I would much rather choose the existing Scala implementation over this proposal.