D8: Method name '$.$b__2' in class cannot be represented in dex format


(Jon Nermut) #1

Still working on upgrading Fire/silver on my Android project.

I’m getting a DEX error at the end now:

> Task :transformClassesWithDesugarForDocsDebug
D8: Method name '$.$b__2' in class 'portableinterop.Class1$4' cannot be represented in dex format.
D8: Method name '$.$b__0' in class 'portableinterop.Class2$1' cannot be represented in dex format.
D8: Method name '$.$b__0' in class 'portableinterop.Class3$1' cannot be represented in dex format.
D8: Method name '$.$b__1' in class 'portableinterop.Class4$2' cannot be represented in dex format.

> Task :transformClassesWithDexBuilderForDocsDebug
com.android.builder.dexing.DexArchiveBuilderException: com.android.builder.dexing.DexArchiveBuilderException: Failed to process /media/disk2/workspace/Android-feature-continuous/Clients/Android/build/intermediates/transforms/desugar/docs/debug/7.jar

The decompiled class is fairly non-descript:

package portableinterop;

import Swift.__.Extension.NativeString;

final class Class1$1 {
    public Class1 me;

    public Class1$1() {
    }

    public void $_$b__0/* $FF was: $.$b__0*/(OpenUrlIntoApp event) {
       
       ...
    }
}

D8 is the newish Dexer in the latest android gradle plugin etc.
I’m guess it’s balking at the $.$ in the name. At least it gives you a sensible error message these days.
The classes in question seem to be Swift closures
Any insights into when this kind of name would be generated, and how I can avoid it?

Thanks

Jon


(Jon Nermut) #2

NB you can go back to the old dx.jar dexer with

android.enableD8=false

And this works, so will use that FTB. But dx.jar’s days are numbered I think.


(Jon Nermut) #3

Although… with android.enableD8=false I end up not being able to install on the device with a INSTALL_FAILED_DEXOPT:

Unable to install ... apk
com.android.ddmlib.InstallException: INSTALL_FAILED_DEXOPT
	at com.android.ddmlib.Device.installRemotePackage(Device.java:1004)

I’m guessing its the same problem later down the chain


(marc hoffman) #4

Can we get a testcase for this?


(RemObjects) #5

Thanks, logged as bugs://80977


(Jon Nermut) #6

I wish. It only shows at the end of a very complex build, which is not something I can send to you.
I’ll see if I can replicate in a smaller project.
Can you tell me under what circumstances Silver will generate a method like $.$b__0 ?


(marc hoffman) #7

Carlo will know better, he/s back in tomorrow, but these probably are closures/anonymous methods.


(Carlo Kok) #8

It’s a simple anonymous method/lambda inside a constructor (and fixed now with the next build, I hope).


(RemObjects) #9

bugs://80977 got closed with status fixed.


(Jon Nermut) #10

Yep, all of the 4 errors where about classes with closures in constructors.

Thanks!


(Jon Nermut) #11

Any chance of getting this one into a stable release soon? It’s a bit of a blocker
The workaround of moving closures out of constuctors is more major than you would think


(marc hoffman) #12

If it’s marked fixed, it will be in the next release (and given it was fixed 8 days ago, I expect its already in .2325).

yours,
marc