Rationale for not supporting Java 7

[trask]

Summarizing decision and rationale from yesterday's meeting on this topic. Please review and provide feedback.

[codefromthecrypt]

rationale looks to cover the reasons why. if you want to trump our RATIONALEs, add what you are willing to not do.

ex. "modern" is fair enough, but this concedes implicitly that open-telemetry cannot be used for things not modern, so something else will.

Maybe @CodingFabian or others know the fuller impact of how many sites from an existing vendor require Java 1.7 instrumentation.

[CodingFabian]

Only commenting since @adriancole pinged me.
From a vendor perspective this makes me happy. We have 1.6 / 1.7 customers and we happily support them with our auto instrumentation.
From a technologist perspective, I would say that not being able to test against 1.7 is just an excuse. It is possible (as a vendor I do that!). One might argue that this is too much effort, and this could be true depending on many factors. I can not, and do not want to judge this.
The true question is what Java 8 library provided class is worth dropping the support. I doubt that any bytecode level or runtime behaviour differences would justify the decision. But I assume this has been clarified in the meeting.

Is that the input you were looking for, Adrian?

[codefromthecrypt]

Is that the input you were looking for, Adrian?

it seems github doesn't have a 🍿 reaction, so I need to make a comment instead

[trask]

@adriancole @CodingFabian appreciate the feedback!

how many sites from an existing vendor require Java 1.7 instrumentation.

Oh yes, I will add this to the doc. We know from New Relic's (very large) user base that 2.5% of apps are still on Java 7:

https://blog.newrelic.com/technology/state-of-java/

From a vendor perspective this makes me happy. We have 1.6 / 1.7 customers and we happily support them with our auto instrumentation.

Yup, we actually discussed this, and it makes us feel less bad about not supporting Java 7 users, knowing that those users have other options for codeless monitoring. I will add this to the doc also.

I would say that not being able to test against 1.7 is just an excuse

I'm not following this, are you saying it's ok to --release 7 and only test against Java 8? Or are you saying we should stick to JUnit 4 and not use Testcontainers? EDIT: or probably you mean something else like running our test code inside a separate JVM from where we run our test harness / verification?

[CodingFabian]

I am not proposing anything for OT. I just want to say that Instana runs Java 1.6 tests, and they do include testcontainers based tests. So I guess it really just depends on the effort you want to invest.

Are you saying NewRelic will recommend Instana? quite an honor.

[trask]

Are you saying NewRelic will recommend Instana? quite an honor.

You would have to ask them, but I doubt it 😁

[jkwatson]

New Relic's own non-OpenTelemetry agent support java 7, so no. :)

[trask]

Instana runs Java 1.6 tests, and they do include testcontainers based tests. So I guess it really just depends on the effort you want to invest.

Yes, good point, I will add this option to the doc.

[codefromthecrypt]

ps while I think this is fun banter, it is more important that people know that in open source this limits the options. It was fairly routine for folks to drive by recommend yanking out brave etc because opentracing was "standard" I expect similar once otel goes into that mode (hopefully it stays more in the here is an option we think is good mode). anyway when people aspire to push low level deps it reduces the instrumentation available in OSS when they do swap out something more portable. Similar to instana, Brave has been supporting JRE 1.6 for ages and we currently compile with JDK 14 and have lambda tests in the test tree also have JFR etc in certain modules with higher level requirements. what maybe Fabian is saying is that it is not required to prevent Java 1.6 or 1.7 in order to use later in tests.. it is just simpler to do it like that.

…

On Thu, Aug 20, 2020, 11:28 PM Trask Stalnaker ***@***.***> wrote: @adriancole <https://github.com/adriancole> @CodingFabian <https://github.com/CodingFabian> appreciate the feedback! how many sites from an existing vendor require Java 1.7 instrumentation. Oh yes, I will add this to the doc. We know from New Relic's (very large) user base that 2.5% of apps are still on Java 7: https://blog.newrelic.com/technology/state-of-java/ From a vendor perspective this makes me happy. We have 1.6 / 1.7 customers and we happily support them with our auto instrumentation. Yup, we actually discussed this, and it makes us feel less bad about not supporting Java 7 users, knowing that those users have other options for codeless monitoring. I will add this to the doc also. I would say that not being able to test against 1.7 is just an excuse I'm not following this, are you saying it's ok to --release 7 and only test against Java 8? Or are you saying we should stick to JUnit 4 and not use Testcontainers? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1068 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPVV6TSWXREB5FKOKBS5LSBU6JHANCNFSM4QFQC7EA> .

[trask]

updated the rationale doc based on feedback

[anuraaga]

Thanks @trask! And thanks everyone for the feedback! I don't think there's any perfect answer here and we'll continue to digest this, we still have until GA to commit to a decision either way. Hoping it makes people happy :)