Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.98%. Comparing base (688e103) to head (08a931b).
Report is 2 commits behind head on main.

@@             Coverage Diff              @@
##               main    #7221      +/-   ##
============================================
+ Coverage     89.96%   89.98%   +0.01%     
+ Complexity     6688     6686       -2     
============================================
  Files           751      749       -2     
  Lines         20200    20191       -9     
  Branches       1978     1977       -1     
============================================
- Hits          18173    18168       -5     
+ Misses         1434     1432       -2     
+ Partials        593      591       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I noticed that we have a java9 specific clock implementation. The goal appears to be: leverage APIs introduced in java 9 to get microsecond level precision when available.

I happened to be looking at this code and didn't actually see any indication that these APIs were introduced in java9, so I deleted the java9 specific implementation and brought the supposed java9-specific implementation to the base, i.e. java 8+.

The test fails in java8, but its just because the test uses a heuristic to estimate that the clock is indeed precise to the microsecond. It appears that the APIs required for the microsecond level precision implementation are available in java 8+, but their implementation doesn't actually achieve microsecond level precision until java 9+. So what is the point of the different implementations?

The microsecond precision version looks like:

    Instant now = Clock.systemUTC().instant();
    return TimeUnit.SECONDS.toNanos(now.getEpochSecond()) + now.getNano();

While the millisecond precision version looks like:

    return TimeUnit.MILLISECONDS.toNanos(System.currentTimeMillis());

The only benefit I can think of for splitting the implementations is to avoid allocating an Instant object instance in java8 when it won't offer any additional precision. If this is indeed the only benefit, then I would argue we shouldn't keep perf optimizations around specifically for old java versions.

One other thing I can't make sense of is that that microsecond level precision implementation calls Instant#toNano, which isn't available in android until API level 26. We're at android API level 23, but animal sniiffer doesn't seem to care. 🤔

@jack-berg Randomly noticed this and indeed the only reason is the small perf improvement. I suppose by now Java 8 usage should have gone down enough to remove it.

Randomly noticed this and indeed the only reason is the small perf improvement. I suppose by now Java 8 usage should have gone down enough to remove it.

Thanks for the context!

We discussed at the 4/3/25 java SIG and decided that we should remove it, pending confirmation from @open-telemetry/android-maintainers that calling Instant.getNano() isn't an issue.

This is essentially a performance optimization which provides a (small) incentive to stay on java 8. If we're going to have java version based performance optimizations, they should encourage upgrading!

pending confirmation from @open-telemetry/android-maintainers that calling Instant.getNano() isn't an issue

It's not an issue, as it's available via the core lib. The core lib allows us to use some of the types/methods available after API level 23, such as Base64 for example, which we already use.

It's not an issue, as it's available via the core lib. The core lib allows us to use some of the types/methods available after API level 23, such as Base64 for example, which we already use.

Thanks!

For when the question of "which APIs are supported when desugaring is considered" comes up in the future, here's the reference: https://developer.android.com/studio/write/java8-support-table