Jakarta package rename from javax

[Cousjava]

In order to make changes to the api we need to change the namespace to jakarta.

[lukasj]

what's the plan once this gets merged? How consumers, such as JSONB/Yasson/Jersey/EclipseLink/others, are supposed to adopt this change? Release jsonp 2.0 ASAP, so this won't disappear from staging (there's hard ~30days limit), rely on snapshots, have some say beta/milestone release or something else?

[aguibert]

JSON-B/Yasson committer here, I'd prefer to consume this change from Maven Central. It should probably be a 2.0.0.RC1 version thought to indicate it's not final. In my experience we are a lot more likely to get people actually trying out the RC if we put it on maven central and users don't need to faff about with their repository configs.

[keilw]

Is this coordinated with all the other specs? So far only Jakarta REST seems to be refactored. Whether that was done in coordination with PMC and others or a shot in the dark I can't say, but almost none of the others did that. If however the idea is to do JSON-P first so JSON-B could follow, where has that been stated? Also https://github.com/eclipse-ee4j/jsonp/milestones don't seem to reflect the current version in the POM which is "1.2-SNAPSHOT", based on the discusison here, why is it not "2.0-SNAPSHOT" or "2.0.0-SNAPSHOT", at least that one is defined in the milestones (I closed all the old 1.1.x ones that have no open issues)

[m0mus]

@lukasj I think that the best solution is to accept this PR and release 2.0-B1 so others can adopt it.

[keilw]

@m0mus Can you or @lukasj then approve it, I'd be happy to merge after that's possible?

[aguibert]

@keilw thanks for pushing this one through. Can you please post here and @mention me when there is some artifact for us to consume in JSON-B? (either a snapshot repo or maven central)

[m0mus]

Fixes https://github.com/eclipse-ee4j/jsonp/issues/219

[jjspiegel]

This change completely breaks backwards compatibility for json-p?

For example, in Oracle's JDBC driver, I allow end users to access JSON values using the javax.json values.

JsonObject obj = resultSet.getObject(1, javax.json.JsonObject.class);

I don't have control over when my consumers update their dependencies. This means that at some point I am going to have to depend on both APIs - jakarta.json and javax.json in order to not break my customers.

Why was this necessary?

[m0mus]

@jjspiegel Unfortunately Oracle didn't allow Eclipse Foundation to make changes in javax namespace. As part of the next (Jakarta EE 9) platform release all APIs packages will be moved from javax to jakarta namespace. Yes, it's not backwards compatible.

[jjspiegel]

@m0mus would it be possible to package javax.json under version 1.1 as a separate "product" rather than JSON-P reference implementation versioning? Currently, it is going to look as if we are depending on both the old and new version of the same product? Procedurally at Oracle, we are compelled by Corporate Architecture to stay on the latest version of our 3rd party dependencies. A separately packaged javax.json at version 1.1 would make this easier to manage.

[aguibert]

The new version will be under new maven coordinates, so your project could depend on javax.json:javax.json-api:1.1.4 and jakarta.json:jakarta.json-api:2.0. Is that what you mean by packaging as a separate "product"?

[m0mus]

@jjspiegel We at Oracle are getting bad karma back for not allowing using javax namespace. :) I guess that javax and jakarta versions of JSONP can be treated as separate products by CorpArch.

[jjspiegel]

@aguibert yes but why 1.1.4? Isn't current version of the JSON-P implementation 1.1 (i.e. JSR 374) My (possibly wrong) understanding is that javax.json 1.1. can't change without a new JSR.

[m0mus]

@jjspiegel there were no API changes since version 1.1. We are not using JCP since everything is moved to Eclipse Foundation. There is a new specification process called JESP (Jakarta EE Specification Process). More details about it here: https://jakarta.ee/about/jesp/

[leadpony]

Hi everyone

How about an idea that we build the new jakarta.json API by extending the old javax.json API ?

package jakarta.json;

public interface JsonObject extends javax.json.JsonObject {

    // Add new API methods here
    ...
}

jakarta.json.JsonObject can be passed in to any legacy code as a javax.json.JsonObject and the old type returned by the legacy code can be safely casted to the new one if the implementation of JsonProvider is based on jakarta.json API (a few exceptions are JsonValue.* static constants).

This design strategy achieves higher backward compatibility and we can also add new API as we like in jakarta.json package.

[jjspiegel]

@leadpony this would be much less disruptive and help ensure backwards compatibility. It would also allow legacy applications depending on JSON-P (that aren't easily changed) to continue to consume security fixes from the JSON-P reference implementation without modifying code.

[m0mus]

@leadpony It will be a mix of javax and jakarta packages and it's not what was recommended by Jakarta EE. We are following 'Big Bang' aproach which assumes complete elimination of javax and moving everything to jakarta namespace.

[leadpony]

@m0mus Thank you for quick reply. Now I understood the principle of the migration. I really hope that the reborn project is a better place for users and implementers who survive the Big-Bang.