It’ll be interesting to see how @Inject is used in a project: will it be pervasive or used here and there in crucial places.
On the minimal end, @Inject could be restricted to resources like databases and large application services like a DAO manager. On the expansive end, someone could conceivably use @Inject as a “new” replacement, using it everywhere in every class. Based on the size of some Spring XML files, the maximal case might not be as unusual as it appears.
Picking the middle option is always the easy way out: it lets you look sensible and fair. Unfortunately, that vague moderation doesn’t really help when you’re making actual decisions.
I’d think anything large enough to be significantly tested or mocked would become an @Inject object. Certainly anything you could legitimately call a “service.” (And it’s a real shame that SOA overhyped the concept, because service-oriented design is a very useful architectural tool, and now it’s somewhat embarrassing to suggest structuring around services.)
Also anything configurable. And any extensions and plugins.
Beyond that, I’m not sure. Generally, I prefer wading into a new technology carefully to understand the issues before adopting it. @Inject as a JNDI replacement is a clear win as it big service injection. Beyond that, we’ll need real application experience.