I'd
agree with Steve that it needs to be either 2 or 3.
Option 1 says that all Jakarta EE 9 implementations
*must* support binary compatibility. That requirement
would inhibit or prevent new implementations which only
want to start with Jakarta EE 9.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx
Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From:
Mark
Little <mlittle@xxxxxxxxxx>
To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:
05/31/2019
05:24 AM
Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Incremental vs Big Bang
boms
Sent
by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
Just because these are the
choices you’ve mentioned, I’d say 1 or 2. 3 has more
negative implications on the developer, e.g., they have
to hunt down whether an implementation has done this,
plus what does that say about “compatibility” if an
implementation isn’t, well, compatible? If a vendor
wants to go down that route then they could stay on v8.
Mark.
On 31 May 2019, at 10:50,
Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
I agree with the scenarios.
My view is where does the binary compatibility story
lie.
1) Should it be mandatory on all compatible
implementations as part of the Jakarta EE 9 platform
specification?
2) Should it be optional as part of the Jakarta EE 9
platform specification?
3) Should it be left as a vendor's decision?
My view is 3 or 2, specifically for the namespace
change.
Steve
-----Original Message-----
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Bill Shannon
Sent: 31 May 2019 00:38
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>; Kazumura, Kenji <kzr@xxxxxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Incremental vs
Big Bang boms
If the vendor's Jakarta EE 9 product provides binary
compatibility with Jakarta EE 8, the customer doesn't
need to do anything to run their existing Jakarta EE 8
app on the Jakarta EE 9 product and they can upgrade to
the new version of the product based on their own needs.
If the vendor doesn't provide Jakarta EE 8 binary
compatibility, then the customer needs to change
everything in their app that uses any API that's changed
in Jakarta EE 9 if they want to upgrade to the Jakarta
EE 9 version of the product. In the Incremental
approach, that would only be some subset of the APIs,
but almost certainly would include some APIs that the
customer is using. In the Big Bang approach, all uses
of Jakarta EE 8 APIs would need to be changed. In both
cases, this is independent of whether the customer wants
to use any new Jakarta EE 9 features. In both cases,
the customer would need to change their build
configuration to replace any reference to the Jakarta EE
8 bom with a reference to the Jakarta EE 9 bom.
With a good binary compatibility story, this change
doesn't make any difference to the customer.
Without a binary compatibility story, the customer is
forced to change their app when *we* change the APIs,
either a little bit every release, or all at once in
Jakarta EE 9.
Kazumura, Kenji wrote on 5/30/19 3:03 AM:
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
_______________________________________________
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
---
Mark Little
mlittle@xxxxxxxxxx
JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport
Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell
House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA),
Michael O'Neill, Keith Phelan, Matt Parson (USA)
_______________________________________________
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
