[cdi-dev] Time to start working on CDI lite

[Mark Struberg]

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 at 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 at 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 at gmail.com> a écrit :
> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> <antonio.goncalves at 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 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.