Special-case desugaring for a handful of java 8 methods [114711928]

Fixed

Feature Request

Status Update

No update yet.

Description

vn...@google.com

created issue #1

Sep 10, 2018 03:20PM

Consider adding special desugaring of few methods introduced to well-known classes in Java 8+.

For particular example see

https://youtrack.jetbrains.com/issue/KT-26432. The problem is that method java.lang.Integer.hashCode(int) was only added in v24, and it needs to be desugared to run on earlier versions.

What makes it different is that
(a) calls to such methods may be seen in java 8 libraries
(b) we cannot expect all such calls to be guarded by 'if (Build.VERSION.SDK_INT >= ...) {' checks
(c) semantics of such methods is well defined in a sense it depends on other methods (in this case the result must be same as that returned by Integer.hashCode()).

There are few other candidates to consider in Integer class (like Integer.compareUnsigned(int, int)) and other classes. Full list of methods TBD.

Comments

js...@google.com <js...@google.com> Oct 9, 2018 04:49PM

Reassigned to ag...@google.com.

ol...@gmail.com <ol...@gmail.com> #2Oct 25, 2018 10:35AM

Microsoft doc:

https://support.microsoft.com/en-ca/help/2999226/update-for-universal-c-runtime-in-windows
Platform 28.0.2 readme:

https://developer.android.com/studio/releases/platform-tools
"
Updated Windows requirements
The platform tools now depend on the Windows Universal C Runtime, which is usually installed by default via Windows Update. If you see errors mentioning missing DLLs, you may need to manually fetch and install the runtime package.
"

jv...@google.com <jv...@google.com> #3Nov 13, 2018 04:17PM

Note: see also

b/129008605

ri...@google.com <ri...@google.com> Nov 20, 2018 10:03AM

Reassigned to ri...@google.com.

ap...@google.com <ap...@google.com> #4Dec 21, 2018 05:01AM

Bug cleaning...what is the status on this? Looks like the depending bug is fixed.

ap...@google.com <ap...@google.com> #5Dec 21, 2018 09:07AM

I noticed that the WINDOWS_UCRT_CHECK_ENABLED Studio flag defaults to false. Should this be set to true eventually, or can this code be deleted?

ri...@google.com <ri...@google.com> #6Jan 3, 2019 01:21PM

Hannah, I am pretty sure we did enable this. Do you know why/when it was disabled?

ri...@google.com <ri...@google.com> #7Jan 3, 2019 01:30PM

Ummm... it doesn't look like it was ever enabled, and the flag hasn't been touched since the initial CL in 2019. I don't know why it was never enabled. Better 4 years late than never?

ri...@google.com <ri...@google.com> #8Jan 3, 2019 01:50PM

Marked as fixed.

Discussed this locally. The current implementation should support what is needed for kotlin code, there is currently no plan for supporting full desugaring of all Java8 code, so closing this as fixed for now, please reopen if we need additional functionality.

ap...@google.com <ap...@google.com> #9Jan 3, 2019 06:24PM

Project: r8
Branch: master

commit 516a6684f134d06eff08080e7ef7129517071817
Author: Rico Wind <ricow@google.com>
Date: Thu Jan 03 13:46:48 2019

Desugar static hashcode on Byte and Short

Bug: 114711928
Change-Id: I67ebad45c80662841496af910e38696732faf186

M src/main/java/com/android/tools/r8/ir/desugar/Java8MethodRewriter.java
M src/test/java/com/android/tools/r8/desugar/Java8MethodsTest.java

https://r8-review.googlesource.com/32568

ap...@google.com <ap...@google.com> #10Jan 3, 2019 06:29PM

https://r8-review.googlesource.com/32568

ap...@google.com <ap...@google.com> #11Jan 3, 2019 06:39PM

Project: r8
Branch: master

commit 59a02cea4cfbb2a4131a047194f6a9726d5babd7
Author: Rico Wind <ricow@google.com>
Date: Thu Jan 03 10:54:13 2019

Add more boxed primitive desugaring

This adds desugaring of:

int Integer.min(int a, int b)
int Integer.sum(int a, int b)

double Double.min(double a, double b)
double Double.sum(double a, double b)
boolean Double.isFinite(double a)

int Float.hashCode(float d)
float Float.max(float a, float b)
float Float.min(float a, float b)
float Float.sum(float a, float b)
boolean Float.isFinite(float a)

int Boolean.hashCode(boolean b)
boolean Boolean.logicalXor(boolean a, boolean b)
boolean Boolean.logicalOr(boolean a, boolean b)
boolean Boolean.logicalAnd(boolean a, boolean b)

Bug: 114711928

Change-Id: Idb5aea382273e6b212902cd34c5fd99ec1b5e21c

M src/main/java/com/android/tools/r8/ir/desugar/Java8MethodRewriter.java
M src/test/java/com/android/tools/r8/desugar/Java8MethodsTest.java

https://r8-review.googlesource.com/32460

ap...@google.com <ap...@google.com> #12Jan 3, 2019 06:39PM

Project: r8
Branch: master

commit 3dd1e52ce68bd835038ff90de5f31e9d1c7371e0
Author: Rico Wind <ricow@google.com>
Date: Fri Dec 21 13:41:14 2018

Reland "Add initial structure for desugaring static java 8 methods""

This reverts commit 6f9e11b9b409480466ddd10ad5b4ebb21f4977a8.

Only change is the way we compute the referencing classes.
We need to handle the cases where the holder is a synthesized class.
Instead of collecting the program classes we collect the holders, and use the builder
to lookup these when generating.

Bug: 114711928

Change-Id: Ic1622b1c83e48e07d8f74bb30664cf6f75381ac7

M src/main/java/com/android/tools/r8/ir/conversion/IRConverter.java
A src/main/java/com/android/tools/r8/ir/desugar/Java8MethodRewriter.java
A src/test/java/com/android/tools/r8/desugar/Java8MethodsTest.java

https://r8-review.googlesource.com/32473

ja...@gmail.com <ja...@gmail.com> #13Jan 4, 2019 03:40PM

> We should fix this for 3.4 as it impacts Kotlin libraries targeting java 8 that want to be reused on Android

This has impacted Java libraries targeting Java 8 that want to be reused on Android for *years* now. In the example of the YouTrack issue who's to say the Java library defining the static interface method isn't also using a functional interface, a stream, an optional, new math methods, java.time, or any of the other appealing APIs added in Java 8 in addition to the language features?

Desugaring only the Java 8 APIs that are used when the Kotlin consumer is updated to target Java 8 but not enabling the Java author to actually use more of those APIs feels very weird.

ri...@google.com <ri...@google.com> #14Jan 7, 2019 07:04AM

#13 That is a valid (and good) point!
The specific issue here was the code generated by the kotlin compiler for data classes - which is what, afaik, what we said would be fixed for 3.4.
I agree that in an ideal world, all developers could use all Java 8 features freely(in their own or library code), and have that desugared to run on older versions of android, but there is also a prioritization here.
I have opened:

https://issuetracker.google.com/122421055
for input and discussion on that.