static invoke function missing

[jonnynch]

Source code

public class TestDecompiler {
	static 
    {
        load();
    }
	private static void load()
    {
		System.out.println("test");
    }
}

After decompilation

import java.io.PrintStream;

public class TestDecompiler
{
  static {}
  
  private static void load()
  {
    System.out.println("test");
  }
}

[JustGregory-zz]

If you use the classname in the call (like this)

static {
  TestDecompiler.load();
}

does it do the same? I'm not sure, but that would be something I might try.

[jonnynch]

Perhaps, but I think most of the people use decompiler to decompile the binary which is without source code. Under this situation, based on the decompiled source from jd-gui, we have no way to know wether there is such a static method call in original source.

[JustGregory-zz]

I know, jonnynch, I thought you were giving a template example, so my recommendation was to try with your code given above.

Okay. One thing I'm not sure I understand, is what jd-core/jd-gui is doing behind the scenes when it comes to leaving code blocks empty like this. It isn't the first time I've seen comments about missing or non-decompiled source lines. And it's not just with jd-gui that this happens.

When the core comes to lines that it doesn't recognize, is it simply abandoning it, instead of noting it for the user to handle? Because instead of wondering what the heck is supposed to be in the empty space, I'd prefer jd-gui/jd-core to generate some notice text as a comment line in the generated source (to "See note 1234" or some such thing), and then append a more fully descriptive not of the problem that is not being decompiled (either at the end of the source-class file or as a standalone text file) possibly with a "I think this should be ..." set of lines.

Sure, my idea would allow (or force) jd-gui to output its "best-guess" description of what it came across, what cannot be determined, as well as what it thinks the code snippet at the location should be -- thereby giving the user final control in what gets placed into post-decompile code review. This idea would shift issues away from saying "JD-Gui didn't decompile this code block" to then discussing how to handle analysis or implementation of the decomp process for specific compiled code implementations.

Just my two cents -- well, maybe less than half a cent -- of opinion, but I believe it has merit enough to mention.

[jonnynch]

I'd prefer jd-gui/jd-core to generate some notice text as a comment line in the generated source (to "See note 1234" or some such thing)

That's exactly what I think. In fact, there are other decompilers that may not be able to decompile fully. But at least they will leave some commented hex code. As i know jd-gui also do the similar thing in some scenarios, but not this time.