Java中的“真实”和“合成”方法参数是什么？

Question

Looking into jlrExecutable class I've found a method called hasRealParameterData() and from its name and code context I assume that it tells whether a particular method has 'real' or 'synthetic' params.

If I take eg method Object.wait(long, int) and call hasRealParameterData() it turns out that it returns false which is confusing to me, as the method is declared in Object class along with its params.

From this I've got a couple of questions:

1. What are 'real' and 'synthetic' Method parameters and why Java believes that params of Object.wait(long, int) are not 'real'?
2. How can I define a method with 'real' params?

Answer 1

Preamble - don't do this.

As I mentioned in the comments as well: This is a package private method. That means:

[A] It can change at any time, and code built based on assuming it is there will need continuous monitoring; any new java release means you may have to change things. You probably also need a framework if you want your code to be capable of running on multiple different VM versions. Maybe it'll never meaningfully change, but you have no guarantee so you're on the hook to investigate each and every JVM version released from here on out.

[B] It's undocumented by design. It may return weird things.

[C] The java module system restriction stuff is getting tighter every release; calling this method is hard, and will become harder over time.

Whatever made you think this method is the solution to some problem you're having - unlikely. If it does what you want at all, there are probably significantly better solutions available. I strongly advise you take one step backwards and ask a question about the problem you're trying to solve, instead of asking questions about this particular solution you've come up with.

Having gotten that out of the way...

Two different meanings

The problem here is that 'synthetic' means two utterly unrelated things and the docs are interchanging the meaning. The 4 unrelated meanings here are:

• SYNTHETIC , the JVM flag. This term is in the JLS.
• 'real', a slang term used to indicate anything that is not marked with the JVM SYNTETHIC flag. This term is, as far as I know, not official. There isn't an official term other than simply 'not SYNTHETIC'.
• Synthetic, as in, the parameter name (and other data not guaranteed to be available in class files) are synthesised.
• Real, as in, not the previous bullet point's synthetic. The parameter is fully formed solely on the basis of what the class file contains.

The 'real' in hasRealParameterData is referring to the 4th bullet, not the second. But, all 4 bullet point meanings are used in various comments in the Executable.java source file!

The official meaning - the SYNTHETIC flag

The JVM has the notion of the synthetic flag.

This means it wasn't in the source code but javac had to make this element in order to make stuff work. This is done to paper over mismatches between java-the-language and java-the-VM-definition, as in, differences between .java and .class . Trivial example: At least until the nestmates concept, the notion of 'an inner class' simply does not exist at the class file level. There is simply no such thing. Instead, javac fakes it: It turns:

class Outer {
  private static int foo() {
    return 5;
  }

  class Inner {
    void example() {
      Outer.foo();
    }
  }
}

Into 2 seemingly unrelated classes, one named Outer , and one named Outer$Inner , literally like that. You can trivially observe this: Compile the above file and look at that - 2 class files, not one.

This leaves one problem: The JLS claims that inner classes get to call private members from their outer class. However, at the JVMS (class file) level, we turned these 2 classes into separate things, and thus, Outer$Inner cannot call foo . Now what? Well, javac generates a 'bridger' method. It basically compiles this instead:

class Outer {
  private static int foo() {
    return 5;
  }

  /* synthetic */ static int foo$() {
    return foo();
  }
}

class Outer$Inner {
  private /* synthetic */ Outer enclosingInstance;

  void example() {
    Outer.foo$();
  }
}

The JVM can generate fields, extra overload methods (for example, if you write class MyClass implements List<String> {} , you will write eg add(String x) , but .add(Object x) still needs to exist to cater to erasure - that method is generated by javac , and will be marked with the SYNTHETIC modifier.

One effect of the SYNTHETIC modifier is that javac acts as if these methods do not exist. If you attempt to actually write Outer.foo$() in java code, it won't compile, javac will act as if the method does not exist. Even though it does. If you use bytebuddy or a hex editor to clear that flag in the class file, then javac will compile that code just fine.

generating parameter names

Weirdly, perhaps, in the original v1.0 Java Language Spec, parameter types were, obviously, a required part of a method's signature and are naturally encoded in class files. You can write this code: Integer.class.getMethods(); , loop through until you find the static parseInt method, and then ask the jlrMethod instance about its parameter type, which will dutifully report: the first param's type is String . You can even ask it for its annotations.

But weirdly enough as per JLS 1.0 you cannot ask for its name - simply because it is not there , there was no actual need to know it, it does take up space, java wanted to be installed on tiny devices (I'm just guessing at the reasons here), so the info is not there. You can add it - as debug info, via the -g parameter, because having the names of things is convenient.

However, in later days this was deemed too annoying, and more recently compilers DO stuff the param name in a class file. Even if you do not use the -g param to 'include debug symbol info'.

Which leaves one final question: java17 can still load classes produced by javac 1.1 . So what is it supposed to do when you ask for the name of param1 of such a method? The name simply cannot be figured out, it simply isn't there in the class file. It can fall back to looking at the debug symbol table (and it does), but if that isn't there - then you're just out of luck.

What the JVM does is make that name arg0 , arg1 , etc. You may have seen this in decompiler outputs.

THAT is what the hasRealParameterData() method is referring to as 'real' - arg0 is 'synthesized', and in contrast, foo (the actual name of the param) is 'real'.

So how would one have a method that has 'real' data in that sense (the 4th bullet)? Simply compile it, it's quite hard to convince a modern java compiler to strip all param names. Some obfuscators do this. You can compile with a really old -target and definitely don't add -g , and you'll probably get non-real, as per hasRealParameterData() .