[cdi-dev] Merging JSR-330 into CDI
struberg at yahoo.de
Sun Mar 20 04:14:15 EDT 2016
I'll give you an example:
Currently many specs refer to atinject but also to CDI, because they need to use @Nonbinding (e.g. in Qualifiers).
Thus Antoine and I asked the atinject EG whether they might introduce a @Nonbinding annotation. During that I learned that annotations not available on the classpath will _not_ blow up but simply don't appear at Runtime in Class#getAnnotations() etc.
Means if you don't have the cdi-api.jar on your classpath the @Nonbinding annotation just doesn't show up at Runtime.
Since Spring and Guice seems to not need this feature it's all fine from a CDI pov.
Imagine what it would have meant to us if we would have got a second @Nonbinding in the javax.inject packgae: we would have to duplicate all the code which currently handling @Nonbinding.
And that was actually the most important requirement the CDI EG came up for atinject in the last 7 years.
Thus before we continue any discussions and further rouse people I like to see clear ideas WHAT you like to get changed in atinject.
> On Sunday, 20 March 2016, 8:35, Mark Struberg <struberg at yahoo.de> wrote:
> > What are the benefits?
> I mean serious, what does CDI gain?
> I can at least tell you what it hurts:
> TL/DR: Instead of claiming HOW cool it would be please show WHAT you like to
> change. I like to see CODE to show possible benefits. Before that I don't
> waste any more energy, and you should neither.
> long version:
> 1.) A lot specs are currently worded to only need JSR-330 for users. That way
> they run fine with CDI, Spring, etc. E.g. JBatch, Bean-Validation, etc. What is
> wrong with that?
> 2.) What changes do you need in atinject? We had a few ideas and sent them to
> the JSR-330 EG a year ago. We had good discussions but none of our wishes was
> worked out because WE failed to make final suggestions!
> The atinject EG (Bob, Jürgen) has been responsive. At least MUCH more responsive
> than other EG leaders these days... So I fail to see why the atinject EG is
> 'inactive since 5 years'. That's just wrong information.
> 3.) We cannot simply take the javax.inject package and maintain it in CDI. It is
> forbidden to split a java package into multiple specs.
> 4.) We also cannot just amend the annotations and take them 'over'. That
> would require the EC to officially move the maintenance of atinject to the CDI
> EG. Or even requires a handover from the atinject EG. I'm not sure about
> 5.) again: WHAT DO WE GAIN? I always hear claims that it would be oh so great.
> But then again: Show me an example what we would gain from it! Stop trashtalking
> but show CODE instead!
> 6.) Our CDI-2.0 roadmap is full of stuff we still need to deliver. The EG is
> busy as hell to get this done. You might add this to a CDI-3.0 wishlist, but
> that's it for now imo.
> 7.) The JSR-330 spec had an important political role back then. I know most
> people don't know that, but it's still great to have this little peace
> which managed to make peace. Not peace between Spring and EE as many people
> believe, back then it was more that it brought mainly peace between CDI and most
> of the rest of JavaEE EGs! Remember that we haven't been allowed to target
> Java SE in CDI-1.0? Remember that we were force to have the 'for Java
> Enterprise' in the spec name? Remember that we had big battles with EJB? No,
> then just take it as granted and let it rest...
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
> on this list, the provider waives all patent and other intellectual property
> rights inherent in such information.
More information about the cdi-dev