Unable to use in a Java EE 8 environment (javax.json vs. jakarta.json)

[matthiaswelz]

The co.elastic.clients.json.JsonpMapper class already uses the "new" jakarta.json.* classes (which are implemented in org.glassfish:jakarta.json). This causes an issue when trying to use the elasticsearch client in an environment which still has the "old" implementation org.glassfish:javax.json on the classpath (which is the case for most if not any Java EE 8 application server).

This is because there is a class "org.glassfish.json.JsonProviderImpl" in both org.glassfish:javax.json and org.glassfish:jakarta.json. One uses javax.json classes and the other one uses jakarta.json classes.

The elastic client now (in class JsonValueParser) simply calls jakarta.json.spi.JsonProvider.provider() which basically calls:

Class.forName("org.glassfish.json.JsonProviderImpl");

However, in an Java EE 8 environment, this will return the JsonProviderImpl from org.glassfish:javax.json because the classes unfortunately share the same name and package.

During runtime, this will lead to an exception:

jakarta.json.JsonException: Provider org.glassfish.json.JsonProviderImpl could not be instantiated: java.lang.ClassCastException: org.glassfish.json.JsonProviderImpl cannot be cast to jakarta.json.spi.JsonProvider

I have created a post on StackOverflow to ask if there is any possibility to use both in the same application. However, I do not expect there to be a solution unless the implementation of the "new" "org.glassfish.json.JsonProviderImpl" (in org.glassfish:jakarta.json) is moved to a different package or renamed. (I am also not sure why the authors of org.glassfish:jakarta.json chose to reuse the same package and class name for the new version).

However, in order to use the Elastic Client in Java EE 8 environments, there should be some sort of workaround for the time being: Maybe there could be two builds - one using the jakarta.json.* classes and one using the javax.json.* classes (or potentially using the maven shade plugin).

Any ideas?

[matthiaswelz]

I have posted a workaround involving the use of the Maven shade plugin to Stackoverflow.

On the stackoverlow thread, it was suggested

Can't you just pick an Elasticsearch version suitable for your environment?

Does that mean that the elasticsearch-java client is not meant to be used with Java EE 8?

Right now, there is unfortunately no alternative to Java EE 8 for many business applications as Java EE 9 is still in preview stage for most (if not all?) application servers. Also, migrating from Java EE 8 to Java EE 9 is not trivial because Java EE 9 is not backwards compatible to Java EE 8.

For example, Hibernate Validator takes the following approach:

Jakarta EE 9 is an iterative release on top of EE 8 with the main purpose of renaming all the javax. packages to the jakarta. packages.

For a while, we will provide equivalent Hibernate Validator versions for both EE 8 and EE 9: Hibernate Validator 6.x will keep the javax. packages while Hibernate Validator 7.x moved to the jakarta. packages.

Full transition in the Java ecosystem will take months if not years given how many libraries depend on the javax. packages, that’s why we will maintain both in parallel and why we are releasing two new versions today.*

[swallez]

Thanks for the report @matthiaswelz. The Java client is meant to be compatible with Java8+, including Java EE 8, but also looking forward, hence the use of the newer jarkarta.json base package.

I agree with you that Glassfish using the same class for implementations of javax.json and jakarta.json is a strange decision.

The context here is a bit different from that of Hibernate Validator as the purpose of elasticsearch-java is not to provide an implementation of a JEE spec and our versioning follows that of Elaticsearch versions.

I see two approaches to solving this:

• shade Glassfish (the jakarta.json variant) and include it in the elasticsearch-java jar file, so that it doesn't conflict with the javax.json variant from Java EE 8
• release two artifacts, one targeting jakarta.json and another targeting javax.json.

I'm leaning towards the first approach, as we can expect that jakarta.json will evolve in the future while javax.json will not. This will also avoid having to publish two different artifacts and asking users to make the choice between those.

[matthiaswelz]

Another strange thing: The maven website for the artifact org.glassfish:jakarta.json lists version 2.0.1 as current and links to https://github.com/eclipse-ee4j/jsonp .

However, the source code in that repository does not seem to include the actual implementation and the maven coordinates are different too: jakarta.json:jakarta.json-api.

Funnily enough, the JsonProvider in that repository specifies the following default provider:

private static final String DEFAULT_PROVIDER = "org.eclipse.jsonp.JsonProviderImpl";

Not sure what's going on here - but it appears to me that there seem to be multiple artifacts claiming to be the "official" one. Also, I don't know which artifact provides the org.eclipse.jsonp.JsonProviderImpl class.

Are you sure the org.glassfish:jakarta.json is actually the "right" artifact to include to use the JSON-P API?

Maybe using jakarta.json:jakarta.json-api together with an appropriate implementation (if existing?) would be a better alternative to shading. But also not sure if that will actually solve the issue or will introduce similar issues if one happens to have a javax.json-version of org.eclipse.jsonp.JsonProviderImpl on their classpath (if that exists?).

[swallez]

@matthiaswelz I found out that Glassfish JSON-P, in its jakarta.json variant, now exists as Eclipse Parsson.

I've updated the project dependencies in PR #63, which should solve compatibility issue with JEE8.

As a workaround until the next release, you may filter out Glassfish from Elasticsearch-Java's dependencies in your project and add Parsson as a replacement.