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

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

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