Use $ character as separator of inner classes in .jobf file

[unoexperto]

Could you please use $ character as separator of inner classes in .jobf file instead of dot ?

c android.support.constraint.solver.widgets.d = Rectangle
c android.support.constraint.solver.widgets.e = Snapshot
c android.support.constraint.solver.widgets.e.a = C0008a
c android.support.constraint.solver.widgets.f = WidgetContainer

That way it would allow me to distinguish between class a in package android.support.constraint.solver.widgets.e and subclass a in class e in package android.support.constraint.solver.widgets.

I can provide PR if you're ok with proposed change.

I see somewhat related issue here #179

[bagipro]

@unoexperto
You could enable deobfuscation which prevents collides

[unoexperto]

@sergey-wowwow Thank you for quick response, Sergey. My problem lies in a bit different field. I'd like to use JADX mapping in Fenflower. Inability to distunguish class from inner class complicates mapping process.

Moreover ideally I'd prefer android/support/constraint/solver/widgets/e$a format rather than android.support.constraint.solver.widgets.e.a.

[skylot]

@unoexperto thank you for this issue! It is serious error to use not raw (without $) class names as a key for search because this can lead to name clash, like for classes with names:

a.b$c
a.b.c

I fixed this in latest commit, please check latest unstable build.

[unoexperto]

@skylot Could you please also comment why methods are not renamed in resulting .java files even though I see them in jobf file ?

For example

m jp.line.android.sdk.login.LineLoginFuture.ProgressOfLogin.<clinit>()V = m22686<clinit>
m jp.line.android.sdk.login.LineLoginFuture.ProgressOfLogin.<init>(Ljava/lang/String;III)V = m22687<init>

My settings are

[skylot]

@unoexperto sorry, I forget to fix classes in methods :(

[unoexperto]

@skylot After digging into it more it seems to me code that generates .jobf doesn't respect settings. So compared to previous screen I changed Minimum name length to 2 and now I see renamed methods of jp.line.android.sdk.login.LineLoginFuture. I think .jobf should only contain records that are really renamed. Otherwise sources generated by JADX and Fernflower (using renaming map) will be different.

And in addition to your comment there are also classnames in field lines such as

f com.flipboard.bottomsheet.commons.a.e:Lcom/flipboard/bottomsheet/commons/a$b; = f7345e
f com.flipboard.bottomsheet.commons.a.f.a:Lcom/flipboard/bottomsheet/commons/a; = f7340a
f com.flipboard.bottomsheet.commons.a.f:Lcom/flipboard/bottomsheet/commons/a$c; = f7346f
f com.flipboard.bottomsheet.commons.a.g:Ljava/util/Comparator; = f7347g

[skylot]

@unoexperto name length settings used like this: shouldRename = len < minLength || len > maxLength. So for minLength = 2 all methods with name length = 1 will be renamed.
About not renamed parts in .jobf: mapping contains all classes even not renamed to allow rename it by editing file and it easier if that line already exists.

[unoexperto]

@skylot I see. But how would app that uses .jobf know what to rename and what not ? That complicates automated syncronization of sources generated by jadx and other apps. Perhaps you could provide extra column in each line that indicates if rule was used or not ?

[skylot]

@unoexperto Hm, actually I don't see any not renamed items in jobf file. Looks like I totally forget how it works (((

[skylot]

@unoexperto anyway I commit fix for methods and fields. I hope it helps

[unoexperto]

Thanks! I'll close this issue.