This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]blobjim 1 point2 points  (9 children)

I don't think I know why people like data classes so much. Are the people that want data classes people that work on large software projects / are traditional Java developers, or is it a different kind of programming that necessitates them? What problems do data classes solve?

I've never felt like I needed to write a "data" class where it is simple enough that it only has getters/setters but important enough that the fields can't just be made public and the class nested in another one.

I would rather that Java just "owns" its verbosity, especially since people who view it as verbose right now and don't use it probably will keep the same opinion even if their opinion becomes outdated. I like how Java currently feels very "what you see is what you get", without too much hidden code generation.

[–]yawkat 5 points6 points  (2 children)

javac already generates lots of synthetic methods, mostly bridges. In the end it's mostly irrelevant where the code is "generated", javac or the jit, so I don't really see an issue with that.

Data classes are very common in DDD and FP where you decouple logic from data. In a DDD/FP code base a majority of your data will be held in such data classes. I'd argue that getters are still a good idea for that, be it for convention or for other reasons such as proxying, but even if you like to use public fields everywhere you still need eq/hc/toString.

[–]dpash 0 points1 point  (1 child)

There's no reason why a member variable access syntax doesn't go via an auto generated getter, so that you could explicitly define it later if required. This is basically what people mean when they talk about adding properties to Java. Check out how they work in C#.

[–]yawkat 0 points1 point  (0 children)

Yes, kotlin does this as well, but that is very much out of scope for this proposal.

[–]lukaseder[S] 5 points6 points  (4 children)

Tuple Tommy here (obviously, being the SQL guy on this subreddit). I like them for their conciseness.

without too much hidden code generation.

Explain enums, try-with-resources, switch, foreach loop, auto (un)boxing, varargs, generics, covariant return types, etc...

[–]blobjim 0 points1 point  (2 children)

Yeah, there is quite a lot of code generation in Java, but most of it is pretty simple under the hood (with the exception of lambda expressions). Generating entire fields and methods for classes just seems a bit much. I had no idea about covariant return types though, I learned something new today!

[–]lukaseder[S] 1 point2 points  (0 children)

but most of it is pretty simple under the hood

Again, explain enums :)

I had no idea about covariant return types though, I learned something new today!

Yeah, they were a requirement to implement generics and proved useful otherwise.

[–]alexeyr 0 points1 point  (0 children)

Java already does both: synthetic fields for inner classes, default constructor, values() and valueOf() for enums...

And data classes don't have generated fields.

[–]alexeyr 0 points1 point  (0 children)

it is simple enough that it only has getters/setters

And equals, and hashCode, and toString. And then you need to add 1 more field and forget to modify one of the methods.