Consider using Java Records

[zkaoudi]

After updating to a later version of Java, we may be able to use the Java Record type instead our custom ones allowing for seamless integration with other libraries that may use it.

[CarloMariaProietti]

Hi, I would like to work on the issue. I was wondering whether public classes are also in target, making them records could brake existing user code. An example on class Tuple2.java: tuple2_instance.field0 would not compile.

[zkaoudi]

Thank you @CarloMariaProietti. I think we were leaning towards not implementing this. I do not recall the reason now. @juripetersen maybe you do?

[CarloMariaProietti]

Thank you @CarloMariaProietti. I think we were leaning towards not implementing this. I do not recall the reason now. @juripetersen maybe you do?

Is this about each class or only public classes?

[AjayBoddeda4]

Hi, I am Ajay Boddeda, a GSoC 2026 applicant working on the DataFrames API proposal.
This discussion is very relevant to my proposal. The Row and Schema classes I am planning to implement for the DataFrame API would be completely NEW classes — not existing ones. So using Java Records for them would not break any existing user code at all.
For example, a Schema record could look like:
record Schema(List columnNames, List<Class<?>> columnTypes) {}
And a Row record could be:
record Row(Schema schema, List values) {}
Since these are new additions rather than modifications to existing classes, Java Records seem like a perfect fit here. Would this direction make sense for the DataFrame API classes?