You are right, that we don't need to do anything. But thinking about the 
possibilities of the implementations maybe can give a good input to the API 
discussion.

When we would come to the conclusion that it would be no problem for any 
Java-EE-Implementation to support both package names at the same time,
the discussion would probably go into another direction.
IF every implementation could support both packages without much effort it 
probably would be the cleanest way for both users and implementors to 
completely separate both APIs. The old code would keep on working and users 
could migrate whenever they want, at least since they want to use new features.

But maybe is CDI the wrong example to explore that, because on the one hand 
there will be no new spec version in the short future and on the other hand it 
is mainly interface- and annotation-based. So probably it would be easier for 
CDI implementations to support both packages than for other implementations.

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

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, 14:47 schrieb "Romain Manni-Bucau" <rmannibu...@gmail.com>:

    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/>
    >
    >
    >
    >
    >


Reply via email to