Code coverage is either a key metric or a terrible distraction depending on who you ask. We favor code coverage as a useful indicator but not the only indicator.
Java has a rough history with logging. Over the years, several new standards and "de-facto" standards have been created, yet most older standards remain in use. Yes, all of these come into play once a Java app gets big and deals with enough external dependencies. Yes, they conflict with each other. Yes, this is terrible.
Though, there's a way to make it all work.
Sometimes science isn't exact. There are multiple ways to arrive at an answer depending on the situation and goals. For instance, we could calculate the free energy of a molecule with either ab initio quantum dynamics or molecular mechanics. Within molecular mechanics there are multiple popular methods, such as the MMFF force field. Inside an application that contains multiple methods for accomplishing a task, we need a way to select among options in a consistent way. Enter: dependency injection.
We can do more in less time by using a language with which we're comfortable. We know the quirks of the language and can avoid them when possible. This stems from our collective decades of experience writing applications and systems with Java. We can focus more on the scientific problems to solve than the tooling.