HACKER Q&A
📣 _positive

Dealing with Java Upgrade Nightmares – Any Lifelines?


Pretty much accepted Java upgrades are going to be the bane of my existence at this point. Anyone found any tools or processes to help speed up the migration? I've found a few dependency management tools, but for the scale of codebase I'm working with the dependency trees are just so large they're not really helpful.


  👤 isbvhodnvemrwvn Accepted Answer ✓
Can you outline what specific problems you have? I'm going to guess upgrade of Java runtime are not the issue, but upgrades of packages are? What kind of packages, an assorted list of cobbled together libraries or half the Internet's of BOMs like spring boot? And I'm going to take a leap and say you have not been keeping up to date for a few years at least?

👤 exabrial
It's not Java, it's lazy developers you hate. The same nightmares happened to me in the early 2000's with CPP and CORBA.

You have to clean up the pom.xml's. That is the only way. Remove ALL unused dependencies. Declare ALL used dependencies correctly: compile, runtime, provided, test. Delcare ALL used dependencies EVEN IF they're brought in transitively. This last point is so essential because the maven version algorithm relies on it.

In big companies, people have a terrible habit of just copy/pasting dependencies from one project to the next. Your pom _absolutely_ must be minimal and only import things you need, otherwise this happens.

One our checks fails the build if undeclared used dependencies are found, but also fails the build if unused dependencies are found. Developers that break these rules too often give an unfortunate meeting because it is this serious.

If these buildings blocks aren't correct, all of your efforts will fail. I used to work for a large Asian software company, that began with an A and ended in Ba. I helped rescue multiple giant codebases with this technique.


👤 stevepike
(Good project management is the key to this work. You need to spend the time up front (scripts can help here, but the tooling isn't awesome) to figure out everything that's going to block your language upgrade. For all those blockers you want to work as hard as you can to find backwards-compatible fixes (like upgrading a blocking dependency to a version that's dual-compatible with your current and next language version). Then you work through small incremental PRs so your eventual large upgrade is easier. This also works for code changes around breaking changes - often you can make these changes ahead of time, standalone. I've done individual rails minor version upgrades that took 100 PRs of pre-work.

In my experience often developers try to take a shortcut where they try to bang out the large upgrade in one giant PR. Sometimes this works but it's very risky - more often I see very long running branches that get abandoned. It's much better to make guaranteed incremental progress, plus your PRs are much easier for your team to review.

My startup Infield solves this problem for python / ruby / JS backends through software for the project planning (we run a solver over your dependency graph and read every changelog to identify breaking changes) and people for the breaking changes (our team will open PRs where we fix breaking changes so your code is compatible). We're starting to think about moving into the statically typed backend world with java / .net / maybe scala. I'd love to hear more about exactly what you've run into and whether my experience here matches with these ecosystems.


👤 tacostakohashi
Are you using maven / something else?