Jaxrs-api: Rename packages javax.* to jakarta.*

[mkarg]

As the trademark negotiations between the Eclipse Foundation and Oracle failed, I suggest we should immediately rename all packages from javax.* to jakarta.*.

[mkarg]

@eclipse-ee4j/eclipse-jaxrs All JAX-RS committers please vote ASAP by posting a comment with +1 / 0 / -1. Thanks.

[arjantijms]

+1 rename swiftly, rename fast, rename completely.

A quick internal discussion among several JSF committers revealed the exact same wish.

[chkal]

+1 for renaming quickly. This will also allow us to finally provide snapshots.

[jansupol]

Let me provide some context, before the vote, mainly taken from the only source given to us.

Jakarta EE specifications that continue to use the javax package namespace must remain TCK compatible with the corresponding Java EE specifications.

There are different opinions on what it means to remain TCK compatible. While some say it is ok to mix jakarta namespace for additions with original javax, because signature tests do not fail as they do not know the new API packages, other say this is still a violation to the TCK compatibility. Not being a lawyer, I would assume the worse, that we could not append a new API within an additional jakarta package. Of course, that means we cannot add new features within javax namespace.

Jakarta EE component specifications using the javax package namespace may be omitted entirely from future Jakarta EE Platform specifications.

If we keep a single class within javax namespace, we can end up booted from the Jakarta Platform.

implementations which claim compliance with any version of the Jakarta EE specifications using the javax namespace must test on and distribute containers which embed certified Java SE implementations licensed by Oracle.

This potentially means we lose customers if we keep a single class within javax namespace.

Conclusion:

If this is true, I am +1 for renaming.

[m-reza-rahman]

I think it is best to verify things with the Eclipse Foundation and not
make assumptions one way or the other. After all, that is why they are
there. Is there someone here from the Eclipse Foundation that can comment?

On 5/5/2019 6:07 AM, jansupol wrote:
>

Let me provide some context, before the vote, mainly taken from the
only source
https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/
given to us.

Jakarta EE specifications that continue to use the javax package
namespace must remain TCK compatible with the corresponding Java
EE specifications.

There are different opinions on what it means to remain TCK
compatible. While some say it is ok to mix jakarta namespace for
additions with original javax, because signature tests do not fail as
they do not know the new API packages, other say this is still a
violation to the TCK compatibility. Not being a lawyer, I would assume
the worse, that we could not append a new API within an additional
jakarta package. Of course, that means we cannot add new features
within javax namespace.

Jakarta EE component specifications using the javax package
namespace may be omitted entirely from future Jakarta EE Platform
specifications.

If we keep a single class within javax namespace, we can end up booted
from the Jakarta Platform.

implementations which claim compliance with any version of the
Jakarta EE specifications using the javax namespace must test on
and distribute containers which embed certified Java SE
implementations licensed by Oracle.

This potentially means we lose customers if we keep a single class
within javax names.

Conclusion:

If this is true, I am +1 for renaming.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/eclipse-ee4j/jaxrs-api/issues/760#issuecomment-489369313,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3ULSWEGYCKU6KDM7UTEHDPTYCJRANCNFSM4HKVFGXQ.

[jansupol]

My interpretation goes further:

Since JAX-RS is using Servlet API, and I am not aware of any renaming activity on Servlet if Servlet won't evolve then JAX-RS is still using the javax namespace if it uses javax.servlet?

[mkarg]

@waynebeaton Can you please comment the raised questions? Thanks.

[chkal]

Since JAX-RS is using Servlet API, and I am not aware of any renaming activity on Servlet if Servlet won't evolve then JAX-RS is still using the javax namespace if it uses javax.servlet?

Please note that Servlet isn't a compile-time dependency of the JAX-RS API. So whether Servlet stays in the javax namespace or not isn't really relevant for us. At least if I understand it correctly.

[mkarg]

We need to differentiate between our renaming of the namespace we live in, and possible renamings of the namespace we are dependent of. My plan is to provide a PR which has separate commits for that, as I assume that it will change over time: There might be dependencies that change their namespace earlier, other might change them later, or never at all. But we have to rename our namespace immediately.

[chkal]

Maybe I'm missing something, but AFAIK the only javax.* package we depend on is javax.xml.bind.

https://github.com/eclipse-ee4j/jaxrs-api/blob/fd8b006a7aa80e14571a122698979ef904c0474f/jaxrs-api/src/main/java/module-info.java#L17-L33

[chkal]

I highly recommend everyone to have a look at this great blog post by @nmcl. I don't agree to all the arguments mentioned in this post, but it is definitely worth reading it!

[jansupol]

But we have to rename our namespace immediately.

As we were informed, the options should be revealed the upcoming week. It can be clear the renaming is the best option, eventually, but I believe we should know our options first. After so many months of waiting for the Agreement to be signed, waiting a few more days for our options does not seem like something not to withstand.

[jansupol]

Maybe I'm missing something, but AFAIK the only javax.* package we depend on is javax.xml.bind.

Note that Specification is not just API.

[mkarg]

To be prepared for the worst case, I have started a draft #761 to collect the needed changes in one single PR.

[chkal]

Note that Specification is not just API.

Agreed! But fortunately the API doesn't depend on the Servlet API directly and the spec doesn't mention the Servlet package name, so AFAIK both are not affected by a potential update of the Servlet package name. But of course the TCK needs to be updated in this case.

[jansupol]

For completness, let's see what is mentioned in javax namespace:
javax.activation.DataSource
javax.xml.transform.Source
javax.xml.bind.JAXBElement
javax.validation.ValidationException
javax.xml.ws.Provider

[bshannon]

@jansupol,

Let me provide some context, before the vote, mainly taken from the only source given to us.

Jakarta EE specifications that continue to use the javax package namespace must remain TCK compatible with the corresponding Java EE specifications.

There are different opinions on what it means to remain TCK compatible. While some say it is ok to mix jakarta namespace for additions with original javax, because signature tests do not fail as they do not know the new API packages, other say this is still a violation to the TCK compatibility. Not being a lawyer, I would assume the worse, that we could not append a new API within an additional jakarta package. Of course, that means we cannot add new features within javax namespace.

It's more complicated than that. You could mix existing javax.* APIs with new jakarta.* APIs in the same spec, but the new jakarta.* APIs can't have any effect on the existing javax.* APIs that would change the behavior of those existing javax.* APIs. That's probably not an acceptable restriction so mixing is not a great choice.

Jakarta EE component specifications using the javax package namespace may be omitted entirely from future Jakarta EE Platform specifications.

If we keep a single class within javax namespace, we can end up booted from the Jakarta Platform.

No, that is not the intent of that statement.

For most specs, you have to keep all the javax APIs or none of them (defined by the spec, not used by the spec). Dependencies on other javax.* APIs are ok, even if the spec renames its APIs to jakarta.*.

The above says that that's not true for the platform spec; the platform spec can omit some (entire) javax APIs.

implementations which claim compliance with any version of the Jakarta EE specifications using the javax namespace must test on and distribute containers which embed certified Java SE implementations licensed by Oracle.

This potentially means we lose customers if we keep a single class within javax namespace.

Keeping a single class is not an option. You keep all of them, or none.

Note that nothing requires you to distribute a Java runtime, but if you do it has to be a compatible Java runtime.

[spericas]

On May 5, 2019, at 11:28 AM, jansupol [e-mail] wrote:

For completness, let's see what is mentioned in javax namespace:
javax.activation.DataSource
javax.xml.transform.Source
javax.xml.bind.JAXBElement
javax.validation.ValidationException
javax.xml.ws.Provider

How did you produce this list?

— Santiago

[jansupol]

@spericas Search for javax in the Specification PDF.

[asoldano]

But we have to rename our namespace immediately.

As we were informed, the options should be revealed the upcoming week. It can be clear the renaming is the best option, eventually, but I believe we should know our options first. After so many months of waiting for the Agreement to be signed, waiting a few more days for our options does not seem like something not to withstand.

I agree on waiting few more days if that's going to provide more information for making a proper choice.

[mkarg]

One more week is over. How long do we like to wait? This is a showstopper for JAX-RS 2.2.

[mkarg]

Another week is over, and it doesn't seem like a conclusion will get found. I'm +1 for not waiting longer but simply rename the master branch right now, as it already contains changes to the API.

[chkal]

I'm +1 for not waiting longer but simply rename the master branch right now, as it already contains changes to the API.

+1

[asoldano]

+1 Well, yes, considering the API has indeed been changed on master, I haven't heard of any alternative to renaming packages.

[spericas]

Although I think this is ultimately the right way to go, it's probably better to wait for the community discussion to reach an agreement before starting to rename packages.

https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html

[mkarg]

@spericas Waiting for actually what? As we already modified master's signature, that branch must get renamed - independent of which proposal wins.

[spericas]

@mkarg I just think it's better to wait until this discussion is finalized in case something changes. Is anyone really eager to consume the renamed API right away?

[mkarg]

@spericas Yes we're eager to consume it as we're working actively on a new application at the moment.

[jansupol]

I believe a new release should be performed the right way. It's version 2.2, so it corresponds to a JAX-RS (or whatever the name) 2.2. That is a new Spec, it should be released along with the updated Spec pdf, and since it is in Jakarta, it should follow the Jakarta Spec process.

Releasing just an API without following the process would result in an unapproved non-Jakarta API, IMO. Maybe it would be possible to release a snapshot, but not a final API.

[mkarg]

@jansupol I agree with that, but what I immediately need is not a release, but a is a way to go on, and that way can only be to have nightly builds of the renamed packages, to be sure, that the application I develop today will run with Jakarta-RS 2.2 once it is officially released later this year. It definitively is no option for application programmers to wait and wait and wait endless for an outcome that is absolutely predictable: Renamed packages.