69 lines
3.5 KiB
Markdown
69 lines
3.5 KiB
Markdown
# Rationale for not supporting Java 7
|
|
|
|
## Android support is no longer tied to Java 7
|
|
|
|
Even for supporting old Android API levels:
|
|
|
|
> If you're building your app using Android Gradle plugin 4.0.0 or higher, the plugin extends
|
|
> support for using a number of Java 8 language APIs <b>without requiring a minimum API level for
|
|
> your app</b>.
|
|
|
|
(<https://developer.android.com/studio/write/java8-support#library-desugaring>)
|
|
|
|
There are some Java 8 APIs that Android does not desugar, but we can use
|
|
[animal sniffer plugin](https://github.com/xvik/gradle-animalsniffer-plugin) to ensure we don't use
|
|
those particular Java 8 APIs that are not available in the base Android level we decide to support,
|
|
e.g. OkHttp takes this approach to
|
|
[ensure compliance with Android API level 21](https://github.com/square/okhttp/blob/96a2118dd447ebc28a64d9b11a431ca642edc441/build.gradle#L144-L153)
|
|
|
|
We will use this approach for the `instrumentation-api` module and for any library (manual)
|
|
instrumentation that would be useful to Android developers
|
|
(e.g. library instrumentation for OkHttp).
|
|
|
|
## Modern test tooling requires Java 8+
|
|
|
|
Both JUnit 5 and Testcontainers require Java 8+.
|
|
|
|
## Auto-instrumentation (Javaagent)
|
|
|
|
We could run tests against Java 8+ and ensure Java 7 compliance by using similar animal sniffer
|
|
technique as above.
|
|
|
|
But bytecode instrumentation tends to be much more sensitive to Java versions than normal code, and
|
|
we would lose a lot of confidence in the quality of our Java 7 support without being able to run our
|
|
standard tests against it.
|
|
|
|
Another option would be to run the "code under test" in a separate JVM from our test harness, which
|
|
would allow us to use Java 8 for our test harness (e.g. use JUnit 5 and Testcontainers), while
|
|
running our "code under test" inside of Java 7. This is an attractive approach (and e.g. Glowroot
|
|
does this, though not to run on older JVMs, but to run with the `-javaagent` flag because I didn't
|
|
think about hacking the `-javaagent` flag directly into the test JVM). But this approach does come
|
|
with a more complex testing and debugging story due to propagating tests and parameters, and
|
|
debugging across two separate JVMs. And new contributor experience has a very high priority for this
|
|
project (compared to say commercial tools who can invest more in onboarding their employees onto a
|
|
more complex codebase).
|
|
|
|
## Library (manual) instrumentation
|
|
|
|
We believe that Java 7 users are primarily in maintenance mode and not interested in cracking open
|
|
their code anymore and adding library (manual) instrumentation, so we don't believe there is much
|
|
interest in library instrumentation targeting Java 7.
|
|
|
|
## Java 7 usage
|
|
|
|
Certainly one factor to consider is what percentage of production applications are running Java 7.
|
|
|
|
Luckily, New Relic
|
|
[published their numbers recently](https://blog.newrelic.com/technology/state-of-java),
|
|
so we know that ~2.5% of production applications are still running Java 7 as of March 2020.
|
|
|
|
## Alternatives for Java 7 users
|
|
|
|
We understand the situations that lead applications to get stuck on Java 7 (we've been there
|
|
ourselves), and we agree that those applications need monitoring too.
|
|
|
|
Our decision may have been different if those Java 7 users did not have any other alternative
|
|
for codeless monitoring, but there are many existing codeless monitoring solutions that still
|
|
support Java 7 (both open source and commercial), and probably many of those applications, having
|
|
been in production for a long time already, are already using one of those solutions.
|