Change min java/android version for SDK

[bogdandrutu]

The proposal is to increase the minimum java version and android api level only for the SDK (the API will remain the same, in order to allow gRPC to depend on opentelemetry-api).

The new proposed versions are (some details here https://developer.android.com/studio/write/java8-support):

• Java 8
• Android 24

I would like every vendor to comment on this.

[jkwatson]

New Relic strongly endorses this change! Thumbs way up!

[bogdandrutu]

Waiting for:

DD: @tylerbenson - DONE
LS: @tedsuo
MS: @SergeyKanzhelev
DT: @Oberon00 - PENDING
SK: @tigrannajaryan
NR: @jkwatson - DONE

[tedsuo]

I don't have the adoption numbers currently. But it is true is that we had Java 7 support in both OpenTracing and OpenCensus. Won't we be abandoning users if we do this? Those users will then demand continued support from OpenTracing and OpenCensus projects, which could hinder our ability to EOL those projects.

[bogdandrutu]

That is what I am asking, if we do abort users. In OpenCensus very few people (close to 0) use the implementation that is java7 compatible (almost everyone use the java8 version).

Are the OpenTracing implementations java7 as well?

[bogdandrutu]

@yurishkuro do you have an opinion here?

[tedsuo]

I’ll check our numbers. I queried the internet: https://twitter.com/opentelemetry/status/1215811993724055552?s=21

[Oberon00]

Java 7 vs 8 is an important issue for Dynatrace. We have some use cases where we might still need Java 7 support from the SDK. We are currently researching if these use cases are actually still needed by customers, but it may take us till next week to reach a decision here. I hope you are not in a rush for this issue?

We would be fine with the Android API level change though.

CC @arminru

[tylerbenson]

I strongly support this.

[bogdandrutu]

@Oberon00 I can definitely wait until next week, that's why I asked here and not changed directly the sdk :)

[tedsuo]

For vendors who are requesting Java 8: is this because you don't perceive the need for Java 7 support any longer, or is it because you plan to accomplish Java 7 support via another APM product?

I am getting push back from on high, to say that Java 7 support is critical for us. It would be helpful to have some data to support moving to Java 8. The version is officially retired, but the perception is that it still has broad adoption among larger enterprises. If there is a gartner report or other data source which supports this move, I would appreciate a link!

[jkwatson]

My thinking is this: Users of Java 7 are the least likely to be adopters of things like Open Telemetry. They are unlikely to want to update a monitoring library or use a brand new one if they aren't even willing to update their JDK to something that is at least under LTS.

[Oberon00]

@jkwatson I agree with you that users of Java 7 are not very likely to instrument their app with OpenTelemetry themselves. But there is the case of providing an auto-instrumenting agent that could be used without code modifications. For such an use case it may make sense to still support Java 7.

[tylerbenson]

@tedsuo I would like to point out that it seems Lightstep has never supported Java 7: lightstep/lightstep-tracer-java#213

[tedsuo]

@tylerbenson that issue a request for us to support java 7 natively, from our own sales engineering team. :)

It would be great to have evidence that industry is moving on. But I'm seeing signs that Java 7 is still sticky. If google is requiring that the API stays at 7 for their own support, and our sales team is pointing people our competitor (DataDog) to get Java 7 support... that's signs that the end user community is still on Java 7.

I would be interested in Java 8, mainly because it would improve the API quite a bit for our users. If we can't bump the API to Java 8, it seems wrong to bump the SDK to Java 8, and ship a java 7 API with no actual support?

FWIW. Oracle is planning to support Java 7 through 2022:

• https://spring.io/blog/2015/04/01/ongoing-support-for-java-7-and-even-java-6
• https://www.oracle.com/technetwork/java/java-se-support-roadmap.html

[tedsuo]

Basically, my question is: what would it take to move the API to Java 8, and then work on a backwards compatibility story for Java 7? If Java 7 support could be added later, I would be fine with not having it now.

[bogdandrutu]

API is not going to move soon to Java8. This issue is about the SDK. Maybe we can drop initially the android API level and stay at least at full java7 for SDK is a good initial step, then changing to java8 later.

[trask]

I tend to agree with @Oberon00's point above that Java 7 users are unlikely to manually instrument their apps, but may still want an auto-instrumentation solution.

Also, I think there's a lot more value in moving the API to Java 8 (which would provide value for users) than in moving the SDK to Java 8, so would opt to keep the SDK at Java 7 (and just bumping android API level 👍) until we can move them both to Java 8.

[carlosalberto]

we can drop initially the android API level and stay at least at full java7 for SDK is a good initial step, then changing to java8 later.

This sounds good to me (as an initial step).

[Oberon00]

(To follow up on #744 (comment):)
Staying at full Java 7 for now sounds fine. Moving to Java 8 would be a problem for Dynatrace as we discovered that we do indeed still require Java 7 support.

[jkwatson]

Can we get a show of thumbs on keeping java 7, but letting the android level requirement be dropped for now?

[lmineiro]

Disclaimer: Zalando is not an observability vendor.

Zalando operates a couple thousand services. A few hundreds of those have been around for quite some time and are still relevant for our business. Approximately 100 of them depend on Java7 and none of them are instrumented in code. We observe those "vintage" systems with the Opentracing java agent.

It was/is difficult to get the agent working without some considerable efforts from our teams. To name a few, we created custom builds of Lightstep's java tracer with Java7 and some of the agent plugins. We don't have an internal team with the purpose of maintaining any of them - it's a best effort. What we discovered with all of those customization efforts is that the Java8 requirement was not really there and just changing to Java 7 was enough - the code wasn't really using any of the Java8 features.

We intend to migrate to OTel and we expect some of those Java7 services to be around. Most likely, the agent approach will be adopted again.

Please take this comment as the contribution of an end-user, with a considerable footprint and investment in tracing, eager to adopt Opentelemetry.

[carlosalberto]

@lmineiro thanks for the feedback/info.

So it sounds we have initial agreement on sticking to Java 7 for now, while dropping the Android level, based also on the votes on @jkwatson comment.

Now we need a PR for updating the build ;)

[jkwatson]

@lmineiro Not criticizing here. Just trying to understand. You have services that you can upgrade the monitoring library, and even use a custom build of the monitoring library, but not upgrade the JVM that the code is running on? Can you explain the disconnect?

[lmineiro]

@jkwatson sure, no problem.
The mentioned 100 services would not run without occasional failures with recent JVMs. This was the result of thorough canary testing. The most common issues were misbehaving memory and GC pressure but also the eventual crash of the JVM. Some investigations pointed at the change in the HashMap implementation. We could've continued investigating all those issues or, eventually, put less effort into an alternative. All things considered, using the agent and adjusting the monitoring library was, for us, a good compromise.