In essence, this is the same problem as #29387.
I ran into this while upgrading an application that uses Jedis as Redis driver to Spring Boot 3.0.0-RC1:
Found multiple occurrences of org.json.JSONObject on the class path:
jar:file:/home/vpavic/.gradle/caches/modules-2/files-2.1/org.json/json/20220320/6df2c050972619466f6dcef7654ef9bcc01dfd0/json-20220320.jar!/org/json/JSONObject.class
jar:file:/home/vpavic/.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
Since its 4.0.0 release, Jedis pulls in org.json:json as a transitive dependency. At the same time, com.vaadin.external.google:android-json is pulled in by org.skyscreamer:jsonassert which in turn is a dependency of spring-boot-starter-test.
At quick glance, Jedis usage of org.json:json is limited to org.json.JSONArray and org.json.JSONObject classes (both of which are offered by com.vaadin.external.google:android-json) so one might be tempted to simply exclude org.json:json, but at the same time there's no guarantee that Jedis won't start using something outside of those two in the future.
Comment From: philwebb
I don't think there's much that we can do that won't make the situation worse. If we exclude the dependency then someone that doesn't happen to have com.vaadin.external.google:android-json will find their application doesn't start. We don't have a starter so we can't easily add com.vaadin.external.google:android-json ourselves.
I've opened https://github.com/redis/jedis/issues/3189 to see if the Jedis project could consider switching implementations or making org.json:json optional.