CFR not fed classes of libraries referenced in the project

[Lanchon]

hi again,

if you add jars to the compile or compileOnly (ie: provided) scopes, these are not passed to CFR. CFR needs all classes to do better decompilation. this triggers warnings by CFR, such as:

/*
 * Decompiled with CFR 0_123.
 * 
 * Could not load the following classes:
 *  org.xmlpull.v1.XmlPullParser
 *  org.xmlpull.v1.XmlPullParserException
 *  org.xmlpull.v1.XmlSerializer
 */

thanks!

[caoli5288]

It just a comments. decompiler do NOT need all classpath to decompile a class file. I'll disable comments next version.

[Lanchon]

yes, it needs the full classpath. it has to do type inference of locals.

imagine you have this code in a method:

Exception e;
if (someBool()) e = new IllegalStateException();
else e = new NullPointerException();
setException(t)    // setException() takes an Exception argument
setThrowable(t)    // setThrowable() takes an Throwable argument

the type of local 'e' is not declared in the bytecode, so it has to be inferred by the decompiler.

so what is the type of e?

• call TSUB the most subclassed common superclass of IllegalStateException and NullPointerException.
• call TSUPER the most subclassed of Exception and Throwable
• then e can be anything between TSUPER and TSUB (inclusive).

in this case:
TSUB = RuntimeException
TSUPER = Exception
so e can be Exception or RuntimeException.

but how does the decompiler know the values of TSUB and TSUPER? even though it is not decompiling any of the exception classes, it needs to access the definitions of the named exceptions and their full object hierarchy to infer a valid type for e and properly decompile the method above that simply uses the exceptions.

this is why CFR needs and looks for extra classes during a decompile, and complains in the generated comment if any wasn't found. if it can't infer the type of e, it will just set it to java.lang.Object and generate invalid code.

and sometimes there is no possible value for e, which means that there were 2 or more Java variables that were collapsed into a reused bytecode stack item. and all this doesn't even mention interfaces :) decompilation is more complex than you imagine!

[caoli5288]

THX. You are right. I'll try fix it next day. :)

[Glaezz]

Iam have this trouble, in classes too, how to fix this?