Recently, the news came that Android Studio 4 will support a so-called "desugaring" of Java 8 APIs (i.e., some kind of auto-backport for target devices not supporting newer API levels as I understand). This would allow RxJava 3 to increase the baseline support to Java 8 on its surface API:

• Stream support
• Stream Collectors support
• Optional support
• CompletableFuture support
• Use site non-null annotations

Some features won't be supported:

• java.time.Duration: allocates, we'll stick to time+unit
• java.util.function: these can't throw Throwables, overloads would create bloat and/or ambiguity

The main issue with Android's Java 8 support is timing related to the pledged release schedule of RxJava 3.x, end of December 2019. AGP 4 may not release for months, inclining us to:

• Wait for AGP's release, effectively parking RxJava 3 for months as release candidate. Drawback: AGP may slip a lot.
• Release on schedule with Java 6 baseline. Drawback: AGP may release shortly after and thus
  • we'd be stuck on 3.x for years;
  • we'd have to start working on 4.x undermining 3.x in a sense, also adding more maintenance burden;
  • we release 3.1 with baseline 8, abandoning 3.0 and possibly violating some pledge;
• Release on schedule with Java 8 baseline. Drawback: 3.x improvements won't be available to many at release.
• Release on schedule with Java 8 bytecode output but no 8 API use, add those in 3.1. Drawback: despite best efforts, this could cause problems with existing desugaring/tooling.

The same issue is likely to arise with the next step, Java 9 support on Android. From our perspective, support for the Flow.* interfaces would be just enough as none of the other 9 features would work (VarHandles - field reflection anomalies?, Cleaner - portable?, Modules?). Beyond 9, the next major change to RxJava would have to come due to value types (no version ETA yet). Loom/Fibers is likely simply an API expansion, not a fundamental change.

Suggestions, ideas welcome.