First, let's separate Kotlin's adoption on Android and on the Java platform. Android has never been Java, it is now very different from Java, and while adoption

First, let's separate Kotlin's adoption on Android and on the Java platform. Android has never been Java, it is now very different from Java, and while adoption of Kotlin for Android is high (~60% according to Google), adoption of Kotlin for Java is quite low (less than 3% according to Indeed.com). Second, records and Kotlin's data classes are not the same feature and they don't have the same goals. Records are primarily about adding named product types, or named tuples, not about reducing boilerplate for mutable objects, while Kotlin's data classes allow you to add properties that are excluded from equals, which is, IMO surprising, and in any event means that data classes do not serve records' goals. That's also why there is no deviation from a naming pattern, because this concept didn't exist in Java before. Records are not beans, and there is no need for them to follow a naming pattern of something they're not; even if there is some benefit in doing so nonetheless, there is also a disadvantage. It's perfectly OK to disagree with Java's designers and think that Java should have added Kotlin-style data classes instead of records and while neither satisfies the others' goals, you think that the former's goals are more important, but that is just a matter of taste. Like Boilerplate Billy, you can think that reducing boilerplate in itself is a big benefit. But I don't think you can point at any evidence that shows the decision to implement records is wrong. So yes, Java could have added a different feature, but it chose not to.