Thoughts on the New @Inject JSR

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

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 :)

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

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?

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.

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.

 

Wangliyu,

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.

Thanks,
Bob

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.

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