The JSR-330 spec was originally owned by Bob Lee (Google) and Rod Johnson
(SpringSource, now VMware). When Bob left Google, Google gave the spec to him.
Neither Bob nor VMware seems to have any interest in moving this spec forward in
the JCP. Without their cooperation, nothing can happen. We would be happy for
them to give the spec over to someone who has both the interest and resources to
move it forward.
Yoon Kyung Koo wrote on 11/06/12 05:05:
> Hi, all,
>
> Indeed @Inject is defined in JSR-330 and JSR-330 was originally planned for
> Java SE platform.
> Then do you know what happened about JSR-330 and Java SE 7 or 8?
>
> I think if JSR-330 will be included in future Java SE then it'll be more
> easily acceptable for other JSRs to use the @Inject rather than using somewhat
> domain specific new annotations.
>
> --
> --------------------
> Software Innovation Evangelist
> Researcher & Executive Director / WAS Lab / TmaxSoft R&D Center
> PGP http://www.javadom.com/personal/yoonforhatgmaildotcom.asc
>
>
>
>
> 2012. 11. 6., ?? 7:11, Werner Keil <werner.keil_at_gmail.com
> <mailto:werner.keil_at_gmail.com>> ??:
>
>> Bill/all,
>>
>> I prefer @Inject, and please keep in mind, that annotation may be used by
>> CDI, and given Bob Lee is too busy with his work at Square to drive any
>> changes, everything in the Dependency Injection space still moving at JCP
>> happens via CDI, e.g. DeltaSpike, but to use @Inject you do not depend the
>> full CDI, only a handful of annotations that are JSR-330<347.gif>
>>
>> We are having this discussion in the Agorava Project, and already have plans
>> for Desktop/RCP or Mobile profiles or Agorava where CDI may be replaced by
>> something else like Guice, etc. Same challenge here, but I would prefer to
>> use 330/_at_Inject where it makes sense over a fragmentation and forking of such
>> annotations.
>>
>> Regards,
>> --
>>
>> Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead | Java Godfather
>>
>> Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
>> Skype werner.keil | Google+ gplus.to/wernerkeil <http://gplus.to/wernerkeil>
>>
>> * DevoXX: November 13 2012, Antwerp, Belgium. Werner Keil, JCP EC Member and
>> Agorava Committer, will present "Java Social JSR, it's alive"
>>
>> * Eclipse DemoCamp: November 21 2012, Copenhagen, Denmark. Werner Keil,
>> Eclipse UOMo Lead and Mærsk Build Manager will present "Eclipse M2M and
>> Standards for the IoT"
>>
>> * Eclipse DemoCamp: November 26 2012, Berlin, Germany. Werner Keil, Eclipse
>> UOMo Lead and Mærsk Build Manager will present "Eclipse M2M and Standards for
>> the IoT"
>>
>> * Eclipse DemoCamp: November 30 2012, Vienna, Austria. Werner Keil, Eclipse
>> UOMo Lead and Mærsk Build Manager will present "Triple-E class Continuous
>> Delivery with Hudson, Maven, Kokki and PyDev"
>>
>>
>> On Tue, Nov 6, 2012 at 10:02 AM, Florent BENOIT <Florent.Benoit_at_ow2.org
>> <mailto:Florent.Benoit_at_ow2.org>> wrote:
>>
>> I agree with Antonio, it easier for people that want to inject something
>> to always use @Inject instead of trying to remember which annotation
>> needs to be used for each particular case.
>>
>> For using some specs outside of Java EE, they can still use the
>> dependency on CDI.
>>
>>
>> Regards,
>>
>> Florent
>>
>>
>> On Tue, Nov 6, 2012 at 9:53 AM, Antonio Goncalves
>> <antonio.goncalves_at_gmail.com <mailto:antonio.goncalves_at_gmail.com>> wrote:
>>
>> Hi all,
>>
>> I am the opposite of Markus on this one. I don't what to ask myself
>> too many questions : need to inject a persistence context ? @Inject
>> PersistenceContext. Need to inject an EJB ? @Inject MyEJB... and so
>> on. I'm already disappointed to see @Context in JAX-RS. The
>> programming model should be as easy as possible.
>>
>> Then comes the "I don't want to depend on CDI". This to me sounds a
>> bit strange. CDI 1.1 is standardizing bootstrapping in Java SE, so
>> what's the issue ? If the Batch JSR needs CDI outside EE it just
>> bootstraps CDI in Java SE. Then, depending on CDI only really means
>> depending on another external jar (piece of cake for Maven)
>>
>> I would like to see less custom technical annotations (let's use
>> @Inject when we can) and in favour of more business annotation that
>> developers can create (thanks to Stereotypes and Qualifiers)
>>
>> Antonio
>>
>>
>> On Tue, Nov 6, 2012 at 6:48 AM, Markus Eisele <myfear_at_web.de
>> <mailto:myfear_at_web.de>> wrote:
>>
>> Hi Bill/All,
>>
>> Still very much split myself. I'm in favor of CDI. I simply don't
>> like to see @Inject all over the place.
>> We already have a ton of custom annotations (e.g. @EJB) and if we
>> treat them as a legacy artifact only we will probably end up with
>> a programming model that needs good naming conventions (again) to
>> be helpful.
>>
>> @Inject
>> private MyBoundary boundaryEJB;
>>
>> @Inject
>> private JobContext batchContext;
>>
>> This moves the problem to the user but should be solved in the
>> platform. Having custom injection annotations makes this more
>> readable and easier to follow in the code (at least for me).
>>
>> I would like to see the expansion of use of CDI stereotypes (aka
>> meta-annotations / stacked stereotypes) and require every EE spec
>> to provide a CDI based injection annotation.
>> They should be free to provide additional ways for supporting
>> standalone environments (e.g. via additional @Qualifiers).
>>
>> - M
>>
>>
>> On 6 November 2012 01:10, Bill Shannon <bill.shannon_at_oracle.com
>> <mailto:bill.shannon_at_oracle.com>> wrote:
>>
>> I'd like to follow up on an issue we raised at the Java EE 7 BOF
>> about the use of custom injection annotations.
>>
>> For example, should the Batch spec define
>>
>> @BatchContext
>> private JobContext ctx;
>>
>> or should it use
>>
>> @Inject
>> private JobContext ctx;
>>
>> The former is effectively a custom injection annotation
>> unrelated to CDI.
>>
>> The latter introduces a dependency on CDI.
>>
>>
>> In your opinion, which is preferred? It seemed that the EE 7
>> BOF audience was
>> pretty evenly split on this one, and I can see arguments for
>> either position.
>>
>> If @Inject is preferred, should we allow custom annotations
>> at the discretion
>> of the spec author, or should we disallow custom annotations
>> entirely?
>>
>> If custom injection annotations are allowed, should CDI make
>> it easy to
>> define them, e.g., using something like:
>>
>> @Stereotype
>> @Inject
>> public @interface BatchContext { }
>>
>> If CDI supported this easily, applications could even define
>> their own
>> injection annotations.
>>
>> Should custom injection annotations be a legacy artifact that
>> we need
>> to continue to support, or should we recognize it as a part
>> of the
>> Java EE programming model and use it widely?
>>
>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>
>> Web site <http://www.antoniogoncalves.org/> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Paris JUG
>> <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
>>
>>
>>
>>
>