|Powered by |
Best viewed with
|Home | Project page | Applet | Download | FAQ | Feedback | Documentation | License | History | Links | Blue Sky|
This section contains features that I think would be great to have, but are also very hard to implement. The name of the section is inspired, by Mozilla.
Currently this are all my own ideas. But if you send me an idea for an interesting feature, I will add it to this list.
If java gets called with `
-O' switch, it inlines methods,
that are private, final, or static and contain no loops. When
decompiling this it sometimes produces really ugly code. The right
way to solve this would be to outline the code again. This is
possible but requires to find the inlined method.
The name `outline' was suggested by Michael.
The local variable naming is very stupid. Even with pretty it just names the variable after the type with a unifying number appended. A method containing very much objects of the same type looks very ugly.
My plan is looking at the assignments. If we have locals in assignments
int l_1 = array.length String l_2 = object.getName()we could name them "length" and "name". If we have assignments:
MenuItem local_1 = new MenuItem("Open"); MenuItem local_2 = new MenuItem("Save");
good names would be
It is currently possible to assign a (hint name,type) pair to a local. If the type matches, the local will be named after hint name. This could be extended by giving them several weighted hints and constructing the name in an intelligent way.
First there should be a good Renamer: Methods that simply return a field value should be renamed to getFieldName. Fields should be named after their type, maybe also by assignments (see section about local variable names).
The deobfuscator should detect inner and anonymous variables, synthetic methods and so on, and rename them accordingly.
The obfuscator should detect Class.forName constructs (and similarly for methods and fields) and if their parameters are constant it should change the parameter according to the rename function.
It would be nice if the decompiler could merge the javadoc comments into the class file. More and more people use javadoc to comment the public api of their java classes. It shouldn't be too difficult to copy them back into the java code.
This doesn't need to be built into the decompiler. A script that takes the javadoc pages and the decompiled code can easily merge them.