[jfengel]

The bigger the project, the more painful the upgrade. Package systems are convenient to avoid reinventing the wheel, until you have to upgrade any piece of it. Then you're stuck trying to figure out which versions of each package go together.

If Package A won't run on JDK 17 your entire project is stuck on JDK 11. If Package B is upgraded but has conflicts with Package A, you have to dig through old versions until you find one that works -- and you don't get upgrades.

The more games somebody has played with reflection, undocumented features, deprecations, etc. the more likely you are to have a conflict. And since package managers encourage you to depend on somebody else's code, you end up depending on everybody else's code.

The smaller and greener the project is the more likely it is you can just pull the latest versions and be happy about it. A project that was written when Java 8 was current, and continued to develop, is going to be a nightmare.

[Macha]

"Oh look, I need to upgrade mockito and Spring. Oh, now I upgraded Spring I need to update the spring JPA plugin. Oh now I upgraded that I need to upgrade Hibernate. Oh now I need to upgrade the library built on it that that team over there maintains. Oh, they're not interested." etc. etc.

[ivan_gammel]

When using Spring Boot you usually update just one version and everything else is updated via BOM. There should be a really good reason to have fine-grained control over every single dependency.

[Macha]

Not every app using Spring is using Spring boot

[ivan_gammel]

You don’t have to use its functionality to use its BOM.

[Macha]

So honestly I didn't realise that it's POM extended to ecosystem libraries beyond Spring's own. However, it still doesn't solve the problem that e.g. the hibernate version compatible with Spring Framework n+1 is not compatible with the hibernate version compatible with Spring Framework n and now you're doing an "all or nothing" upgrade, which for a large app can be time consuming.

[ivan_gammel]

The point of using BOM is to avoid specifying dependency versions of individual components, so this problem is in reality non-existent. The only case when you would actually need to have different version of Hibernate than in your BOM is some critical bug fix, which is very likely a patch version and is very unlikely to break compatibility with the rest of your setup.

[dingi]

True, Spring upgrades can be a pain in the ass. There is a trick to make it less painful though. Use maven BOM for version management. As with any framework upgrade, it doesn't make the process entirely painless. But very much less painful.

[dionian]

Having a lot of experience with that stack... it is why i migrated to scala long ago

[paulddraper]

Tho Scala makes the upgrade problem even worse:)

[brnt]

Java isn't forward compatible?

[jfengel]

Overwhelmingly it is, until it isn't. There are tiny gotchas, especially if you play with some of the murkier aspects, such as reflection or class loading.

The more of someone else's code you use, the more likely one of them bumps into one of the gotchas. And that sets off a cascade of conflicting versions.