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

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

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.

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

Can we get a testcase for this?

Thanks, logged as bugs://80977

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 ?

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

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

bugs://80977 got closed with status fixed.

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

Thanks!

2 Likes

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

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