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

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

Following up from today's conversation about Jakarta EE 8 compatibility...

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?