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

[Antoine Sabot-Durand]

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 at 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 at 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 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/20150829/4f371604/attachment.html