I don’t grok many of the points to be honest. Please let me question a few practical
points:
1.) big size: nope, thats implementation specific. OWB core has 500k + apis + asm ->
way below 1MB jar size altogether. And this even includes OSGi stuff. And I think there is
a weld-se package as well, right?
2.) slow boot: nope, both OWB and Weld in the meantime provide SPIs to switch out to
custom scanning. Now the default scanning plugins could be replaced with a manually
pre-configured class list (build time generated) etc. Thus I see no real need to change
the spec. Of course, the bootstrap events could be improved. But that’s a matter of CDI
event performance. Just do a few benchmarks and you will see that there is lots of room
for improvement (10 mio CDI events OWB 6s, weld 19s). Do we really have anything near 10
mio classes in an embedded scenario? :)
What is left is that we _might_ drop the ‚contextual instance‘ paradigma alltogether to
spare bytecode tinkering and class proxies. But this basically is dropping the ‚C‘ from
CDI just for saving 150kByte. Imo that’s not worth it. Especially as it would mean that
the (C)DI-SE has a totally different programming paradigma as CDI-EE.
Don’t get me wrong! I think it is really important to grow new ideas and let them flourish
for a while. But at some point we also need to check them against the real world.
LieGrue,
strub
Am 30.08.2015 um 14:06 schrieb Antonio Goncalves
<antonio.goncalves(a)gmail.com>:
@Antoine, so which content do you see in CDI Lite ? Are you sure about events ?
I'm in favor of a "fatter" 330 that would have :
• @Inject : already there
• @Qualifier : already there
• Producers and disposers
• Programatic lookup
• Java SE Bootstrap
When you say "The goal here is not to propose a new EE profile but a subspec",
330 could already be seen as a subspec. If you put events apparts, what would be missing
in this list in your point of view ? And what obstacles do you see in archieving this ?
To boostrap CDI we have a CDIProvider, why not having an InjectionProvider just to
bootstrap 330 (then, CDIProvider could extend InjectionProvider, so it bootstraps the all
thing) ?
Antonio
On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <antoine(a)sabot-durand.net>
wrote:
Yes Arjan, I think it's the first reason. We really should work with them to
understand what should be added to CDI 2.0 to have it as a first citizen DI in their
spec.
Le sam. 29 août 2015 à 23:15, arjan tijms <arjan.tijms(a)gmail.com> a écrit :
On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
<antonio.goncalves(a)gmail.com> wrote:
> I remember talking with the JAX-RS guys (Java EE), years ago (back in EE6),
> and their answer for not adopting CDI was "too heavy".
I can't find an exact reference anymore, but I somewhat remember that
one of the reasons was also simply that CDI as a general solution
finished late in Java EE 6, while JAX-RS finished earlier and had all
the work for their own DI solution already done.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
_______________________________________________
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.