Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms

["Kazumura, Kenji" <kzr@xxxxxxxxxxxxxx>]

Steve,

I do not deny market driven.
But the cost which a vendor pay for market demands may depend on a specification decision.

Because the main target of Jakarta EE will be the customers who are using Java EE now,
the compatibilities are high priority to decide a specification.
We should create the specification which encourages these existing customers to use Jakarta EE.

-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 7:37 PM
> To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
> Subject: 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
> _______________________________________________
> 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