Why does R8 doesn't backport default interface methods but D8 does? [228791247]

Verified

Bug

Status Update

No update yet.

Description

pr...@gmail.com

created issue #1

Apr 11, 2022 01:00PM

Description has been deleted.

Comments

ag...@google.com <ag...@google.com> #2Apr 12, 2022 07:25AM

Fixed in r1313.

pr...@gmail.com <pr...@gmail.com> #3Apr 12, 2022 03:16PM

[Empty comment from Monorail migration]

Message last modified on Apr 12, 2022 04:21PM

bug_report.zip

76 MB

Download

ag...@google.com <ag...@google.com> #4Apr 13, 2022 09:14AM

Reassigned to sg...@google.com.

[Empty comment from Monorail migration]

Message last modified on Apr 13, 2022 09:15AM

pr...@gmail.com <pr...@gmail.com> #5Apr 13, 2022 10:43AM

This issue was migrated from

crbug.com/nativeclient/245?no_tracker_redirect=1

[Monorail components: TrustedRT]

Message last modified on Apr 13, 2022 11:10AM

mk...@google.com <mk...@google.com> #6Apr 13, 2022 02:32PM

D8 is compiling java to be desugared such that it can run on ART. Desugared output from D8 is never ment to be consumed by a java compiler and dependending on the min-api level (which is an android level api level) it may or may not desugar default methods.

When compiling R8 with a class file output the output is ment to be consumed by a java compiler and R8, I believe, will not consider a min-api. It will assume that the version used for javac compilation is the same for running/addition compilation and will therefore not desugar default methods.

There is no correspondance between min-api and class file versions. If you really want to persue this direction I would recommend using D8 to produce output for an api-level you consider being sufficient for java 7 and then use R8 on it. I believe that should work.

pr...@gmail.com <pr...@gmail.com> #7Apr 13, 2022 07:00PM

I'm sorry, but I don't quite understand it!
I use R8/D8 to produce dex files as output and the dex files will be than compiled with a dex2oat compiler (to use it later on iOS). I use 21 as min api level which should desugar the default methods. This is working when using D8 for producing dex files (see my reproducer). When I now just switch the d8 execution with the r8 execution (+proguard config), the desugaring fails for default methods(see reproducer). Everything else (lambdas, Buffer 9+ Api etc.) will be correctly backported/desugared, the same way just d8 does. Both dex outputs, from d8 and r8 (when no default interface needs to be desugared) leads to a sucessful launch of the app, therefor the general approach is working!
As also the other person analysed, the exception has nothing to do with the java/android classes used in the jar, since the same behavior occures without them. It is only that I can't run r8 on the jar in the reproducer. I would consider this a bug in R8, or am I wrong?

Message last modified on Apr 13, 2022 07:04PM

ze...@google.com <ze...@google.com> Apr 19, 2022 07:57AM

Reassigned to ze...@google.com.

ze...@google.com <ze...@google.com> #8Apr 19, 2022 12:11PM

Thank you for the report and for including a reproduction! This is an R8 bug which is subtly caused by having two (or more) keep rules that target an interface method that is defined as a default method on a super-interface. R8 then incorrectly generates multiple bridges. We should have a fix up shortly and I'll post back.

Regarding compiling with java.lang.Object, while R8 does not explicitly support that, there is no reason we should fail on it. I'll update the places that fail based on the reproduction project too.

ap...@google.com <ap...@google.com> #9Apr 19, 2022 01:12PM

Project: r8
Branch: main

commit b14927241155613d1aa8de398494d84fdec68f55
Author: Ian Zerny <zerny@google.com>
Date: Tue Apr 19 14:38:06 2022

Regression test for insertion of multiple interface bridges.

Bug:

Issue 228791247

Description

Issue summary

Comments

ag...@google.com <ag...@google.com> #2Apr 12, 2022 07:25AM

pr...@gmail.com <pr...@gmail.com> #3Apr 12, 2022 03:16PM

ag...@google.com <ag...@google.com> #4Apr 13, 2022 09:14AM

pr...@gmail.com <pr...@gmail.com> #5Apr 13, 2022 10:43AM

mk...@google.com <mk...@google.com> #6Apr 13, 2022 02:32PM

pr...@gmail.com <pr...@gmail.com> #7Apr 13, 2022 07:00PM

ze...@google.com <ze...@google.com> Apr 19, 2022 07:57AM

ze...@google.com <ze...@google.com> #8Apr 19, 2022 12:11PM

ap...@google.com <ap...@google.com> #9Apr 19, 2022 01:12PM

ap...@google.com <ap...@google.com> #10Apr 20, 2022 07:30AM

ze...@google.com <ze...@google.com> #11Apr 20, 2022 07:57AM

ap...@google.com <ap...@google.com> #12Apr 22, 2022 07:12AM

ap...@google.com <ap...@google.com> #13Apr 22, 2022 07:12AM

ap...@google.com <ap...@google.com> #14Apr 22, 2022 07:12AM

ap...@google.com <ap...@google.com> #15Apr 22, 2022 07:12AM

ap...@google.com <ap...@google.com> #16Apr 22, 2022 07:12AM

ap...@google.com <ap...@google.com> #17Apr 22, 2022 07:12AM

ap...@google.com <ap...@google.com> #18Apr 22, 2022 07:13AM

ap...@google.com <ap...@google.com> #19Apr 22, 2022 07:13AM

ap...@google.com <ap...@google.com> #20Apr 22, 2022 07:13AM

ap...@google.com <ap...@google.com> #21Apr 22, 2022 07:13AM

ap...@google.com <ap...@google.com> #22Apr 22, 2022 07:13AM

ap...@google.com <ap...@google.com> #23Apr 22, 2022 07:14AM

ap...@google.com <ap...@google.com> #24Apr 22, 2022 07:14AM

pr...@gmail.com <pr...@gmail.com> #25Apr 22, 2022 08:45AM

ze...@google.com <ze...@google.com> #26Apr 22, 2022 10:43AM

Add comment

Issue metadata