James is a DZone MVB and is not an employee of DZone and has posted 7 posts at DZone. View Full User Profile

Thoughts on the New @Inject JSR

  • submit to reddit

There's been some interesting feedback from JSR299 folks on the new @Inject proposal. (Though there is a bit of argument for argument sake in there :).

I can understand 299 folks wanting there to be just one spec that talks about IoC. However IoC is a large complex area that is still undergoing quite a bit of innovation (e.g. see the changes in Guice 2 and the JavaConfig which is part of Spring 3).

For me the great thing about the new @Inject JSR is that its small, simple and focusses on the common well understood part of IoC (the annotations you add to your objects so that popular IoC containers can inject your objects). This is the thing I most want - a standard set of annotations I can use everywhere in objects - then consumers of those objects can choose whatever IoC container they wish to wire things together be it Spring or Guice or a JSR 299 provider or whatever. The actual wiring code (in Java, XML or some other script/language) tends to be kinda small stuff relative to the tons of Java code for the objects themselves. Given the large variety and constant innovation in the wiring side of things, its probably a bad time to try lock that part down as I don't think there's consensus on how that part should look (though Guice 2 and Spring JavaConfig seem to get closer all the time).

299 however standardizes lots of things which only seem to be done in Seam; I don't see Spring, Guice or Pico implementing 299 any time soon as its a bit too big - however all IoC containers should be able to implement @Inject pretty easily; most IoC containers have already got something like @Inject in them today.

So as a practical kinda guy at heart, the best way forward IMHO to be able to write IoC container agnostic objects that can then be injected by Spring, Guice, Pico, Tapestry or indeed a 299 provider seems to be the @Inject JSR.

This doesn't mean 299 isn't useful; there's some interesting stuff in there particularly relating to eventing and JEE integration to IoC; but I see getting @Inject done and adopted by Spring, Guice & Pico (and hopefully the JSR 299 RI too!) to be most important for IoC in the Java ecosystem as a whole.


Published at DZone with permission of James Strachan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Liyu Wang replied on Fri, 2009/05/08 - 10:40am

in the past, Spring tried to do their best to make everything "non-standard", especially after 2.x, most likely for a normal project, if you use it, you will be locked in, now Spring feels the fear of JSR-299, so it try to mark itself "standard" and trap more people. The proposal only defined the small set of annotations, didn't mention the container, but for DI you have to have a container to do the magic, here Spring imply that you have to use Spring as container, and can't move to anywhere else, after all it still "non-standard". Btw, I think it's wierd that seeing people drive a Carmeria that has Harmer's body and Civic's engine, BMW's nose and Thomas' wheel. Spring always make me feels like that. Why don't you save your day job to just use Seam+JSF+EJB3.x, it can move to any JEE container and works just fine. Peace

Ivan Lazarte replied on Fri, 2009/05/08 - 10:57am

I see standardization of a general set of dependency injection annotations a necessity.

Let's say I'm coding an SWT app, or a command line client. Am I supposed to download 299 for that? It doesn't make any sense. Spring/Guice's proposal to me is finally opening the door for larger adoption of AOP within a lot of development contexts OUTSIDE of the EE space. What are the needs of those applications, as well as those which might be used for the web, but not necessarily from within an EE container.

The core fact is this. There IS life outside a JBoss instance.

Liyu Wang replied on Fri, 2009/05/08 - 11:22am

FYI, in JBoss WebBean RI has a small core that can live outside EJB container, and basiclly I see those Annotations defined in the new proposal is just small set of the JSR299. Even you develop Desktop/Rich Client apps, if you choose to use Spring, eventually you will end up with a jar hell, you need Apache commons, log4j/slf4j, Spring core, spring-beans, spring-context, if using JPA, you have to choose your toplink/hibernate, if using AOP, you have to choose the spring-aop, aspectJ, and some other libs, and use Spring to glue them. and your "app" will locked in with Spring "container" and the libs you choosed. worst part is Spring always change some classes/DTD/XSD in each version, and you will find your "app" can only run on Spring 2.5.1. after 3 month or more, you will be asked to pay a hell lot money to get that version supported. That's how we do things :)

Fab Mars replied on Fri, 2009/05/08 - 11:25am

I agree with most of what wangliyu wrote.

Also, I followed the lenghty discussion on http://in.relation.to/Bloggers/CommentsOnAnnotationsForDependencyInjection and I fully support Gavin's point.

Also, I'm tired of people always pretending that some technology is very complex and that many concepts remain to be addressed (in an uncertain future full of questionmarks and evil shadows you know)...I don't think that Java, and now more than ever, needs retrograde and wait-and-see mentalities. The Java ecosystem has to evolve now if it wants to live. Sorry for being frank.

299 is a huge outbreak in the JCP world thanks to the hindsight and the hard work of the WebBeans folks. Its repercussions will be unprecedented. This is far from just a rubberstamp of Seam imo, and for once in the Java world, it will make our lives easier in the end. Oh it has very complicated features too, but you don't have to use them and can keep the game simple. I'm not gonna discuss technical details.

Still, when I see this @Inject attempt, I do see people looking through the small lens of the opera-glass, as we say in French. IoC for the poor. No thanks. I can undertsand the aim there, but this is just a political thing. One could argue WebBeans was also one in the first place. At least it addresses a whole range of issues.

James Strachan replied on Fri, 2009/05/08 - 11:33am in response to: Liyu Wang

If you want to stick with 299 and Seam thats fine - noone is talking about taking anything away. The new @Inject is about promoting a standard set of annotations across the existing popular IoC frameworks like Spring, Guice, Pico and Tapestry - plus 299 implementations can support them too. i.e. a real standard, not just Seam and the RI. I really don't see Spring/Guice/Pico/Tapestry implementing 299 any time soon - do you? Note that the new @Inject JSR does not imply you must use Spring. Try any of the other providers! Heck Seam can trivially support them too! FWIW Java ecosystem is a little larger than just Seam; but if you wanna stick with 299, thats fine with me

Liyu Wang replied on Fri, 2009/05/08 - 11:35am

I guess the new proposal is just a trap, it defined the annotations and put into the JavaSE, and then if you want to use it, you have to have a container, whoever do the offical RI for this will put their stuff into the JavaSE, it's just bad idea, like boundled JavaDB/Java-WS2.0 stack, and how this will cooperated with new Java module system? Too many unknown, and I do think Spring try to put a bad seed into the Java heart. God knows JCP's new master will do what to Java, but he definately don't want other company share the market with himself.

Liyu Wang replied on Fri, 2009/05/08 - 11:39am

oh, one thing forgot to mention, I'm not JSR299 fan, besides it still in final draft, JSR299 is targetting in JEE spec, it doesn't mess up JSE, the new proposal required change JSE and only put the annotations in the JDK/JRE means you can't run it out of the box. You see the difference?

Liyu Wang replied on Fri, 2009/05/08 - 11:43am in response to: James Strachan

Apache has openWebBean project, I'm not Seam fan boy, but if I'm using JSF, I'll use Seam, I'm not so called architect who will add Spring no matter if it's really needed. So I don't want to see add those Annotations into JDK/JRE. you can have sepated package that's fine with me.

B. Ertung replied on Fri, 2009/05/08 - 2:35pm in response to: Liyu Wang

As far as what read from the link, it is just a JSR proposal. Why do you so enthusiastically think that it would make its way to the JDK core? There are numerious approved JSRs which are not included in the core. On the other hand, it is always good to have this kind of innovative approaches around. I personally think that @Inject would not make the core JDK, but having it standardized would not hurt anyone.

I see @inject as innovative in the context of architecting software. I certainly would not care about the political egoism created to keep things in an oblivious context driven by only a few. Only thing matters to me is that I would prefer simple against bloatware anytime. Nevertheless, at the end, I will always have a choice to use it or not to use it.

Ivan Lazarte replied on Fri, 2009/05/08 - 2:20pm in response to: Liyu Wang

No, you need spring.jar, but nice try. Wait, what about logging! Oh that's right JBoss uses that too. AspectJ AOP is optional. Have you even developed a modern Spring app? Sounds like you have some sound bites but no real experience.

Liyu Wang replied on Fri, 2009/05/08 - 6:43pm in response to: B. Ertung

It's not me, it's the proposal make me think of that way, those simple annotations doesn't mean anything if you don't have container, the idea of @Inject is same with JSR299, it just try to get rid of EJB, try to use "Spring Container" to replace "EJB3 container", and @Inject introduce a lot holes, those holes are just traps for projects, too many unknown stuff.

If it put into JDK core, you really don't have choice to get rid of it.

I hope this JSR proposal RIP, anyway, God knows what will happen to JSR after Oracle bought Sun.


Liyu Wang replied on Fri, 2009/05/08 - 6:47pm in response to: Ivan Lazarte

take a look, the proposal is target to JSE env, so you don't have JBoss, you have to have log4j or slf4j, apache commons, don't tell me your "Spring Container" needs JBoss container.

I don't understand, NB/ECLIPSE doesn't need spring to make it work, why you need Spring to work with SWT?

Besides the Seam doesn't really need JBoss, it can deploy to GF, WL, WSP, even TC.

Did you try Spring WebFlow? try do one Seam and one SWF, see how you feel it.

Bob Lee replied on Fri, 2009/05/08 - 6:57pm in response to: Liyu Wang


Not everyone writes EJB-based web apps. Some of us use DI on mobile phones, in GWT apps, in Swing apps, in command line programs, etc. These annotations can be used in all of those places as well as by 299; they don't preclude 299 in any way.


Liyu Wang replied on Fri, 2009/05/08 - 7:16pm in response to: Bob Lee

I'm not fan boy of JSR299, besides it's still a draft, actually I used Guice 1.0 for a while, I like it, I can see there are some things in Seams get the idea of Guice 1.0, I like Guice over Spring, all I'm saying is that the annotation is just an interface to developer, there are much more things need to be clarify behind of these annotations. I don't want to see these add-on features to be put into Java core, JSR299 is just a set of jars, JPA is a set of jars, they don't get in the core of JDK, I don't want to be forced to use/include Spring stuff into the project that I don't really need it.

Cloves Almeida replied on Fri, 2009/05/08 - 9:31pm in response to: Liyu Wang

C'mon, proposing a set of annotations as a standard and call it a day is ridiculous. It's akin to the SI folks saying "well, we couldn't agree on the lenght of a 1 meter, but we say every measure should be based on it and 'm' is the standard representation".

The discussion is not about SE vs EE. We all agree we need DI on applets, mobiles, embedded, etc. But the standard should be specific enough that, if I use no extensions, I can replace vendors with MINOR changes and MINOR impact on behavior. Currently it has no plans to specify how DI is configured (XML? Annotations? Java?) so a developer must rewrite configs whenever he changes vendors. This specification is at least incomplete.

Also, being a subset of 299, which will be approved first, the @Inject has the burden to be consistent with 299. Anything but that will bring confusion and bad mouth to the community. Big boys won't allow that.

Imagine an IBM consultant trying to convince a senior architect at a Fortune 500 company to use this thing called "Dependency Injection". He get's thrilled that he can uses SE so it will fits nicely on his salesmen PDAs. His DAOs can just inject a datasource from an embedded database - it's so much more elegant! It's so good that he adopts it and, being a Java standard, has no policy objections or lengthy evaluations.

The PDA application goes in production and now they want to change their open source testbed implementation to IBM's accredited implementation - wait they can't because they'd need to redo the configuration. The big iron boys liked and want to reuse the code in their 299 "web version" of the app. Oh! They're even more scr*wd because it's a different set of of configuration files AND DIFFERENT ANNOTATIONS.

I know it's a bit dramatic but it still is a bad idea.

Liam Knox replied on Sat, 2009/05/09 - 6:11am

I agree the @Inject looks small and direct, covering a well understood and used in anger side of IoC. Given the caliber of project owners I would certainly trust this work rather than jsr299. People seem to hark on about EJB3 and so called 'standard' containers but fail to remember that Spring, Guice etc have gained such massive uptake because J2EE standards were in such a complete mess due uneeded complexity and usability. EJB3 2 steps forward 3 back
My 2 cents worth would be go with simple and the @Inject annoations are pure intuitive and feel right.

hookfi john replied on Sun, 2009/05/31 - 7:53am

links of london Bracelets links of london Earrings links of london Necklaces Provide customers elegant and high-qualitylinks of london jewellerywith competitive price.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.