I strongly suspect Oracle will need to provide backward
compatibility as well.
And if someone creates some reusable open source code to do the
application transformation, the burden of providing that backward
compatibility would be low.
I think the question is whether having two kinds of branded Jakarta
EE Compatible products - one that can make use of the existing
ecosystem of applications and libraries, and one that can't - is
better for the Jakarta EE brand, or whether it will bifurcate the
brand in a way that reduces its value.
I suspect backward compatibility is going to be essential to
introducing the Jakarta EE brand to the market and making it
successful. Once it's clearly successful, and the majority of the
ecosystem has made the transition, backward compatibility may no
longer be needed. The fact that the major vendors will almost
certainly provide that backward compatibility, whether its required
or not, may be sufficient. And the lack of that backward
compatibility may be a competitive disadvantage. Maybe that's
enough and a requirement isn't necessary?
Kevin Sutter wrote on 4/18/19 8:29 AM:
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
_______________________________________________
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
|
