At the end we need to talk to people within Jakarta. The current CDI proposal is a big mess in my eyes. The no1 reason for using anything JavaEE used to be a strong backward compatibility. And now they break it for no reason. Almost: they break it for supporting Quarkus. Which could have perfectly solved this in other ways as well, like we and Oracle Helidon do when running on the GraalVM. Maybe I'm overly pessimistic, but my fear is that CDI-4.0 will likely kill the JakartaEE ecosystem if they don't step back.
LieGrue, strub > Am 01.12.2021 um 10:41 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > Hi all, > > CDI 2.0 is a great spec but seems the future is not that bright for CDI > with all jakarta.enterprise.inject.build package which makes the spec > toggled (ie you have an unified API but you can't use the full API at the > same time since several parts are now incompatible between each others). > > I wonder if we shouldn't take this as an opportunity to extract an > openwebbeans API and provide a light IoC (potentially even with generated > proxies instead of asm ones to make us even lighter). > > The advantages are obvious: > > 1. Stable API compared to what the spec is baking > 2. Lighter runtime/impl > 3. Not bound to a single company choices (sadly it is what it is now) > > The drawback is indeed: > > 1. Likely less integrated in frameworks (vaadin, etc) - even if integration > is generally light > 2. Need to check how we link it to javax/jakarta impl (shared module or > just no link?) > > Wdyt? > Did you already think about such an option? > Do you think CDI 4 which breaks CDI 2/3 and EE platform design for no > technical reason is worth it? > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance>
