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

[Antonio Goncalves]

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/2ded33c2/attachment-0001.html