[feature] Can Jadx reduce deeply nested structures #2

[DecompExplorer]

Describe your idea

Description 1:

Hi, it's me again. I created the issue Can Jadx reduce deeply nested structures before and it was fixed by this commit. I have found that Jadx works well in most similar cases since that version, while I have also found some other cases that may lead to deeply nested structures, which may be introduced by that commit.

Example 1:

The following code snippet is from org/bukkit/command/defaults/PlaySoundCommand.java in the project Bukkit, and the corresponding .class file can be found here

        if (location.distanceSquared(soundLocation) > fixedVolume * fixedVolume) {
            if (minimumVolume <= 0.0D) {
                sender.sendMessage(ChatColor.RED + playerArg + " is too far away to hear the sound");
                return false;
            }
            ...
        } else {
            player.playSound(soundLocation, soundArg, (float) volume, (float) pitch);
        }

The corresponding code is generated by Jadx just before the commit:

        if (location.distanceSquared(soundLocation) <= fixedVolume * fixedVolume) {
            player.playSound(soundLocation, soundArg, (float) volume, (float) pitch);
        } else if (minimumVolume <= 0.0d) {
            sender.sendMessage(ChatColor.RED + playerArg + " is too far away to hear the sound");
            return false;
        } else {
            ...
        }

The corresponding code is generated by Jadx after the commit:

        if (location.distanceSquared(soundLocation) <= fixedVolume * fixedVolume) {
            player.playSound(soundLocation, soundArg, (float) volume, (float) pitch);
        } else {
            if (minimumVolume <= 0.0d) {
                sender.sendMessage(ChatColor.RED + playerArg + " is too far away to hear the sound");
                return false;
            }
            ...
        }

The previous version has fewer levels of nesting and provides a more concise structure, while the latter version (including the latest version) introduces a direct usage of else after the first if statement, thereby increasing the depth of nesting of subsequent statements. I was wondering if Jadx is able to adopt the approach of the previous version to reduce nested structures when encountering these kinds of cases.

Example 2:

The following code snippet is from org/apache/commons/imaging/common/BinaryOutputStream.java in the project commons-imaging (commit:92440e4206a12ffd455def326c181058b53b6681), and the corresponding .class file can be found here

    public final void write3Bytes(final int value) throws IOException {
        if (byteOrder == ByteOrder.BIG_ENDIAN) {
            ...
        } else {
            ...
        }
    }

The corresponding code is generated by Jadx just before the commit:

    public final void write3Bytes(int value) throws IOException {
        if (this.byteOrder == ByteOrder.BIG_ENDIAN) {
            ...
            return;
        }
        ...
    }

The corresponding code is generated by Jadx after the commit:

    public final void write3Bytes(int value) throws IOException {
        if (this.byteOrder == ByteOrder.BIG_ENDIAN) {
            ...
        } else {
            ...
        }
    }

In comparison to the previous version, the latter version (including the latest version) uses else block rather than early return in method write3Bytes. I was wondering if it's what Jadx is intended to do. I am worried that it will lead to deeply nested structures in some other cases. Thank you.

Description 2:

In addition, I have found that while combined with if statements may cause Jadx to generate deeply nested structures.

The following code snippet is from org/apache/commons/codec/binary//CharSequenceUtils.java in the project commons-codec(commit: fe6dbee7524a5aa4160751155be2e8c975f66c68), and the corresponding .class file can be found here:

        while (tmpLen-- > 0) {
            char c1 = cs.charAt(index1++);
            char c2 = substring.charAt(index2++);

            if (c1 == c2) {
                continue;
            }

            if (!ignoreCase) {
                return false;
            }

            // The same check as in String.regionMatches():
            if (Character.toUpperCase(c1) != Character.toUpperCase(c2)
                    && Character.toLowerCase(c1) != Character.toLowerCase(c2)) {
                return false;
            }
        }

The corresponding code generated by Jadx:

        while (true) {
            int i = tmpLen;
            tmpLen--;
            if (i > 0) {
                int i2 = index1;
                index1++;
                char c1 = cs.charAt(i2);
                int i3 = index2;
                index2++;
                char c2 = substring.charAt(i3);
                if (c1 != c2) {
                    if (!ignoreCase) {
                        return false;
                    }
                    if (Character.toUpperCase(c1) != Character.toUpperCase(c2) && Character.toLowerCase(c1) != Character.toLowerCase(c2)) {
                        return false;
                    }
                }
            } else {
                return true;
            }
        }

Compared to the original source code, code generated by Jadx uses while(true) instead of while with conditions, which increases the level of nesting. Furthermore, Jadx negates the condition c1 == c2 and include subsequent statements within the code block, which also increases the nesting depth of the code. Can Jadx improve it to reduce nested code structures? Thank you for your effort in maintaining Jadx.

Jadx version: latest