DataLoaderOptions immutability change is not breaking

[bbakerman]

Discussed in #188

^{Originally posted by zsmoore April 30, 2025}
Hello all,

We are upgrading to 4.0.0 to get the latest instrumentation changes (thank you this will remove some custom infra we have). However, after the upgrade we have failing tests due to the immutability change.

This is fine as its a major change and we expect to need changes however the immutability change seems like we could go farther here. I agree that we should ditch the mutability and move to immutability however, since this is a major change anyway should we have just deleted the old functionality? Now code that does not have test coverage might break at runtime rather than compile time. Luckily we had test coverage to cover this scenario.

example code

DataLoaderOptions options = DataLoaderOptions.newOptions();
if (maxBatchSize != BatchLoader.UNSET_BATCH_SIZE) {
  options.setMaxBatchSize(maxBatchSize);
}
return options.setCacheMap(cache);

In this case I would prefer if the codebase was broken so we could make the proper fix rather than needing to find it ourselves based on the test results.

Thank you!

[bbakerman]

We have had the same feedback from a team in Atlassian.

This was a mistake - we meant to break the behavior to be immutable but I wrongly kept the API shape the same but this was wrong. Mea cupla.

We will release a v5.0 very soon with this fixed since it will continue to hurt others over time. So any one using DataLoader direct would be able to get the new breaking change and file at compile time.

Our challenge however is more in graphql-java. We updated to 4.0 as a transitive dependency and if we were to pick up this new major version then really that should be a major release of graphql-java and we only just made one of those

So we need to decide if this is worth a major graphql-java release or not. But thats a seperate decision to a new DL major version