What does $$ in javac generated name mean?

Question

When shifting through java call graph generated by libraries like DependencyFinder and java-callgraph, I found out that java compiler generate names for anonymous functions, inner classes, etc.

I've found out the meaning of a couple of them (please correct if I'm wrong):

• org.example.Bar$Foo refers to Foo, which is an inner class of org.example.Bar.
• org.example.Bar$1 refers to an anonymous class declared inside one of the methods of org.example.Bar.
• org.example.Bar.lambda$spam$1() refers to a lambda declared inside of org.example.Bar.spam() method.

However, I also found:

1. org.example.Bar$$Lambda$2.args$1
2. org.example.Bar$$Lambda$2.call()
3. org.example.Bar$$Lambda$7.lambdaFactory$()
4. org.example.Bar$$Lambda$7.get$Lambda()

What does the four name above refer to? What does double dollar ($$) mean?

Answer 1

The classes for lambda expressions are not javac generated, but created at runtime by the JRE. Their names are completely unspecified and you can’t rely on any naming scheme.

But obviously, Oracle’s current JRE has a recognizable pattern. It appends $$Lambda$n to the name of the defining class whereas n is an increasing number, which reflects the creation order at runtime, rather than any property of the compiled code.

You can verify this with the following program:

public class Test {
    public static void main(String... args) {
        if(args.length==0) {
            final boolean meFirst = Math.random()<0.5;
            if(meFirst) {
                Runnable r=Test::main;
                System.out.println("first run:\t"+r.getClass());
            }
            main("second run");
            if(!meFirst) {
                Runnable r=Test::main;
                System.out.println("first run:\t"+r.getClass());
            }
        }
        else {
            Runnable r=Test::main;
            System.out.println(args[0]+":\t"+r.getClass());
            if(args[0].equals("second run")) main("last run");
        }
    }
}

Depending on the state of the random meFirst flag, it will print either

first run:  class Test$$Lambda$1
second run: class Test$$Lambda$2
last run:   class Test$$Lambda$2

or

second run: class Test$$Lambda$1
last run:   class Test$$Lambda$1
first run:  class Test$$Lambda$2

It shows that the first generated class always gets the number 1, regardless of whether it’s one of the first two method references instantiated in the first main invocation or the third method reference, instantiated in the first recursion. Further, the 3rd execution always encounters the same class as the 2nd, as it’s the same method reference expression (note: distinct expression, as the target of all expressions is the same) and the class is re-used.

Depending on the version, you may further see something like /number appended to the names, which hints that the names really don’t matter, as each of these classes has another unique identifier (they are so called “anonymous classes” which you can’t locate via ClassLoader and name).

Field names like args$n within these classes represent the n’th captured value. Since the LambdaMetafactory has no knowledge about the actual names of the captured variables, it has no other choice but to generate such names.

---

But as said, that’s an implementation artifact. It’s possible to maintain such a naming pattern, as long as a new class is generated for each creation site in each defining class. But since the specification allows arbitrary sharing/reusing of classes and instances representing equivalent lambda expressions (doing the same) and method references (targeting the same method), such a naming pattern is not possible with every implementation strategy.