Antonio,
The goal here is not to propose a new EE profile but a subspec that could
lead to a lighter implementation. And I don't see the benefit of pushing
this implementation to Java EE since CDI is today far less heavy that some
other spec like EJB or JPA. Perhaps you can give reason to review my
opinion here.
The benefit of CDI light would be in SE where the weight of libs really
count. That doesn't mean that someone couldn't take CDI light API to
produce a library and have it working on SE and EE since CDI lite has to be
a subset of CDI full.
Regarding JAX-RS my feedback was that the lack of SE support in CDI and
weight of impl in SE were the main reasons of the non adoption of CDI
support. As we are adding SE support and lite version of CDI these reason
will disappear.
Same for forge: CDI lite will help them to have something faster to start.
If we figure a solution to mutate bean manager at runtime that could also
help them I guess.
Roughly CDI lite is basic injection plus producer plus programmatic lookup
plus events, so it's more than a fatter jsr 330.
Antoine
Le sam. 29 août 2015 à 20:46, Antonio Goncalves <antonio.goncalves(a)gmail.com>
a écrit :
Hi all,
With my strong Java EE background, sentences like "IMO CDI lite should be
targeted to Java SE", hurt ;o)
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". Today, a JBoss
project called JBoss Forge (Java SE) is "dumping" CDI from its internals
because it's too slow (George, could you develop a bit more this topic?).
What do these two projects have in common ? They just need a "light"
dependency injection framework. I was talking to the Forge guys (I think it
was Lincoln) and, basically, they just need @Inject, @Qualifier and
@Produces (the missing one).
My question is : do we need a CDI Lite, or do we need a "fatter" @Inject
(for both SE and EE) ? I think that if we manage to move producers (and
disposers) to JSR 330, then CDI would do the rest, no need for a Ligther
version.
WDYT ?
Antonio
PS : With Antoine we talked to Juergen (co-spec lead od 330) and Patrick
Curran (JCP Chair man) and it looks like another lead could take over 330
(I'm imagining RedHat talking the Lead role on 330). Even a maintenance
release would be doable
On Fri, Aug 28, 2015 at 11:35 AM, Antoine Sabot-Durand <
antoine(a)sabot-durand.net> wrote:
> Hi guys,
>
> CDI lite is one of the big feature we are expected to deliver for version
> 2.0. I think it's time to start discussing about its design.
>
> The big picture is to provide a consistent subset of CDI that could be
> implemented like Dagger is (code generated with process annotation). This
> would allow using CDI in constrained environment like mobile or embedded
> devices.
>
> IMO CDI lite should be targeted to Java SE (I don't think it would make
> sense for Java EE). So, from a specification perspective, we''l probably
> have to split core part in 2 and se part as well (gosh).
>
> I'm not sure regarding API. today they only weight 72 KB, so creating a
> subset only for the sake of the weight doesn't make sense. the only reason
> would be to have something clearer for the end user. but that could be
> tricky.
>
> Antoine
>
> _______________________________________________
> 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 <
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>