Truly decide on, and document with rationale, support for Java 7

[anuraaga]

The topic of Java 7 support came up again

open-telemetry/opentelemetry-java-instrumentation#714

It continues to come up. I thought we had some consensus that supporting Java 7, mostly to support Android apps that target a large range of OS, is ok. But admittedly we've only had conversations on several issues, maybe some sigs, who knows, but nothing permanent. I think we need to decide and document this decision instead of leaving it as an elephant in the room. A concrete example of what doesn't work well without a decision is #575. There's no point in the investigation if the end result is "seems good, but requires Java 8, did we actually make a decision on this?".

[Oberon00]

This was truly and formally decided in #744 IMHO, see e.g. #744 (comment)

[anuraaga]

If it truly is, then we should probably add it to a markdown file somewhere in the repo with some rationale, referring people to docs is easier than issues. I'm happy to write a doc but need to reconfirm the decision since I suspect the buyin is not complete.

[Oberon00]

referring people to docs is easier than issues

I would usually search in issues not in code for such a decision. However, a summarizing comment edited into the issue description, or as final comment that can be linked to would be helpful. I'm not against a markdown doc either though, it would just not be my first choice.

[Oberon00]

I suspect the buyin is not complete.

All I can say is that at least for Dynatrace, nothing has changed (and most likely won't change in the next few years) in that regard: we still need a functional SDK + dependencies that support Java 7. We don't have a strong opinion on auto instrumentation.

[jkwatson]

I suspect the buyin is not complete.

All I can say is that at least for Dynatrace, nothing has changed (and most likely won't change in the next few years) in that regard: we still need a functional SDK + dependencies that support Java 7. We don't have a strong opinion on auto instrumentation.

@Oberon00 Can you write up a summary as to why you need java 7 support? It's definitely a large drag on productivity to support it, and if Dynatrace is the only vendor that needs it, can Dynatrace maintain its own fork with java 7 support?

[Oberon00]

@jkwatson

Can you write up a summary as to why you need java 7 support?

We will be using an OpenTelemetry-based solution for our own auto-instrumentation and we already know that some customers that want to use it are stuck on Java 7 there for quite some time. It's as simple as that, unfortunately.

if Dynatrace is the only vendor that needs it,

I don't think that is the case.

On #744 (comment) it looked like Lightstep was glad to have Java 7 support too. CC @carlosalberto

And on open-telemetry/opentelemetry-java-instrumentation#714 linked in the initial description, there seems to be the assumption that basic Java 7 support is useful for Android app developers.

EDIT: In #744 (comment), @lmineiro from Zalando spoke up to say that they are also still using Java 7 JVMs for some services.

This matches experience at Dynatrace: Unfortunately, Java 7 (and other old technologies) are not as uncommon in enterprise code as one would hope.

It's definitely a large drag on productivity to support it

Really? Of course one always feels bad when having to write/let the IDE generate the boilerplate for an anonymous inner class instead of simply writing a lambda, but I don't think it's that big. Except probably for default interface implementations which would really be useful for library evolution (but see next points).

I think the core SDK is (or should be) a relatively simple piece of code. Having exporters or special propagators, or resource detection plugins or auto instrumentation use Java 8 (or 11) is fine with us.

can Dynatrace maintain its own fork with java 7 support?

I think it's clear that OpenTelemetry won't be supporting Java 7 (or even 8) forever (and probably also not as long as Dynatrace wants to support Java 7). So at some point, it will probably come to that. But I think having at least the GA version support Java 7, until the next major release (dropping Java 7 already warrants one) would be a good.

[carlosalberto]

Observe that this is also needed by Google, IIRC (cc @bogdandrutu )

[jkwatson]

The last we heard from Ted, Lightstep no longer needed java 7 support. I'm ok with re-opening this issue post GA.

And, yes, default methods on interfaces, and static members on interfaces is a big win for API design that we can't take advantage of with java 7.

[carlosalberto]

Oh yes, I forgot to mention this - from the LS side, we don't need Java 7 support.

[kittylyst]

I've seen this debate play out in other projects and venues, so I thought I’d add my 2c.

In general, I think it’s helpful to separate out the two issues: Android support vs supporting very old legacy Java apps.

Android is a separate runtime that actually has very little to do with the JVM these days apart from having some language level compatibility. I feel like it’s reasonable to ask to what extent a mainline project should be constrained in order to accommodate a fork (and one that is not converging, but very definitely charting its own destiny).

To the other point, Java 7 was EOL’d over 5 years ago, and its market share of Java apps in 2020 is a couple of percent (and that represents all Java 7 apps, not the ones that would be interested in OTel) - so if that is not compelling enough to remove Java 7 support, then I think it’s reasonable to ask what people think the gating criteria for removal should be.

If 5.5 years since EOL and 2.5% usage isn’t long enough and small enough to warrant dropping support then what is?

[Oberon00]

I only have anecdotal evidence for this, but among the reasons that systems are still stuck at Java 7 is often also a combination of the following: (1) the system is large and complex or otherwise difficult difficult to port, (2) the system is mission-critical and runs well enough ("never touch a running system"). Both of these will also make you want to monitor the system. So while the market share of Java 7 may be very small, I think the relative share of apps in need of monitoring among them is higher than for newer Java versions.

[iNikem]

You cannot add monitoring without "touching" the system. Both manual and auto instrumentations are quite invasive. I don't understand how "it is too risky to migrate to java8" and "let's add manual monitoring throughout the whole application" can both be true

[Oberon00]

Auto instrumentation does not have to involve much manual work. Of course already adding a -javaagent command line to all JVMs can be a lot of work, but the risk of adding auto instrumentation is (at least often perceived as) lower than switching to a newer JVM.

[iNikem]

Yeah, one more mystery: people are afraid of newer JVM but totally ok with allowing some library to modify all their classes in obscure way 🤷