Well this article is my first encounter with the new EJB specs and it is rather early in the morning so I might miss some important issues here but basically I don't see any difference between
Context ic = new InitialContext();
HelloWorld helloWorld = ( HelloWorld)ic.lookup("java:comp/env/ejb/HelloWorld");
private HelloWorld helloWorld;
Okay, it looks different and you don't seen any InitialContext magic but to me it is still the same, this is not inversion of control as I appreciate it from Spring.
For me the prime reason to use IOC is that in a certain location I want to use an object implementing a certain interface but without having to determine at that location what object (of what exact concrete type) I am going to use. This functionality is basically already provided in the old J2EE specs as you lookup an object by name in the J2EE context. It is in the J2EE config where you define 'the" object suited to become the object implementing the desired interface. The same type of object lookup is also available in Spring by using its ApplicationContext and looking up a POJO bean by name.
Still the problem here is that this is not really IOC, its is an enhanced version of an implementation of the Interface Design Pattern. The problem as I see it is that sometimes you suddenly need 2 different objects of different types implementing a certain interface instead of just one. And if you developed your application by looking up objects by their configuration name. Example: an application uses a datasource to retrieve and store data. The data source is retrieved from the runtime environment using a single name AdventureDB. But then for some architectural reason 2 different databases are put into use and thus 2 differently configured datasources with 2 different names. Ok, it is simple to alter the code to use a different name in the lookup process. But if you used real IOC this wouldn't be necessary.
This is my second reason to use IOC in its full glory: in a spring based application where I need a datasource I provide a setter method to inject a datasource and in my spring config I define for a lot of different objects which datasource they need to use. Okay okay, if one object suddenly needs to use 2 different datasources this scheme also needs modification then.
@Resource javax.ejb.TimerService ts; is a J2EE example of a more complete IOC as I just described it. But then the article is missing one element: where do you define the resource ? E.g. where in the new J2EE do you define the real class of which the resource is going to be a runtime instance of?
And finally one last remark which is not the issue of the article "Using dependency injection", where in J2EE 5.0 can I find Aspect Oriented Programming, which is the third reason I like Spring way over J2EE 1.4.
On the whole: a nice article on J2EE 5.0 but regarding J2EE 5.0 itself: too little too late.
Just my $.02