-
Notifications
You must be signed in to change notification settings - Fork 829
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change min java/android version for SDK #744
Comments
New Relic strongly endorses this change! Thumbs way up! |
Waiting for: DD: @tylerbenson - DONE |
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. |
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? |
@yurishkuro do you have an opinion here? |
I’ll check our numbers. I queried the internet: https://twitter.com/opentelemetry/status/1215811993724055552?s=21 |
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 |
I strongly support this. |
@Oberon00 I can definitely wait until next week, that's why I asked here and not changed directly the sdk :) |
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! |
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. |
@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. |
@tedsuo I would like to point out that it seems Lightstep has never supported Java 7: lightstep/lightstep-tracer-java#213 |
@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: |
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. |
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. |
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. |
This sounds good to me (as an initial step). |
(To follow up on #744 (comment):) |
Can we get a show of thumbs on keeping java 7, but letting the android level requirement be dropped for now? |
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. |
@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? |
@jkwatson sure, no problem. |
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):
I would like every vendor to comment on this.
The text was updated successfully, but these errors were encountered: