Here's a message I sent to the Spec Committee 3 weeks ago that
includes some of the questions we would need to answer about the
compatibility requirements:
I strongly support the approach of *not* requiring *how* to implement
Jakarta EE 8 compatibility in Jakarta EE 9. The spec should require
that Jakarta EE 8 applications can be deployed without change. Whether
the implementation transforms the application at deployment time,
transforms it at runtime, provides separate implementations of the
Jakarta EE 8 APIs, or uses some other approach, should all be allowed.
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.
Finally, 100% compatibility is probably impossible. We're going to need
to decide what level is acceptable.
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?
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?
Scott Stark wrote on 5/8/19 12:50 PM:
This tension between compatibility and trying to make a
decision on how an initial move away from javax namespace APIs
keeps coming up, and during today's spec committee call this
was brought up and it was suggested that perhaps we need to
define a taxonomy of compatibility modes, as Dan Bandera
termed it, and relate those modes to the namespace change
options. I was going to try to take a stab at doing this. As
much as we would like to make the namespace change approach
separable from compatibility concerns, unless that is clearly
illustrated as possible they will need to be treated together
as that is how most people are viewing this javax to jakarta
transition issue.
thanks for starting to curate the feedback.
However I take issue with the following:
It
is envisioned binary compatibility can be
achieved and offered by implementations via
tooling that performs bytecode modification
at either build-time, deploy-time or
runtime. While
there are open questions and
considerations in this area, the primary
goal of the discussion that must conclude
is how do we move forward with future
modifications to the APIs themselves.
Essentially
you are suggesting that these discussion should
exclude consideration of one of the most
significant impacts of this name change. This is
like voting for Brexit without have any idea what
a Brexit would look like or how it can be
implemented!
I never said exclude. We can talk about anything we
like just as long as we also make sure to reach a
decision on how to handle the namespace change in the
time we have. As you point out, reaching a decision on
that goal will logically involve a lot of groundwork.
Is that clearer and more in line with your thoughts?
-David
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
