It's not so much about the Java code itself. When your Java app needs to talk to a database, it's convenient to be able to write integration tests against a running instance of the real DB. Ideally you'd also have a light-weight mock DB for unit tests, but some things only show up against the real deal. I guess you _could_ build that kind of test environment without containers, but I sure wouldn't want to.
If you're using an open source database like MySQL or Postgres it's pretty trivial to do this without containers. All you need is ~10 lines of SQL to create a new database and database user on your single local database instance. I don't understand why anyone would use a different database for testing and production. As far as I'm concerned, Postgres/MySQL are lightweight. I certainly have them running permanently on my machine and they use almost no resources when not in active use.
Now you need to git-bisect. And the range includes versions that ran in production with three different versions of your DB daemon (MySQL, PostgreSQL, whatever). The version might matter—in fact, look at that, the oldest few commits error on the current version of the DB.
Or you need to try something on another project that uses a different version of your database server. Or you need to pinch-hit on a project that has a half-dozen service dependencies at particular versions, none of which you have installed and running already.
The ability to very easily spin up clean installs of a bunch of services at arbitrary versions is incredibly useful. Containers aren't the only way to do that, but Docker does make it pretty damn convenient.
IO in the Mac "Docker Desktop" app (which wraps a Linux VM and a virtualization framework) is quite slow even on x86 so people often run eg PostgreSQL as a native app.
