2022-01-14 07:58:10.511  WARN 9723 --- [           main] ory$DuplicateJsonObjectContextCustomizer : 

Found multiple occurrences of org.json.JSONObject on the class path:

    jar:file:/home/vscode/.gradle/caches/modules-2/files-2.1/org.json/json/20090211/c183aa3a2a6250293808bba12262c8920ce5a51c/json-20090211.jar!/org/json/JSONObject.class
    jar:file:/home/vscode/.gradle/caches/modules-2/files-2.1/com.vaadin.external.google/android-json/0.0.20131108.vaadin1/fa26d351fe62a6a17f5cda1287c1c6110dec413f/android-json-0.0.20131108.vaadin1.jar!/org/json/JSONObject.class

You may wish to exclude one of them to ensure predictable runtime behavior

I think that spring-boot-actuator-autoconfigure (tests) depend on

  • com.datastax.oss:java-driver-core brings in a whole mess of things including org.json:json:20090211
  • com.vaadin.external.google:android-json directly

Possibly some pruning of the datastax dependency would help.

Comment From: wilkinsona

Thanks, Dave.

We have dependencies on org.json:json in the following modules:

  • spring-boot-actuator
  • spring-boot-actuator-autoconfigure
  • spring-boot-autoconfigure
  • spring-boot-docs
  • spring-boot-starter-data-cassandra
  • spring-boot-starter-data-cassandra-reactive
  • spring-boot-test-autoconfigure
  • spring-boot-test-support

In each case, it's a transitive dependency of com.datastax.oss:java-driver-core. The dependencies in the two starter modules will affect users.

Of the above modules, the following also have a dependency on com.vaadin.external.google:android-json:

  • spring-boot-actuator
  • spring-boot-actuator-autoconfigure
  • spring-boot-docs
  • spring-boot-test-autoconfigure

None of these will affect users as they're all on the test compile or test runtime classpath.

We also have a dependency on com.vaadin.external.google:android-json in the compile classpath in spring-boot-test and, therefore, in spring-boot-starter-test as well. This will affect users. If they combine spring-boot-starter-test with one of the Cassandra starters they end up with duplicate classes on the classpath and the warning shown above will be logged when they run their app's tests.

I think we should try to avoid the duplicate JSON classes when the starters are combined. However, that's easier said than done as android-json contains only a subset of org.json:json and org.json:json has an awkward licence which is why we avoid depending upon it directly.

Related issues: #5929, #8706

Comment From: philwebb

I wonder if org.json can be safely excluded. Looking at https://github.com/datastax/java-driver/commit/ca8de6ac15d7e0a15f5476f35481b417f823afc0 it appears that it was added to upgrade the version used in Esri. That recently changed to an optional dep (see https://github.com/datastax/java-driver/pull/1575) but org.json wasn't changed to optional. I can't find any org.json imports in the core driver code.

I would raise an issue with them, but they use JIRA and it won't let me log in currently.

Comment From: wilkinsona

Thanks, Phil. I can log in, but the issue creation wizard isn't working as I get a spinner in the bottom-right corner where a button should be.

@adutra Per Phil's analysis above, would it be possible for the Java Driver's org.json:json-api dependency to be made optional?

Comment From: adutra

Thanks for the heads up!

@absurdfarce this could be indeed added to your current work on https://github.com/datastax/java-driver/pull/1580. If org.json:json-api is only needed by Esri, then it should be made optional as well, which hopefully would solve our Spring friends' issue.

The reason why this transitive dependency is still showing up is here: https://github.com/datastax/java-driver/commit/ca8de6ac15d7e0a15f5476f35481b417f823afc0.

Comment From: absurdfarce

I can confirm that the changes in https://github.com/datastax/java-driver/pull/1580 cause org.json:json to be marked as an optional dependency as well. When we made Esri an optional dependency the transitive deps it brought along with it were also marked as optional... and that's how org.json:json gets into the core and shaded JAR deps.

Comment From: wilkinsona

This has been fixed in 2.7 by the Cassandra 4.14 upgrade. I don't think we risk destabilising things by doing anything in 2.6.x.