[cdi-dev] Merging JSR-330 into CDI

[Mark Struberg]

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.


LieGrue,
strub




> 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 
> that
> 
> 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...
> 
> 
> 
> LieGrue,
> strub
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> 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.
>