Thanks Kevin.
We will also likely provide backwards compatibility with Jakarta EE 8 for some but not all versions of our products.
However Jakarta EE 8 compatibility cannot be
mandatory to achieve the Jakarta EE 9 logo for the reasons I mention.
Steve
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Kevin Sutter
Sent: 18 April 2019 16:30
To: jakarta.ee-spec.committee@xxxxxxxxxxx
Subject: Re: [jakarta.ee-spec.committee] Jakarta EE 8 compatibility
Although from an IBM standpoint, we will most likely provide backwards compatibility with Jakarta EE 8, I can see Steve's point. Somebody on yesterday's
call also brought up the fact that we will (hopefully) have new implementations joining the fold at the Jakarta EE 9 timeline. So, if we're looking not to stifle innovation and promote new implementations, we can't require every Jakarta EE 9 implementation
to support Jakarta EE 8. I suppose this last statement depends on the final content of Jakarta EE 9, but you get the idea. If we're looking to promote this new Jakarta EE environment and encourage new implementations, then we can't start off by requiring
them to support all of the old technologies in Jakarta EE 8.
----- Original message -----
From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
To: Bill Shannon <bill.shannon@xxxxxxxxxx>, Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Cc:
Subject: Re: [jakarta.ee-spec.committee] Jakarta EE 8 compatibility
Date: Thu, Apr 18, 2019 1:22 AM
OK to simplify the Payara position on this.
We do not think compatibility with Jakarta EE 8 should be required for Jakarta EE 9.
Secondly all javax apis, property names, service loader files, schemas etc. in all specifications included in Jakarta EE 9 should be moved to the jakarta namespace.
Steve
-----Original Message-----
From: Bill Shannon <bill.shannon@xxxxxxxxxx>
Sent: 17 April 2019 21:27
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>; Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Jakarta EE 8 compatibility
Steve Millidge (Payara) wrote on 4/17/19 12:00 PM:
> Comments below
>
>
>> I strongly support the approach of *not* requiring *how* to implement Jakarta EE 8 compatibility in >Jakarta EE 9.
>
> +1
>
>> The spec should require that Jakarta EE 8 applications can be deployed without change.
>
> -1
> I could accept a profile of Jakarta EE 9 that imposed this requirement but not every profile. This should be a market driven requirement by the vendor not a requirement of the spec. The reason why is this imposes too much technical debt on any new vendor
that may wish to build on the work we do in Jakarta EE 9. We all want to create a new vibrant community around Jakarta EE 9 this requirement kills that stone dead.
Putting it in a profile is pretty much the same as making it optional.
If it's going to be optional, and some vendors aren't going to do it at all, do we really need to specify how it MUST work for vendors who do choose to provide it? Shouldn't it be up to each vendor to decide how much compatibility they need to provide based
on the demand from their customers?
>> That said, I think the idea of deployment time or runtime transformation is most interesting, and I >hope someone will build such a thing as an open source project (EE4J or otherwise) that many of us >can reuse in our implementations. It would be great
if someone would create such a community >project that we could contribute to.
>
> Interesting though this is intellectually this makes runtimes, slow, fragile and bloated. Everything that we are accused of and we've striven against. If we move all apis to jakarta namespace in Jakarta EE9 this also is likely technically unnecessary as Jakarta
EE 8 apps will use javax and Jakarta EE 9 apps jakarta.
I'm not sure what you think is unnecessary.
The point of doing a transformation is to allow the apps that use javax to be "linked" to the corresponding jakarta.* classes so that only one set of APIs and implementations is necessary.
>> Finally, 100% compatibility is probably impossible. We're going to need to decide what level is >acceptable.
>
> This statement goes against the requirement that Jakarta EE 8 applications can run unchanged.
Right, so we need to qualify the goal/requirement.
Presumably it's all *portable* applications.
Maybe it doesn't include applications that use reflection. Or applications that manipulate class loaders. Or applications that do some other things that are hard to support compatibly.
>> For example, can I mix and match use of javax.mail and jakarta.mail APIs in the same application? Can >I pass a jakarta.mail.Message object to a method that expects a javax.mail.Message object? Or must >they be distinct types?
>
> IMHO this is not a spec issue. Spec should be self contained and not refer to previous versions of the spec. Assuming we are going to move all apis to the jakarta namespace. We can't go to market with a Frankenstein api where whenever a class changes in the
future it is moved from one namespace to another and now we have to support both.
If the spec includes a compatibility requirement, then this absolutely is part of the spec.
>> And what about attributes that aren't part of the Java EE specs? As others have mentioned, can I >configure the javax.mail logger? Can I set a breakpoint in javax.mail.Message? Will my stack trace >include javax.mail.* APIs? Can I serialize a javax.*
object and deserialize it with a jakarta.* class?
>
> Again imposing requirements to support old dead apis in the spec with statements like these would kill innovation stone dead.
>
> Backwards source code compatibility and binary compatibility has been killed by lawyers. Let's not bake requirements into the Jakarta EE 9 specifications that kill future innovation.
>
> By all means compete on runtimes that support migration/compatibility if each vendor feels there is the customer demand.
And that's the decision to be made - is compatibility required, optional, or unspecified? The consensus in the meeting seemed to be that compatibility is required. Is that not really what people intended?
_______________________________________________
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
|
