Inconsistent behavior of circular dependencies on different machines

[DanielLiu1123]

Due to legacy code, we’ve enabled circular dependencies. With the same codebase, both my colleague and I can run it normally on macOS, but on our server (Amazon Linux), we’re encountering circular dependency issues (Spring Boot 3.1.4). It’s been driving us crazy—we’ve run into this kind of problem at least three times. Our workaround has always been replacing constructor injection with @Autowired. What’s even more frustrating is that we haven’t been able to build a minimal reproducible case…

I did some research and found that many others have faced the same issue:
https://stackoverflow.com/questions/29347723/why-does-spring-get-circular-dependency-issues-on-one-machine-and-not-another

I think this perspective might be accurate:
https://stackoverflow.com/a/34206071/24228439

However, I haven’t found any related issues in the Spring Boot issue tracker. I’d really like to know if anyone else has encountered something similar, and what solutions worked for them.

[bclozel]

We should have plenty of issues like that in the Spring Boot and Spring Framework issue trackers.

Let me find a few here:

• Java Spring Boot Circular Dependency on one environment #23222
• Enable reproducibleFileOrder by default on bootJar and bootWar tasks #27411

As for fixing such issues there are some workarounds like using "@lazy" or ObjectProvider at the injection point:

• Circular dependency between AttributeConverter and JPA #41156 (comment)
• Circular Dependency Issue - V2.6 to Latest #36286

But the true recommendation is to refactor the code and break cycles for good. If you don't break cycles, you will always have to allow cycles in the first place and then rely on a best effort behavior that might break depending on external factors. After all, this is why we flipped the default for this in the first place: we acknowledge that fixing this in large codebases is challenging and this shouldn't happen in the first place.

[DanielLiu1123]

@bclozel Thanks for your reply.

We’ve completely avoided circular dependencies in our new code. However, we also have a massive legacy codebase—far bigger than you might imagine—and we simply don’t have the capacity to refactor it right now.

The core issue for me isn’t the circular dependencies themselves, but rather the inconsistency across different machines, which has caused us a great deal of pain. If a circular dependency were to surface during local development, that would be fine—I could just refactor it. But if it works on my machine and then fails in production, that’s terrifying (which is exactly what we’re dealing with now). It takes a huge amount of time to debug, and even with deep knowledge of Spring, it’s still difficult to identify the root cause. This significantly adds to the frustration of development.

What I truly want is consistent behavior. If I can reliably reproduce a problem, then it becomes a simple one to solve.

So what I’m looking for is a solution that ensures consistent behavior across different os, not how to resolve circular dependencies.

[bclozel]

To guarantee such a thing, we would need stable way to scan for files on filesystems and reflectively list methods in classes - across operating systems. As far as I understand this is not possible right now.

[DanielLiu1123]

So this is indeed a problem, right? Maybe we should reopen this issue and wait for a solution to emerge someday.