3:14 a.m.
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(a)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(a)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.