Re: [jakarta.ee-spec.committee] Jakarta EE 8 compatibility

["Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>]

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?