Mark,
I'll take your branch and check, how much effort it would be to support both
packages at the same time.
--
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
Registergericht: Amtsgericht Oldenburg, HRB 4670
Geschäftsführer: Lars Röwekamp, Jens Schumann
Nächste Konferenz:
Java Forum Nord | Hannover | 24. September 2019
Nächste Akademie:
API, Microservices & DDD Summit | München | 17. - 19. Juni 2019
Treffen Sie uns auf weiteren Konferenzen,
Summits und Events:
Zu unseren weiteren Events
Am 08.05.19, 17:38 schrieb "Mark Struberg" <strub...@yahoo.de.INVALID>:
I'd say we do branches and continue with jakarta.*.
The current OWB release is very stable and fast. So I don't expect many
changes.
https://github.com/struberg/openwebbeans/blob/jakarta/webbeans-impl/src/main/java/org/apache/webbeans/container/BeanManagerImpl.java#L37
Done that on last friday already :)
LieGrue,
strub
> Am 08.05.2019 um 14:21 schrieb Arne Limburg
<arne.limb...@openknowledge.de>:
>
> 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/>
>
>
>
>
