mapping-io import support

[NebelNidas]

The follow-up to #1505, so you can now import your previously exported mappings. Partly addresses #1531.

Currently working:

• Passing mapping file location via command line argument
• Adding last opened mapping file to the project data
• Actually applying the mappings:
  • Classes
  • Fields
  • Methods
  • Method args
  • [ ] Method vars not feasible

[lgtm-com]

This pull request introduces 1 alert when merging ce2b021 into 1533b7f - view on LGTM.com

new alerts:

• 1 for Dereferenced variable may be null

[NebelNidas]

@skylot Is there any way to determine during the decompilation's rename phase whether a local variable is present in bytecode or generated by the decompiler? And are the SSAVars' reg nums different to the VarNode ones?

I can't use the collectMethodVars trick from the exporter here, since VarNodes are only available after decompilation has finished

[skylot]

Is there any way to determine during the decompilation's rename phase whether a local variable is present in bytecode or generated by the decompiler?

I don't think it is possible. In short: bytecode only have registers next jadx split these registers into SSA variables (add version number for each register) and next in ProcessVariables merge variables which used in PHI and have same types (sets of SSA vars that can be merged available in CodeVar). Also, some SSA vars not generated because expressions can be inlined.
You can apply name for all SSA vars or CodeVar only by register number, because you don't have any additional info :(

And are the SSAVars' reg nums different to the VarNode ones?

Yes, those numbers are same

[NebelNidas]

@skylot Can you look at why the test is failing? It works fine on my machine 🤔

[skylot]

@NebelNidas
This test executed in headless mode (without UI) but you are trying to use UI objects (i.e. new MainWindow instance), so you get a HeadlessException.
Looks like you don't need these added constructor arguments (JadxProject and JadxSettings) at all, because these settings already added into JadxArgs. So just remove these new arguments and this will resolve exception.

[skylot]

Also, I think I will migrate your change to plugin by myself, so I will take your change once it ready and apply needed refactoring.

[NebelNidas]

Looks like you don't need these added constructor arguments (JadxProject and JadxSettings) at all, because these settings already added into JadxArgs

Not really the case though. JadxArgs only contains the initial CLI start arguments, not necessarily the values that are used at a later point. JadxProject's mappings path may get changed later on, JadxArgs's stays the same:

jadx/jadx-gui/src/main/java/jadx/gui/ui/MainWindow.java

Lines 428 to 431 in c5ed9e2

	private void closeMappingsAndRemoveFromProject() {
	closeMappings(true);
	project.setMappingsPath(null);
	}

Or JadxArgs' value is null (no launch arg set), but there is a mappings path stored in the current project's project file which only gets loaded into JadxProject.
Same with JadxSettings:

jadx/jadx-gui/src/main/java/jadx/gui/ui/MainWindow.java

Lines 422 to 425 in c5ed9e2

	if (resetMappingsMode) {
	wrapper.getSettings().setUserRenamesMappingsPath(null);
	wrapper.getSettings().setUserRenamesMappingsMode(UserRenamesMappingsMode.getDefault());
	}

Now, I could update the values stored in JadxArgs each time as well, but does that make sense? Why are JadxArgs and JadxSettings even split into two different files? I understand that one is jadx-core and one is jadx-gui, but why doesn't one extend the other?

[skylot]

Well, I understand your confusion, here are some details:

1. JadxArgs - storage for all jadx decompiler options (part of jadx API)
2. JadxCLIArgs - definition and parsing of jadx-cli args, have convert method to get JadxArgs. Yes, some fields duplicate JadxArgs fields, but some can have different types, like input files are strings and need to be converted to File in JadxArgs.
3. JadxSettings - jadx-gui global settings, extends JadxCLIArgs to allow override from cli, can be saved as json in java preferences.
4. JadxProject - project specific settings, saved as json file, set/override global options in JadxArgs.

So JadxArgs purpose is to store all settings, other classes just wrappers to collect/store these settings.
For jadx-gui JadxArgs options set and updated in JadxWrapper, you can copy/update settings from project if needed.

As for DiskCodeCache class, I don't want to tie it to jadx-gui, because it can be used independently, and I may move it to core or separate module later.

Also, you mention options update after initial loading: actually it is a big issue, because incremental code update is very error-prone, if you know what class code is changed you can use ClassNode.unloadCode() to remove it from cache and force decompilation on next load or ClassNode.reloadCode() to get updated code right now. But for now, I prefer full reload, as it is much easier to support and cause fewer errors, and anyway it should be implemented for correct first load.
So the best approach is to put correct options into JadxArgs in JadxWrapper, and if these options updated, just call reload.

[skylot]

@NebelNidas I merged this PR into jadx-next branch, I will refactor your changes into separate module/plugin. I plan to merge that branch after next jadx release (August 20).
Thanks again for your contribution 👍