New candidate JEP: 371: Hidden Classes

[Remi Forax]

----- Mail original -----
> De: "David Lloyd" <david.lloyd at redhat.com>
> À: "David Holmes" <david.holmes at oracle.com>
> Cc: "hotspot-dev" <hotspot-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Lundi 27 Janvier 2020 14:56:57
> Objet: Re: New candidate JEP: 371: Hidden Classes

> On Fri, Jan 24, 2020 at 4:56 PM David Holmes <david.holmes at oracle.com> wrote:
>>
>> FYI.
> 
> I'm a bit curious about this:
> 
>> To invoke private nestmate instance methods from code in the hidden class, use
>> invokevirtual or invokeinterface instead of invokespecial. Generated bytecode
>> that uses invokespecial to invoke a private nestmate instance method will fail
>> verification. invokespecial should only be used to invoke private nestmate
>> constructors.
> 
> This seems pretty unusual.  Don't we normally use invokespecial for
> private method invocations?  What is the reasoning for this?

It's the new usual since 11 and the introduction of nestmates,
before javac was generating an accessor method (the access$000 methods).

class Foo {
  private void privateMethod() {
  }

  public static class Bar {
    public void m() {
      new Foo().privateMethod();
    }
  }

  public static void main(String[] args) {
    new Bar().m();
  }
}

The bytecode of 'm()' is

public void m();
    Code:
       0: new           #7                  // class Foo
       3: dup
       4: invokespecial #9                  // Method Foo."<init>":()V
       7: invokevirtual #10                 // Method Foo.privateMethod:()V
      10: return

When calling a method (this is different for constructor),  invokespecial semantics has no been extended to be able to call private method of classes of the same nest, only invokevirtual/invokeinterface and invokestatic have that capability. 

The reason is that invokespecial semantics is already a patchwork of several semantics, you can call a constructor, a private method of the same class and a method of the super class and each semantics has it's own verification rule.
Given that invokevirtual already had to be extended, adding a new mode for invokespecial was not necessary.

As a trivia, if you take a look to the dex file used by Android, the opcode invokespecial doesn't exist, instead you have several other opcodes, one for each semantics.

> 
> --
> - DML

Rémi