[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms
|
Hi Kenji,
Thanks for expanding the scenarios.
In my view I feel fundamentally how to handle the 2 scenarios is really a market driven decision rather than a specification decision. Therefore the answer to each scenario is market driven rather than spec driven.
For example if the number of customers in the market demanding support for scenario (1) is large, vendor(s) will support running Jakarta EE 8 apps on their latest release whatever the Jakarta EE 9 spec says.
For scenario 2 if there is a long tail of customers that are prepared to purchase long EOL dates for Jakarta EE 8 apps vendor(s) will offer this option on their latest releases.
The reason I say it is market driven rather than spec driven is if you flip this argument around and drive this via spec and state in the spec " Jakarta EE 9 app servers MUST support Jakarta EE 8 apps unchanged" then if there are no customers willing to pay for this compatibility burden then vendors will not build Jakarta EE 9 products. Also it is not possible for a new vendor to build a compatible implementation that is Jakarta EE 9 only to drive Jakarta EE 9 adoption and market share.
Steve
-----Original Message-----
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Kazumura, Kenji
Sent: 30 May 2019 11:03
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms
Steve,
I 'm not sure other country, but it likely happens in Japan.
(1) A vendor provides a Jakarta EE 9 product which run with Java SE 13, and a customer want to use Java SE 13 features (but not want to use Jakarta EE 9 new features).
In this case, this customer must use Jakarta EE 9 product, unless we provide Jakarta EE 8 product which run with Java SE 13.
(2) The customers, who wants a long term support, usually select the newer version product.
For example, the date of EOL for Jakarta EE 9 product is later than the one for Jakarta EE 8.
They select Jakarta EE 9 product because they want to use it as long as possible.
-Kenji Kazumura
> -----Original Message-----
> From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
> [mailto:jakarta.ee-spec.committee-bounces@xxxxxxxxxxx] On Behalf Of
> Steve Millidge (Payara)
> Sent: Thursday, May 30, 2019 6:48 PM
> To: Jakarta specification committee
> <jakarta.ee-spec.committee@xxxxxxxxxxx>
> Subject: Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms
>
> Hi Kenji,
>
> I may have missed something subtle in your email but if the customer
> is not using any Jakarta EE 9 features then don't they just have a Jakarta EE 8 app and therefore can't they just use the Jakarta EE 8 bom?
>
> Steve
>
> -----Original Message-----
> From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
> <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Kazumura,
> Kenji
> Sent: 30 May 2019 08:07
> To: Jakarta specification committee
> <jakarta.ee-spec.committee@xxxxxxxxxxx>
> Subject: Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms
>
> Assume that you have an existing Jakarta EE 8 app, and you want to
> change just your own business logic, but you don't want to use any new features in Jakarta EE 9.
> You don't need to change the package names in your source code when
> using incremental bom, while you need to change all the package names in your source when using big bang bom.
>
> If we choose the big bang approach, this type of customers do not have motivation to use Jakarta EE 9.
> My concern is, if a vendor has a lot of this type of existing
> customers, this vendor also does not have motivation to provide Jakarta EE 9 products.
>
> -Kenji Kazumura
>
>
> > -----Original Message-----
> > From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
> > [mailto:jakarta.ee-spec.committee-bounces@xxxxxxxxxxx] On Behalf Of
> > Bill Shannon
> > Sent: Thursday, May 30, 2019 6:10 AM
> > To: Scott Stark <sstark@xxxxxxxxxx>
> > Cc: Jakarta specification committee
> > <jakarta.ee-spec.committee@xxxxxxxxxxx>
> > Subject: Re: [jakarta.ee-spec.committee] Incremental vs Big Bang
> > boms
> >
> > If you have an existing app that's using the Jakarta EE 8 bom and
> > you update part of that app to use the new features in Jakarta EE 9,
> > e.g., the jakarta.ws.rs.Path class, you'll need to add something to
> > your app configuration to get access to the new API, either by
> > adding the entire Jakarta EE 9 bom or by adding the adding the new
> > Jakarta RESTful Web Services API pom.
> >
> > That's the same with Incremental or Big Bang.
> >
> >
> > Scott Stark wrote on 5/29/19 1:43 PM:
> > > Let's focus on javax.ws.rs.Path moving to jakarta.ws.rs.Path, and
> > > I have updated updated a Jakarta EE 8 app to
> > Jakarta EE 9 where the only change was in the REST spec. I expect that the Jakarta EE 9 bom will have:
> > > - under incremental, the jakarta.ws.rs.* + all unmodified javax.* spect artifacts.
> > > - under Big Bang, the jakarta.ws.rs.* + all jakarta.* spec artifacts that simply had a package name change.
> > >
> > > If I am using the incremental bom, I will only be able to compile
> > > my updated Jakarta EE 8 app if I have replaced
> > all of the javax.ws.rs.Path usage.
> > > If I am using the Big Bang bom, and I have only incrementally
> > > updated my app to what has functionally changed,
> > then I also need to include the Jakarta EE 8 bom. Any location where
> > I forgot to update javax.ws.rs.Path usage will be treated as Jakarta
> > EE 8 and the binary compatibility layer will kick
> in.
> > >
> > >> On May 29, 2019, at 12:56 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
> > >>
> > >>>
> > >>> If I have a Jakarta EE 8 app that is updated to use the new REST
> > >>> apis, it would need to include both Jakarta EE 8 and Jakarta EE
> > >>> 9 boms to compile the app. Do we envision having a compatibly
> > >>> bom such that there is a single bom a user could use to still
> > >>> build from source against? The concern here is that they
> > >>> intended to update all REST api usage to the Jakarta EE 9 apis,
> > >>> but missed some locations. If they have to include both Jakarta
> > >>> EE 8 and Jakarta EE 9 boms, this would be masked. If there was a
> > >>> Jakarta EE
> > >>> 9 compatibility bom, compiling against it would fail on the
> > >>> locations that did not update from JAX-RS to
> the Jakarta EE 9 REST apis.
> > >>
> > >> That would only be an issue with the incremental approach where
> > >> the bom would have the jakarta.rest.* APIs but not the javax.ws.rs.* APIs, right?
> > >>
> > >> If compatibility works by effectively "aliasing" the javax names
> > >> to the jakarta names, an app, or even a class, could mix and
> > >> match javax names and jakarta names and still work. (Whether
> > >> fine grained mixing is a good idea is a separate issue. :-))
> > >> And yes, it would need to depend on the appropriate bom(s) or pom(s) to get access to the APIs it needs.
> > >>
> > >>
> > >> Whether there's a "compatibility bom" and what it's called would
> > >> seem to depend on whether compatibility is a Jakarta EE spec of
> > >> some sort or whether it's left completely to products to provide.
> > >> In any event, there would continue to be the Jakarta EE 8 bom.
> > >
> > _______________________________________________
> > jakarta.ee-spec.committee mailing list
> > jakarta.ee-spec.committee@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
>
>
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
