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

Mon Aug 31 03:57:35 EDT 2015

I don't see Events in a "Lite" version because the other DI frameworks
don't use them. A "fatter" 330 with producers, programmatic lookup and
bootstrap, could be "easily" implemented by Spring, Guice... If we leave
events in a Lite version, then it won't be the case, and Weld and OWB will
be the only two implementations.

For me, a Lite version would just be about DI. If Weld uses events
internally to archieve basic DI, well, it's just an implementation
decision, not a spec. I would not even try to standardize the way @Inject
works (like Romain said, @Inject doesn't work the same in Weld or Spring),
let's leave it like this. If you take back Antoine sentence "*This would
allow using CDI in constrained environment like mobile or embedded devices*",
then I don't think events would fit here.

Antonio

On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg at yahoo.de> wrote:

> > For me, a Light version of CDI is clearly the features number. That's
> why I don't see events in it.
>
> We did discuss this last year on the f2f meeting. The problem lies within
> our Extension mechanism. Without events you also need to drop the Extension
> mechanism. And to be honest, this is THE major hit in all CDI…
> Sorry to be the bad guy busting all those ideas. I really don’t want to,
> but better now than too late down the road ;)
>
> It’s really tricky as many features are heavily based on each other. E.g.
> by removing scanning you could get rid of javassist/asm/etc ? nope, we also
> have our class proxies which need bytecode tinkering. So remove
> interceptors and decorators too? Well yea, but we still have normalscoping
> -> what is left? basically spring prototype and singleton. Hmm.  that’s not
> that much compared to full CDI. And all that for only 200kByte?
> (Btw we also discussed generating the bytecode classes at build time, but
> then we still miss the dynamics we get from Extensions, e.g. PAT adding an
> interceptor annotation)
> Just to give you a rough idea how this all works together when it comes to
> implementation details…
> Please feel free to ask Jozef and me for further infos on ‚dependencies‘.
>
> LieGrue,
> strub
>
>
> > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves <
> antonio.goncalves at gmail.com>:
> >
> > For me, a Light version of CDI is clearly the features number. That's
> why I don't see events in it.
> >
> > For me, a CDI Lite would just focus on DI. If CDI has @Produces and
> Spring has @Bean, then it's because 330 lakes this functionality.
> >
> > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <
> rmannibucau at gmail.com> wrote:
> > Lite can have several definition, let's try to list them up if it can
> help:
> >
> > - binary size: for me until 3M for an app it is "Lite"
> > - features number: the whole IoC set of feature is light since you
> almost always need it, it means you can do lighter but it wouldnt be used -
> check spring, who uses only spring-ioc and not context or more?
> > - features complexity: sure we are not light here but supporting scopes
> already breaks "Lite-ness" IMO so not a real issue
> >
> > So my view is CDI "SE" is light enough - as a spec and spec can't affect
> implementations so seems the fight is not on the right side to me.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >
> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
> antonio.goncalves at gmail.com>:
> > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
> forked 330 because he found CDI was doing too much  ;o)
> >
> > For me, "CDI Lite" was just basic dependency injection. The fact that
> CDI can now run on SE (like JPA....), is good... but for me it has nothing
> to do with Light : it's the entire thing that can bootstrap in SE. Good.
> >
> > So what is Lite for you guys ?
> >
> > Antonio
> >
> > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
> rmannibucau at gmail.com> wrote:
> > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
> > Personally, I'm not in favor of a slimmed down runtime.  It was tried
> with EJB, but never implemented properly (most implementations that support
> EJB-lite actually support the entire thing, except for deprecated stuff).
> >
> >
> > +1, most of CDI is basic and quickly any light version will miss events
> or other thing - in particular in maintaining micro services from
> experience. Size of an implementation can easily be < 1M so not sure it
> would bring anything. Only important point is what Antoine started to do ie
> ensuring EE and SE parts are clearly identified and split in the spec.
> >
> > I think if we define SE properly we won't have a need for this.
> >
> > John
> >
> > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
> antonio.goncalves at gmail.com> wrote:
> > @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.
> >
> > _______________________________________________
> > 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.
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
> >
> >
> > --
> > 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.
>
>

-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/c3b0dac2/attachment-0001.html 