Desugar opentelemetry-sdk-common for android failed

[hangqiu]

Describe the bug
Using bazel to build android apps using the opentelemetry-api. Build failed with error below:

Desugaring v1/https/repo1.maven.org/maven2/io/opentelemetry/opentelemetry-sdk-common/1.2.0/opentelemetry-sdk-common-1.2.0.jar for Android failed: (Exit 1): desugar_java8 failed: error executing command bazel-out/k8-opt-exec-50AE0418/bin/external/bazel_tools/tools/android/desugar_java8 ... (remaining 1 argument(s) skipped)

A more general question, is there any android example using opentelemetry?

Steps to reproduce
relevant WORKSPACE file:

RULES_JVM_EXTERNAL_TAG = "4.0"

RULES_JVM_EXTERNAL_SHA = "31701ad93dbfe544d597dbe62c9a1fdd76d81d8a9150c2bf1ecf928ecdf97169"

http_archive(
name = "rules_jvm_external",
sha256 = RULES_JVM_EXTERNAL_SHA,
strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG,
url = "https://github.com/bazelbuild/rules_jvm_external/archive/%s.zip" % RULES_JVM_EXTERNAL_TAG,
)

load("@rules_jvm_external//:defs.bzl", "maven_install")

maven_install(
artifacts = [
"io.opentelemetry:opentelemetry-api:1.+",
"io.opentelemetry:opentelemetry-context:1.+",
"io.opentelemetry:opentelemetry-sdk:1.+",
"io.opentelemetry:opentelemetry-sdk-common:1.+",
"io.opentelemetry:opentelemetry-sdk-trace:1.+",
"io.opentelemetry:opentelemetry-exporter-otlp:1.+",
"io.opentelemetry:opentelemetry-exporter-otlp-trace:1.+",
],
repositories = [
"https://maven.google.com",
"https://repo1.maven.org/maven2",
"https://jcenter.bintray.com",
],
)

relevant BUILD file
android_binary(
name = "blablabla",
srcs = glob([
"/*.java",
]),
assets = glob(["assets//"]),
assets_dir = "assets/",
custom_package = "blablabla.blablabla.blablabla",
manifest = "AndroidManifest.xml",
nocompress_extensions = ["tflite"],
resource_files = glob(["res/**/"]),
deps = [
"@maven//:io_opentelemetry_opentelemetry_sdk",
"@maven//:io_opentelemetry_opentelemetry_sdk_common",
"@maven//:io_opentelemetry_opentelemetry_sdk_trace",
"@maven//:io_opentelemetry_opentelemetry_exporter_otlp",
"@maven//:io_opentelemetry_opentelemetry_exporter_otlp_trace",
"@maven//:io_opentelemetry_opentelemetry_context",
"@maven//:io_opentelemetry_opentelemetry_api",
],
)

What did you expect to see?
A clear and concise description of what you expected to see.

What did you see instead?
A clear and concise description of what you saw instead.

What version and what artifacts are you using?
see above

Environment
Compiler: android studio 4.2 RC1
OS: Ubuntu 18.04"

Additional context
Add any other context about the problem here.

[jkwatson]

Hi @hangqiu . We don't have any Android experts around here right now, but we desperately need some. I've started messing around a little bit with it, but I haven't done very much yet.

Can you explain what this error means, and how we might correct it?

[hangqiu]

Hi @jkwatson Thanks for quick response. I'm not an android expert either :-) But I found a similar issue here: bazelbuild/bazel#11618. Looks like the library has some primitive type that didn't pass the desugaring process. Hope this thread helps

[anuraaga]

@jkwatson Did you use sdk-common in your recent Android tests? Wondering if this issue is Bazel-specific and works with gradle-android-plugin.

[jkwatson]

@jkwatson Did you use sdk-common in your recent Android tests? Wondering if this issue is Bazel-specific and works with gradle-android-plugin.

Well, it was definitely pulled in by the SDK, so yes! I have not done anything with bazel at all, but it sounds like maybe I should add it to my experiments.

[jkwatson]

Everything I have done so far works great with the Android gradle plugin, android studio, etc. I would guess this is a bazel issue, and not anything in particular about sdk-common. sdk-common does have a multi-release jar, though. I wonder if bazel doesn't grok them?

[anuraaga]

@hangqiu Would you be able to file an issue with Bazel? Based on @jkwatson's investigation, it seems the desugaring works fine with this library with the standard Android toolchain so it seems like an issue in that tool specifically.

[hangqiu]

@jkwatson If it's a multi-release jar, is there a way to specify a particular release in the dependency BUILD file?

[jkwatson]

@jkwatson If it's a multi-release jar, is there a way to specify a particular release in the dependency BUILD file?

The way multi-release jars work, the right version should be automatically picked up by the JVM at runtime. If you're using java 8, you'll get that version of the code, and if you're using 9+, you'll get that version of the code. It's not a dependency thing.

[hangqiu]

Ah you meant the jar version. As you can see from the log, it’s using java8 and SDK-common v1.2.0. If the version specified is 1.+ then the latest would be picked up.

[jkwatson]

Ah you meant the jar version. As you can see from the log, it’s using java8 and SDK-common v1.2.0. If the version specified is 1.+ then the latest would be picked up.

No, a multi-release jar has code to support multiple versions of a JVM inside it. It has code for both java 8 and for java 9+. Crack open the sdk-common jar and take a look inside it and you should be able to see how it's structured. Baeldung also has a good primer: https://www.baeldung.com/java-multi-release-jar

[jkwatson]

I think this is probably a bazel issue. I've been having no problem with this in the standard android gradle plugins. Closing for now. If there's something specific we can do to make things more bazel-friendly, please re-open.