Status Update
Comments
st...@staale.org <st...@staale.org> #3
For the relationship between the desugared library and the version of R8 there will be a dependency, so that for instance version 2.0.0
of com.android.tools:desugar_jdk_libs
could require at least R8 3.2.X. Now the com.android.tools:desugar_jdk_libs
dependency should carry enough information to fail if not supported by the current version of R8. Until now the only dependency is that R8 2.0.X is required. I am preparing a section on DAC with this matrix, which initially will be small. So for com.android.tools:desugar_jdk_libs
no explicit R8 version should be needed as well, except for better/earlier error reporting.
However, there might be other reasons for requiring a specific R8 version:
- the code in the
AAR
might use a method which is only backported from a specific R8 version (e.g.List.of
which was added recently). This is not something new, and could have happened before as well. We cannot easily check the code in theAAR
, as some code might (indirectly) be guarded by an API level check, so that the backporting in not necessarily needed. - the code in the
AAR
is compiled with a more recentjavac
(e.g. JDK 11 or JDK 17), and that could mandate a lower R8 bound. This is also not new, but here we could check the code when building theAAR
.
pe...@google.com <pe...@google.com> #4
Thanks
st...@staale.org <st...@staale.org> #5
If using a library with desugaring enabled, the build should fail (or at least give warning) when desugaring is not enabed in the library/application that depends on such library
pe...@google.com <pe...@google.com> #6
Could we get an update on prioritization? I'm updating Android API Guidelines right now, and it's unfortunate that library developers still can't use core library desugaring over a year later:
Libraries targeting SDK < 26 *must not* use `java.time.*` until the AAR format
supports advertising core library desugaring requirements (see
[b/203113147](https://issuetracker.google.com/203113147)).
Description