Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

I 100% agree. This is an area that should be left to implementor innovation while the specification focuses on end user expectations.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Bill Shannon <bill.shannon@xxxxxxxxxx>
Date: 5/9/19 4:02 AM (GMT+08:00)
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>, Scott Stark <starksm64@xxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

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

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.

On Wed, May 8, 2019 at 12:36 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
On May 8, 2019, at 12:52 AM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

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?


jakartaee-platform-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

jakartaee-platform-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top