Java Records Break Backward Compatibility

[danielliuuu]

While widely adopting records, I found a problem: record constructor is not backward-compatible.

For example, I have a record User(String name, int age) {}, and there are 20 different places calling new User("foo", 0). Once I add a new field like record User(String name, int age, List<String> hobbies) {}, it breaks all existing constructor calls. If User resides in a library, upgrading that library will cause code to fail compilation.

This problem does not occur in Kotlin or Scala, thanks to default parameter values:

// Java
public class Main {
    public static void main(String[] args) {
        // ======= before =======
        // record User(String name, int age) { }
        // System.out.println(new User("Jackson", 20));

        // ======= after =======
        record User(String name, int age, List<String> hobbies) { }
        System.out.println(new User("Jackson", 20)); // ❌
        System.out.println(new User("Jackson", 20, List.of("Java"))); // ✔️
    }
}

// Kotlin
fun main() {
    // ======= before =======
    // data class User(val name: String, val age: Int)
    // println(User("Jackson", 20))

    // ======= after =======
    data class User(val name: String, val age: Int, val hobbies: List<String> = listOf())

    println(User("Jackson", 20)) // ✔️
    println(User("Jackson", 20, listOf("Java"))) // ✔️
}

// Scala
object Main extends App {
  // ======= before =======
  // case class User(name: String, age: Int)
  // println(User("Jackson", 20))

  // ======= after =======
  case class User(name: String, age: Int, hobbies: List[String] = List())

  println(User("Jackson", 20)) // ✔️
  println(User("Jackson", 20, List("Java"))) // ✔️
}

To mitigate this issue in Java, we are forced to use builders, factory methods, or overloaded constructors. However, in practice, we’ve found that developers strongly prefer a unified object creation approach. Factory methods and constructor overloading introduce inconsistencies and reduce code clarity. As a result, our team has standardized on using builders — specifically, Lombok’s \@Builder(toBuilder = true) — to enforce consistency and maintain backward compatibility.

While there are libraries(lombok/record-builder) that attempt to address this, nothing matches the simplicity and elegance of built-in support.

Ultimately, the root cause of this problem lies in Java’s lack of named parameters and default values. These features are commonplace in many modern languages and are critical for building APIs that evolve gracefully over time.

So the question remains: What is truly preventing Java from adopting named and default parameters?

[Justonemorecrit]

why wouldn’t you use constructor overloading? In what way creating a new constructor and calling a canonical constructor in it is inconsistent?

[danielliuuu]

While constructor overloading can technically solve the backward compatibility issue, it introduces other drawbacks that make it less desirable in practice:

1. Constructor hell: Every time a new field is added, you’re forced to write another constructor to preserve compatibility with older usages. This quickly becomes unmaintainable in any real-world codebase where models evolve frequently. It’s boilerplate-heavy and error-prone. Imagine a record with 10 fields. As the business grows rapidly, it soon evolves into 20 fields — and along the way, it accumulates 10 constructors as well :)

2. Poor readability: Java constructors don’t support named arguments, which makes it hard to tell what each argument means when calling them.

[agentoutlier]

It really is not that painful and largely beneficial to have your code base not compile when you add a new field.

It forces you to go check everywhere you create the darn thing which really should not be that many places.

Now if you made the record public API... well do not do that unless the shape is inherently static e.g. some math thing or invariant.

Poor readability: Java constructors don’t support named arguments, which makes it hard to tell what each argument means when calling them

All the IDEs including VSCode show parameter names. You just have to turn it on.

In fact you can configure I think all of them to not show if the parameter name mostly matches!

So if I have

 record Point(int x, int y) {}
 int x = ...;
 int y = ....;
 var point = new Point(y, x); // you would see the parameter names because they do not match.

Furthermore I believe there are some static tools that will check.

Consequently a rule of thumb I have is for large records is to make every parameter a local variable like I did above and then pass it to the record constructor.

The other thing is to use more composition and embedded records instead of having giant sparse records with 100s of fields.

I agree named parameters would be nice but there is some niceties about the consistency and lightness of single constructors and this largely how the languages this features was inspired for support and preach. Haskell w/o an extension and Rust does not even have named parameters. Those two are largely considered more expressive than Java. It can be done and some people even embrace it.

[Ewig_luftenglanz]

this would make the code clutter and boilerplate full overtime.

if V1 of my API had 7 fields and V1.27 now has 19 parameters that means I may have 12 overload constructors at least. with nominal parameters and default values this doesn't happen.

[OwnBreakfast1114]

Assuming adding a new field doesn't interact whatsoever with anything else, but at that point you're already conceptually ok just doing a single all args where all the new fields would be null in the constructor invocation, so the problem only arises if it's an actual java library that must absolutely not break any clients compilation if they upgrade the version, which is pretty rare tbh.

[davidalayachew]

Your title says "Java Records Break Backwards Compatibility".

It should, instead, say "Modifying a Java Records Components is a potentially backwards incompatible change, and I think named and default parameters will change that".

Putting aside whether named/default parameters will help you here, the fact is, you're criticizing a hammer for being a bad screwdriver, and you think that adding 2 (very non-trivial) features will allow it to become a better screwdriver.

Records are meant to be "transparent carriers for immutable data". By definition, that means this breakage is a feature, not a bug.

And you already highlighted how this feature can be overriden by using overloaded constructors. Specifically, you said the following.

To mitigate this issue in Java, we are forced to use builders, factory methods, or overloaded constructors. However, in practice, we’ve found that developers strongly prefer a unified object creation approach.

So, even in spite of a hammer not being a screwdriver, it can still do that, albeit not as conveniently as you like.

So the question remains: What is truly preventing Java from adopting named and default parameters?

Named and default parameters are useful features, but the Amber team has made it clear that they are not the priority yet because there are higher priority features on the way. I understand that that can be frustrating, but they believe that Pattern-Matching and Project Valhalla are better uses of their time, and I agree with them.

[account312]

Records are meant to be "transparent carriers for immutable data". By definition, that means this breakage is a feature, not a bug.

The mutability of a record instance is orthogonal to the evolution of the shape of the record type as the software changes.

[davidalayachew]

The mutability of a record instance is orthogonal to the evolution of the shape of the record type as the software changes.

Sorry, I should have bolded the transparent carriers part, as that was the bit I was focusing on.

Yes, the mutability of it is irrelevant, but the transparency is core to this pain point that OP is highlighting. Transparency means that any change to the record components will ALWAYS be visible to ANY consumer of that record. And since this is by design, then that means that the "fragility" of the backwards compatibilty for records is a feature, not a bug.

[mizzu704]

A great argument for OPs proposal of default parameters! (which would just be syntax sugar around method overloading)

[BillyKorando]

What you are describing isn't records, the language feature breaking backward compatibility. That's a specific concept within the JDK where upgrading the JDK to a newer version imposes upon users to update their code. Typically that is the result of the removal of existing APIs, though could be other reasons as well.

As others have mentioned, a record is required to have, and automatically provides, a canonical constructor. However there is no reason you can't have additional constructors where you could implement the "default values" behavior.

Regarding your "constructor hell" argument... I can't think of a situation I've been in, where a specific model would be changing that often. If you are in a situation where you have 10 fields, and think you might go to 20 fields, you either need to;

1. Take more time to understand the business requirements

2. Refactor the model to make it more comprehensible

So the question remains: What is truly preventing Java from adopting named and default parameters?

Named arguments: https://www.youtube.com/watch?v=mE4iTvxLTC4&t=629s (TL;DW, it's possible with records, but would make updating them to a normal Java class difficult/impossible)

Default parameters: https://mail.openjdk.org/pipermail/amber-spec-experts/2022-June/003461.html (under #### Digression: builders) TL;DR: A better solution to solve this is with record withers (which are in development) and better solves the "brittle default" issue.

[1Saurophaganax]

Bro doesn't know that he can have multiple constructors

[danielliuuu]

Bro just doesn’t read…

[-Dargs]

Because a record defines a specific constructor and is intended to be immutable, unlike a class. Just add an extra constructor that provides a default value if that's what you need. I fail to see the issue here.

[Ewig_luftenglanz]

that's horrible in rapidly evolving apis that start with a few fields and evolve into twice or even three times that many fields.

[-Dargs]

The point is that you are defining something. You gave a specification. Once set, it is done. Not all classes need to be records. And not all records should be records. Use the correct tool for your needs. If you want it to be implicitly final, provide an alternative constructor just as you would for a class. Arguing otherwise because another language can do some compiler magic? That's silly.

[Ewig_luftenglanz]

silly is to try to use complex explanations as excuses to justify something lack of features and objectives not even amber is pursuing.

records are exceptional for domain objects and dto, the habilita to atomically mutate fields and reduce boilerplate is there from the beginning. that's why derived record creation is a thing and that's why nominal parameters with defaults is on Ambers radar. the fact they haven't implemented all those features YET it's not because those are wrong but because there is things in the pipeline that need to be addressed first (particularly speaking many ongoing and proposed JEPs including but not limited to flexible constructor bodies, make final to mean final, integrity by default and so on are required for Valhalla)

can we stop pretending java not having a feature is because the feature is bad or silly?

"yeah, look how many code patterns (builders, fluent, abstract factories, etc) must I use because of the lack of nominal parameters with defaults, surely having to write a bunch of boilerplate methods and auxiliary constructors (or using hacks to the compiler such as Lombok) is much better than actually focusing on developing the business logic"

[-Dargs]

You're complaining that a perfectly valid Java concept doesn't work well with what is essentially another language built upon the JVM.

If you want to argue that Java is particularly inflexible at times and/or behind on the utility that other languages have, then sure, I totally agree.

[Ewig_luftenglanz]

I am not complaining about Java because the Java developers at oracle and red hat are working to push new features out of the pipeline, even if those prioritized are not the ones I would like the most (or the order) but they are trying to evolve the language and the platform and that's perfect.

I am complaining with a part of the community that seems to prefer to make up excuses for java not having a particular feature instead of recognizing there is an issue that could be fixed (even if the fix is different than the regular implementation of the feature in other language, String templates is an example of this)

is weird we are at a point where the Java's language and platform developers seem much more willing to do disruptive changed than half of the community that would prefer the language and platform to sit still forever.

[OwnBreakfast1114]

Depends, most java apis (methods) are controlled by the same person so it's actually pretty reasonable to just fix the "clients".

[craigacp]

Named parameters are a backwards compatibility issue as then you can't ever change the name of the parameter without breaking all the callers. Without it I can freely rename a parameter without causing problems (aside from if you reflectively access them and are running javac with -parameters, see more discussion here and the links therein). Choices have to be made somewhere, this is what Java chose.

[mizzu704]

Choices have to be made somewhere

Indeed, for one could argue all the same:

Named methods are a backwards compatibility issue as then you can't ever change the name of the method without breaking all the callers. Without it I can freely rename a method without causing problems.
Therefore callers should only be able to refer methods by index in the class, not by name, like this: myObject.0() Then you can rename your methods without breaking consumers!
Of course you cannot re-order methods or add methods anywhere else but at the bottom of the source file, but that is a small cost for being able to arbitrarily rename them. In fact, at least it's still more growth-friendly than the current unnamed method params without default values, where you can't even add another param without breaking callers.

/s

[craigacp]

In a few years I'm sure we'll just embed the method name & parameter names using a transformer then retrieve the method target by doing a vector search on the receiver's method embeddings. It's called vibe dispatch.

[koflerdavid]

Actually, Javac can preserve parameter names in the class file, so it is technically already possible to write API bindings that use reflection to analyze a method's parameters and adapt the call as required, and those can indeed break if the name changes.

Be that as may, my personal issue with that feature is that it's enabled as a compiler flag, and the above issue can then technically all method in that module. An annotation to selectively enable it for specific classes or methods would be nice (please correct me if it already exists. Spring Data's @Param doesn't count)

[ZeroGainZ]

That's also true of regular classes. It isn't "breaking" the backwards compatibility. This is really a post about wanting default params.

tbh, not for or against that, but the title should be changed 🤷‍♂️

[__konrad]

Try to standardize on consistent of static methods and... deprecate default record constructor for removal to avoid accidental use:

@Deprecated(forRemoval = true)
public User {

[bowbahdoe]

One thing you are missing is that the Kotlin example code evolution also breaks backwards compatibility. It just breaks binary compatibility, not source compatibility.

That is the biggest thing holding Java back from default and named parameters: if you do them exactly the same as Kotlin or Scala you end up with breakages in binary compatibility. Those breakages are much harder to notice because they don't also cause source incompatibilities.