Alas, it's still kind of a mess. The #1 improvement made to Java imho has been dependency injection in Spring and Hibernate. But this dependency injection pretty much kills all the compile-time sanity checking that compiled languages are supposed to provide. It's great when it works, but when it doesn't, it just barfs out useless stack traces that don't actually show you where the problem occurred.

I'm not sure I believe Spring and JavaEE are as compatible as some would lead you to believe. CDI and JPA are the official implementations of dependency injection and ORM persistence, but they overlap with other functions in Spring and Hibernate. Components in JavaEE are POJOs or MBeans and they're injected based on qualifiers and rules in a configuration file. Guice and Spring both allow you to wire components together, but you can easily get conflict between their injection and the CDI injection.

The compile time sanity checking is still doing type checking, and to a degree you're correct ... there will be run-time exceptions if CDI can't find any instances of an object (likely an interface) to inject or if there is more than one that matches. I don't think you'd want it to randomly pick one.

If you code to the CDI and JPA specifications, you can plug in Hibernate and Weld as your implementations of the frameworks. If you plug in Hibernate and Weld, then use their non-standard extensions you can indeed find irregularities.

Can you show me an example of something a compiler could check if it wasn't for dependency injection?

I think the question of whether or not to hard code some setting or make it configurable is unrelated to dependency injection. Dependency injection is one way to design dynamic configuration once you have decided not to hard code.

Other options would be to load stuff from a database, a directory server or from a config file. No matter how you do it the compiler won't be able to help.

I can't speak to Spring and Hibernate, but using Guice for dependency injection has been quite pleasant. True, it does push some errors to run-time that I would have preferred to see at compile-time, but the error messages make the resulting fix immediately obvious.

(Can anyone speak to this aspect of working with Dagger?)

I don't believe this is true at all. Dependency injection is just a way to invert control, decouple your code, and make it more testable. Proper tests of your configuration when your container is bootstrapped is all that is necessary to maintain sanity here.

You are still getting all the benefits of static typing, especially if you are coding to a contract.