What would you check when reviving a 1990s Java utility?

Start with the URL handling. A tool that blindly adds an HTTP scheme can turn an already complete HTTPS address into something invalid. Check both bare hostnames and URLs that already include a scheme, then test redirects from HTTP to HTTPS.

Also look for old global TLS workarounds. Disabling SNI globally can cause trouble with modern sites that host multiple domains on one address. Remove that workaround if it is no longer needed, and test against the kinds of endpoints the tool actually submits to.

Before changing much code, figure out what actually belongs to the application. Old archives can contain a pile of extra files alongside the program, which makes the folder layout harder to understand than the code itself.

Get a reproducible build and a small test case first. Once you know what runs and what goes into the release, the compatibility fixes are less of a guessing game.

I'd check whether the directories you care about still accept PAD submissions before sinking too much time into it. Keeping a niche tool alive can be worthwhile, but getting it to run doesn't necessarily mean every old submission endpoint still works.

Be careful about judging the whole codebase from one successful repair. Getting a legacy program working proves it can be maintained, but it doesn't tell you how easy future changes will be. Document the build, the fixes, and any assumptions you had to make so the next person has a starting point.