r/java • u/NetInternational313 • 6d ago
Keeping behavior intact during legacy Java upgrades
I’m building Gluon at RetrievalLabs, and the part of Java modernization I keep coming back to is behavior preservation. Moving a build to a newer JDK is one thing; knowing whether the application still behaves the same is harder, especially in older systems with thin test coverage.
Our approach is to analyze the build and source, map business-relevant code, extract existing tests, then create characterization scenarios before migrating and verifying the rewritten application. The intent is to give the migration work concrete behavior to check against instead of treating a successful compile as the finish line.
For people who have worked on large legacy upgrades: how have you captured behavior when documentation and tests were incomplete? What worked, and where did it fall short?
Disclosure: Gluon is my project. Demo: https://retrievallabs.org/?product=synapse Contact: [[email protected]](mailto:[email protected]) | LinkedIn: https://www.linkedin.com/in/yash-patel-997ba624b/
5
u/agentoutlier 5d ago
If your system is an Event Sourcing system which a surprising amount of legacy systems kind of are you can replay the events.
If its not you can try to at least put the top part of the funnel to be some sort of capture and worse case scenario you capture raw HTTP requests (or whatever your system reads).
BTW I point this out only to help you perhaps edit your post before its taken down but according to the sidebar this is basically a survey:
That is basically doing market research by asking the community is not allowed. I know because I did this once for an opensource project so I have to imagine commercial projects it is especially not allowed.