You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To enable this feature, the decompiler must have an API for obtaining an Abstract Syntax Tree (AST) from input code.
Not all decompilers readily support obtaining the AST, potentially necessitating forking of the decompiler codebase.
Implementing this feature across different decompilers would require creating abstractions, which can be complex.
Alignment Issue:
Even if partial recompilation is achieved, it works effectively only for the initial pass.
Editing decompiled code can lead to misalignment between the AST and the edited code.
Generic Code Handling:
A generic code handling system is necessary to support editable code, addressing the issue of code alignment after user edits.
Obfuscation Challenge:
The challenge lies in handling obfuscated code, as most Java code parsers expect valid Java source code.
Some parsers, like JavaParser (2x/3x), hard fail in cases involving obfuscation, whereas OpenRewrite (4x) can provide partial AST from obfuscated code in certain cases.
Refactoring Requirements:
Implementing this feature would necessitate significant refactoring in terms of managing decompilation, displaying decompiled code, handling syntax styling, and context analysis.
Edge Cases and Abuse Considerations:
The feature is subject to potential edge cases, particularly concerning obfuscation.
Careful consideration is needed to prevent misuse and abuse of this approach to display data.
The initial feature request would involve significant refactoring in four key areas:
Decompilation Management: Restructuring how decompilation is handled.
Display of Decompiled Code: Adapting code display methods.
Syntax Styling: Updating the approach to syntax styling.
Context Analysis: Enhancing the system's context analysis capabilities.
A new idea is being proposed:
Action: Right-click on a method to access the "edit method separately" option. Functionality: Opens a new window/tab with the following features:
Handling of Inner Classes, Fields, and Methods:
Obfuscated fields are replaced with fieldX aliases, and these aliases cannot be changed.
Inner classes are mocked, and if they have illegal names, aliases are provided.
Other methods, including lambdas, are mocked.
If they have illegal names, aliases are used.
Comments are included for reference.
Method Body Editing:
The method itself is presented in a text field, allowing users to edit and save the method body.
Additional Features (Nice to Have):
Method and Parameter Renaming: Consider allowing users to rename method names and parameter names.
Changing Types: Explore the possibility of changing data types, potentially using a miniature JASM field.
The text was updated successfully, but these errors were encountered:
<insert first idea draft here>
Potential Problems with this approach:
The initial feature request would involve significant refactoring in four key areas:
A new idea is being proposed:
Action: Right-click on a method to access the "edit method separately" option.
Functionality: Opens a new window/tab with the following features:
fieldX
aliases, and these aliases cannot be changed.The text was updated successfully, but these errors were encountered: