Personally i would expect a kind of proxy based impl since CDI is mostly
interface based so it would always work and enable to switch between models
when needed.
Now I also dont expect we do it before CDI 3 arrives which can be never -
we dont know today.
So do we need anything? Probably not.
Probably let's wait we clarify clearly the status before doing anything.
Today the "vs" sounds emotionnal to me because the option to enrich javax
is still valid and the sanest for users and the community (what would mean
the first message of jakarta being "we drop everything" whereas goal is
long term investment at the end).
Le mer. 8 mai 2019 à 14:21, Arne Limburg <arne.limb...@openknowledge.de> a
écrit :
> Hi all,
>
> Being at the JAX conference now, I am quite oftenly confronted with the
> javax vs. Jakarta discussion.
> Besides that it is not clear how to handle that at the API level (btw.
> Good blog entries, David and Mark), I am thinking of how it could be
> handled at implementation level.
> My preferred solution would be the complete separation of Java EE APIs
> (with javax packages) and Jakarta EE APIs (with jakarta packages)
> and having the implementation support both. The question is, are we able
> to handle this without much code change?
>
> My first idea was to define an own set of interfaces like
> public interface Bean<T> extends javax.enterprise.inject.spi.Bean<T>,
> jakarta.enterprise.inject.spi.Bean<T> {
> …
> }
> We could then use this interface as return value for or interfaces
> whereever Bean is the return value in specification interfaces.
>
> The only problem I see with this approach seems to be with Collection
> return values and generics, i.e.
> javax.enterprise.inject.spi.Bean#getInjectionPoints() returns a
> Set<javax.enterprise.inject.spi.InjectionPoint> and
> jakarta.enterprise.inject.spi.Bean#getInjectionPoints() would return a
> Set<jakarta.enterprise.inject.spi.InjectionPoint>. In an ideal world our
> common interface would return a Set<org.apache.openwebbeans.InjectionPoint>
> where org.apache.openwebbeans.InjectionPoint extends the other
> InjectionPoints. But that does not work for generics.
> Regarding parameters the solution would be to have both methods and call
> one from the other, wrapping the parameter, which most probably should work
> out.
>
> Any ideas/opinions on that?
>
> Cheers,
> Arne
>
> --
> Arne Limburg – Enterprise Architect
>
>
> OPEN KNOWLEDGE GmbH
> Poststraße 1, 26122 Oldenburg
> Mobil: +49 151 - 108 22 942
> Tel: +49 441 - 4082-154
> Fax: +49 441 - 4082-111
> arne.limb...@openknowledge.de
> www.openknowledge.de <https://www.openknowledge.de/>
>
> Registergericht: Amtsgericht Oldenburg, HRB 4670
> Geschäftsführer: Lars Röwekamp, Jens Schumann
>
> Nächste Konferenz:
>
> Java Forum Nord | Hannover | 24. September 2019 <
> https://www.openknowledge.de/event/java-forum-nord/>
>
> Nächste Akademie:
>
> API, Microservices & DDD Summit | München | 17. - 19. Juni 2019<
> https://www.openknowledge.de/event/at-api-und-microservises-summit/>
>
> Treffen Sie uns auf weiteren Konferenzen,
> Summits und Events:
>
> Zu unseren weiteren Events<https://www.openknowledge.de/event/>
>
>
>
>
>
