Status Update
Comments
am...@google.com <am...@google.com>
je...@google.com <je...@google.com>
ga...@google.com <ga...@google.com> #2
We need the following info:
- if Java library desugaring is enabled
- min version of
com.android.tools:desugar_jdk_libs
library - min r8 version - Søren is that really needed, or there is no dependency between
desugar_jdk_libs
and R8?
sg...@google.com <sg...@google.com> #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
.
ne...@tomtom.com <ne...@tomtom.com> #4
Thanks
[Deleted User] <[Deleted User]> #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
al...@google.com <al...@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)).
al...@google.com <al...@google.com> #7
Bumping this since it overlaps with class verification out-of-lining being built into R8 / D8. We can't stop manually out-of-lining new API references until we're able to specify minimum required R8 / D8 versions.
al...@google.com <al...@google.com> #8
Bumping this again since we're starting to see backports of platform APIs that take Duration
, and it would be nice to avoid adding a DurationCompat
.
Ivan, do you think there's any change this is going to be implemented in 2023? If not, I'll start recommending that library owners create Compat
versions of the Java 8 APIs.
ga...@google.com <ga...@google.com> #9
Considering there are already clear use-cases in AndroidX, I'll add this to AGP list of OKRs for Q2 2023.
lo...@gmail.com <lo...@gmail.com> #10
Also use cases in kotlinx! Thank you for making this a priority 🙏
sg...@google.com <sg...@google.com> #11
I think it is fine to extend the AAR format to say that library desugaring is required. However, if we start to use it for JetPack libraries developers have to accept the license referenced for the library (see
ga...@google.com <ga...@google.com>
re...@gmail.com <re...@gmail.com> #12
^ Is this the latest recommendation for the library authors? I couldn't find it in the api guidelines.
al...@google.com <al...@google.com> #13
Weird, I could have sworn I had a CL up when I wrote that comment. Docs changes pending.
Also, ping! It's been ~1.5 years and we still can't use Java 8 language APIs in most Jetpack libraries.
bi...@google.com <bi...@google.com> #14
To recap our discussion above:
Based on #2 and #3, library authors can specify javaLibraryDesugaring
to be true and a minDesugarJdkLibs
version to be used by consumer modules. No r8 version is needed at this moment.
Not sure about how we gonna do regarding the license from
Let me know if there is any misunderstanding, I am going to send out a CL soon. :)
al...@google.com <al...@google.com> #15
Thank you for picking this up!
Not sure about how we gonna do regarding the license from
, so it it out of the scope of the aar metadate work? comment #11
Yeah, that's a Jetpack policy decision. GPLv2+classpath is even more lenient than Apache 2.0 in this case, so I don't see any problems there.
bi...@google.com <bi...@google.com> #16
When users specify javaLibraryDesugaring
to be true via dsl but don't specify minDesugarJdkLibs
, do we want to have a "default" minDesugarJdkLibs
written into aar metadata? For example, we have a default minAgpVersion in aar metadata which is 1.0.0.
Soren, do you have some insights?
sg...@google.com <sg...@google.com> #17
I don't think we should have a default version, but require the dependency to be specified with version, com.android.tools:desugar_jdk_libs:2.0.0
. Right now we have versions 1.1.x, 1.2.x and 2.0.x, and the AGP (and then implicitly D8/R8 version) is specified in
From version 2.0.0 we have the additional complication that there are 3 different variants:
com.android.tools:desugar_jdk_libs_minimal:2.0.0
com.android.tools:desugar_jdk_libs:2.0.0
com.android.tools:desugar_jdk_libs_nio:2.0.0
I think we can ignore the minimal one. However, if the AAR specify the desugar_jdk_libs
variant and the app specified the desugar_jdk_libs_nio
variant, then the desugar_jdk_libs_nio
variant should be used, as that includes the desugar_jdk_libs
variant - and the other way around as well.
This is not nice to have such special handling, and we should find the right way to set this up. One thing I have sees is that 9999.0-empty-to-avoid-conflict-with-guava
desugar_jdk_libs_nio
have a dependency on desugar_jdk_libs
version 9999.0
which is an empty artifact.
bi...@google.com <bi...@google.com> #18
I don't think we should have a default version, but require the dependency to be specified with version
In that case, we could write desugarJdkLibs
into AAR metadata like com.android.tools:desugar_jdk_libs:2.0.0
If we find javaLibraryDesugaring
is true but no desugarJdkLibs
, we don't compare desugar jdk dependency version from aar and the version specified in app
However, if the AAR specify the desugar_jdk_libs variant and the app specified the desugar_jdk_libs_nio variant, then the desugar_jdk_libs_nio variant should be used
Do we want to throw errors(build fails) if AAR requires desugar_jdk_libs_nio
but app specifies desugar_jdk_libs
? Or we just want to "upgrade" the variant to desugar_jdk_libs_nio
?
If we want to do the "upgrade", that seems to be another scope of work where the desugarJdkLibs
variant affects the variant used in the app. It is good to bring it up so that we can add the variant info into AAR, but I think we could tackle the "variant conflicts resolving" part in a separate ticket. This one is more about checking if the consumer meets the requirement from the aar metadata. In terms of the validation part, we could compare the versions regardless of variants and throw errors if the app version is lower than the version from AAR. Sounds good?
If we want to fail the build, we can do that as part of the validation. In this case, we will compare both version and variant.
I think we can ignore the minimal one
Can you clarify on this point in the context of my previous question?
This is not nice to have such special handling
From AGP point of view, I don't think we would have too much special handling here.
Right now we have versions 1.1.x, 1.2.x and 2.0.x, and the AGP (and then implicitly D8/R8 version) is specified in this table.
I wonder how does the compatibility requirement between AGP and desugar lib version come into play here. Can you share a case where we need throw error messages based on AGP version?
bi...@google.com <bi...@google.com> #19
sgjesse@, can you share your thoughts regarding #18?
sg...@google.com <sg...@google.com> #20
First of all I agree that when building the AAR we should just write the desugarJdkLibs
artifact name used by the module into the AAR, i.e. whatever value is set for the dependency coreLibraryDesugaring
in the module. That should be the only information needed in the AAR.
It would be great if picking the right desugar_jdk_libs
when using desugared library in the app and through several AARs with different flavors and versions could use the normal Maven version resolution, so that the AAR could just add a coreLibraryDesugaring
dependency to the apps dependencies
:
dependencies {
coreLibraryDesugaring(com.android.tools:desugar_jdk_libs:2.0.0) // explicitly added by the developer
coreLibraryDesugaring(com.android.tools:desugar_jdk_libs_nio:2.0.3) // implicitly added from one AAR
coreLibraryDesugaring(com.android.tools:desugar_jdk_libs:1.1.8) // implicitly added from another AAR
}
This should result in only adding com.android.tools:desugar_jdk_libs_nio:2.0.3
as a coreLibraryDesugaring
dependency. Likewise
dependencies {
coreLibraryDesugaring(com.android.tools:desugar_jdk_libs_nio:2.0.0) // explicitly added by the developer
coreLibraryDesugaring(com.android.tools:desugar_jdk_libs:2.0.3) // implicitly added from one AAR
coreLibraryDesugaring(com.android.tools:desugar_jdk_libs:1.1.8) // implicitly added from another AAR
}
Should also result in only adding com.android.tools:desugar_jdk_libs_nio:2.0.3
as a coreLibraryDesugaring
dependency.
So
dependencies {
coreLibraryDesugaring(com.android.tools:X:A) // explicitly added by the developer
coreLibraryDesugaring(com.android.tools:Y:B) // implicitly added from one AAR
coreLibraryDesugaring(com.android.tools:Z:C) // implicitly added from another AAR
}
Should result in coreLibraryDesugaring(com.android.tools:max(X,Y,Z):max(A,B,C)), where the name is sorted desugar_jdk_libs_nio
> desugar_jdk_libs
> desugar_jdk_libs_minimal
. And version is sorting by semantic version.
I am not sure if there is any way we can handle this with just Maven logic. Using the Guava "hack" with com.android.tools:desugar_jdk_libs_nio:X.Y.Z
depending on com.android.tools:desugar_jdk_libs:9999.0-empty-to-avoid-non-nio
would not work for the second case, as that would result in com.android.tools:desugar_jdk_libs_nio:2.0.0
and not com.android.tools:desugar_jdk_libs_nio:2.0.3
.
Also looking at
bi...@google.com <bi...@google.com> #21
Should result in coreLibraryDesugaring(com.android.tools:max(X,Y,Z):max(A,B,C)), where the name is sorted desugar_jdk_libs_nio > desugar_jdk_libs > desugar_jdk_libs_minimal. And version is sorting by semantic version
That sounds good to me. I think we have to handle it in AGP by checking the aar metadata when determining the core library dependency version. Not so sure about maven magic.
Given that, IIUC, we should only fail the build if coreLibraryDesugaring
is not enabled in consumer(e.g. app, library) when the meta data of its aar dependency requires coreLibraryDesugaring
to be enabled. We don't fail the build because of version or desugar lib variant.
building the AAR we should just write the desugarJdkLibs artifact name used by the module into the AAR,
We can write something like the following into the aar.
javaLibraryDesugaring=true
desugarJdkLibs=com.android.tools:desugar_jdk_libs_nio:2.0.3
i.e. whatever value is set for the dependency coreLibraryDesugaring in the module.
Normally we ask users to specify what goes into aar metadata via dsl, it seems we are writing things into aar metadata without users input. Should we provide the option for users for specifying javaLibraryDesugaring
and desugarJdkLibs
? If so, the value specified by the user override the value obtained from the actual set up(whether coreLibraryDesugaring is enabled and what desugar lib is being used)?
how does AARs specify dependencies today?
I think it is via gradle metadata(or pom if gradle metadata not exist) which is not packaged inside the aar.
cl...@google.com <cl...@google.com> #22
I think that is correct:
com.android.tools:max(X,Y,Z):max(A,B,C))
where the name is sorted desugar_jdk_libs_nio
> desugar_jdk_libs
> desugar_jdk_libs_minimal
. And version is sorting by semantic version.
bi...@google.com <bi...@google.com> #23
Should we provide the option for users for specifying javaLibraryDesugaring and desugarJdkLibs
Let's extract those info from android.compileOptions.coreLibraryDesugaringEnabled
and the dependency resolved for coreLibraryDesugaring
, instead of asking users to specify from android.defaultConfig(buildType/flavor).aarMetadata
because:
aarMetadata
is variant specific but library desugaring is global.- we have enough info from existing dsl to write out metadata
- if we see a need of allowing users to "override", we can support that later.
bi...@google.com <bi...@google.com> #24
The work for adding core library desugaring related info to AAR metadata(mvp version) is done with I9203bd7919b7b55cd3b46ea5465ecc93f55771e3 which will be available from AGP 8.2.
This means the consumer(e.g. app) will be asked to enable library desugaring if there is a requirement from its dependencies. For androidx folks, the library desugaring info is written out to aar metadata automatically if you publish your library with 8.2+
Next step would be "integrate" desugar-jdk-lib variant & version from the dependency with the ones declared on the consumer side
bi...@google.com <bi...@google.com>
g....@xe.gr <g....@xe.gr> #25
We have a base (library) module in our app that defines coreLibraryDesugaring
and is used by various other (library) modules of the same app. The "app" (application) module of the app is also defining coreLibraryDesugaring
, so until AGP 8.1.x everything was working OK.
However, when updating to AGP 8.2.x it forces us to define coreLibaryDesugaring
in all the intermediate (library) modules too.
Surely, this enforcement should apply only for application-type modules, not library-type ones too, right?
g....@xe.gr <g....@xe.gr> #26
Any comment on my comment above? Should I open a new issue?
al...@google.com <al...@google.com> #27
File a new issue, please.
bi...@google.com <bi...@google.com> #28
Can you also link the new issue here? Thanks
g....@xe.gr <g....@xe.gr> #29
I opened issue
Description
Follow-up to b/202868795#comment4 and b/150132272#comment10 .
Currently it is possible for a library to use new Java APIs via
coreLibraryDesugaring
, but the UX for clients of libraries is not great. We should embed the requirements (R8/D8 version? more?) in AAR metadata and provide appropriate error messages to library clients.