Pom dependencies that should be "compile" are "runtime" about java-server-sdk HOT 7 CLOSED

That changelog item says that they changed utils.VersionUtils, which is not something that is referenced by the Java SDK, so I see no reason why you shouldn't be able to use a newer version.

LaunchDarkly is not the only library in my application that's using gson. I'm using other things that also use gson. protobuf (an indirect dependency of ours through some Google Cloud libraries we're using for BigQuery), for example, also uses gson. I can test that my own code doesn't call the affected methods, but it's going to be very difficult to tell if (at runtime) some part of some other library is going to want to call one of the affected methods. So it's best if I can allow my dependencies to specify their desired version of their dependencies.

Also, is there a reason you can't use the "all" distribution that bundles Gson and SLF4j?

The "all" distribution bundles gson and slf4j without shading them. The bundled version of slf4j is incompatible with our application, resulting in ClassCastExceptions.

from java-server-sdk.

@rkennedy-mode We've released version 4.10.1 which should fix the scope problem; the question about dependency ranges is something that we can revisit separately.

from java-server-sdk.

This is causing us active pain at the moment as we're having to manually manage which version of gson being used. dependabot then happily tells us it's behind v.latest and unhelpfully offers to upgrade us to gson v.latest, which potentially introduces a backwards incompatible change (see v2.8.5).

Compile fails even if you're not referencing any gson classes. Our code calls LDUser.Builder.custom(String, String) but the compiler complains because there's another version of that method that takes a gson JsonElement: LDUser.Builder.custom(String, JsonElement).

from java-server-sdk.

Could you say more about what you mean by "potentially introduces a backwards incompatible change"? That changelog item says that they changed utils.VersionUtils, which is not something that is referenced by the Java SDK, so I see no reason why you shouldn't be able to use a newer version. Since the SDK uses a fairly limited subset of Gson functionality and always uses it in the same ways, you should be able to tell right away whether there is actually a problem.

I know we still need to fix the dependency scopes, I'm just trying to understand why the current workaround is such a problem.

from java-server-sdk.

Also, is there a reason you can't use the "all" distribution that bundles Gson and SLF4j?

from java-server-sdk.

I believe we now know how to fix this. Apologies for the delay— we wasted a lot of time on the assumption that we were using the Shadow plugin incorrectly, but it seems like this is actually a known issue in Shadow and just has to be worked around. And then it fell off of our radar at some point last year because no one else had mentioned it. We should have a release with the fix shortly.

A related question: would it be better for the dependency to specify a range like [2.7,3.0) rather than the current specific version? The SDK should not care if another library prefers a later version of Gson as long as it's in the same major version. The only reason I'm hesitating to make that change is that then we would probably need to have a separate build for the "all" jar (the one that bundles Gson), retaining a specific version dependency there, because otherwise we would not have a reproducible build of that distribution.

from java-server-sdk.

Thanks for the fast turnaround, Eli!

from java-server-sdk.