Unable to use in a Java EE 8 environment (javax.json vs. jakarta.json) about elasticsearch-java HOT 4 CLOSED

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.

from elasticsearch-java.

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.*

from elasticsearch-java.

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?).

from elasticsearch-java.

@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.

from elasticsearch-java.