I am aware Play.isProd is removed in the latest build. What would be the benefit using dependency injection in this case?
Yes, I agree for shared resources / mutable state using dependency injected singleton bean is a good practice. But in this case, env.mode is not going to change (AFAIK) Shouldn’t it just works like Apache SystemUtils.IS_OS_MAC?
Actually, that’s not quite true. Play.isProd answers the question “is the currently running application running in production mode?”. This doesn’t make sense if there is no running application, or in a case where you have multiple running applications (which is a supported thing in Play 2.7, e.g. for parallel testing).
In general, though, I’d try to avoid having mode checks as much as possible. If you have code that only runs in prod hidden inside a component, you can make it much harder to test that code. In most cases, you can replace a mode check with configuration, which is much more explicit. That way if you write a unit test against that code you can explicitly configure it to make sure each code path is tested.
Even for your IS_OS_MAC example, it might be useful to have that passed in rather than checking that global state in the code. Suppose you want to write tests for the Mac and Linux version of your component, and still make it possible to run those tests on either platform. If you can write new Thing(isMac = true).doSomething() you can force the “Mac” behavior and test that your method does the right thing, without having to actually be on a Mac.
Of course, if you’re sure it makes sense in your case to use the global helpers, you can go ahead and override the application loader and set your own global state on startup. Play just doesn’t want to provide these global helpers by default anymore since it tends to encourage less testable and less modular code.