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.
No, it’s not an impl thing at all but all the Extension events and it’s usage are
specified deep in the CDI spec.
Of course the impls could use different code parts for Extension events and ‚user events‘
but you still would need an event bus OR you would get rid of Extensions alltogether. But
that would be pretty insane imo ;)
There is also no need to go further in the JSR-330-only area. All CDI containers must pass
the atinject TCK and thus are fully certified JSR-330 containers as well. Add guice,
Spring, picocontainer, etc to this. There is really no need to go down even further in
this road imo. We are not here for world domination. We don’t need to do _every_
situation. Let’s instead do OUR main goal really well.
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.
Forget about all the Android area for now. In android there are not even Annotations
afaik. And Android is NOT Java. The runtime and all the bytecode stuff we do here wont
work that easily. So we would get rid of TONS of neat stuff a JavaSE app most of the times
would LOVE to have.
IF we say that CDI-lite is targetting android then this is fine as well. But then we aim
for a TOTALLY different goal! This would not even be useful in a SE. If you really like to
have a lightweight-as-possible DI container, such a project already exists. It is called
Apache Avalon [1] and got written in 1999. So it even predates Spring for about 5 years…
LieGrue,
strub
[1]
Am 31.08.2015 um 09:57 schrieb Antonio Goncalves
<antonio.goncalves(a)gmail.com>:
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(a)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(a)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(a)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(a)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(a)gmail.com>
wrote:
> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)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(a)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(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.
>
> _______________________________________________
> 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.
>
>
>
>
> --
> 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(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.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France