Multiple this$1 fields when mixing subclassing and inner classes

[Stefan Reich]

I'm thinking about becoming a JCP member to turn this idea (merging this$x
fields) into a JSR.

The JCP paperwork seems scary though, and I don't speak their programming
language (legalese) enough to really get what is demanded...
https://jcp.org/aboutJava/communityprocess/JSPA2.pdf

It seems I could become a JCP member as an individual without having to pay
a fee. Not sure what all the "IP" fuss is about. "Are you willing and able
to sign the JSPA and license IP"? License MY IP to Oracle? Or the other way
around? Who can help me out there?

Greetings

On Tue, 10 Sep 2019 at 01:30, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Oh, I didn't know about those JDK 11 changes. That may in fact break the
> idea of merging the references. I'm sure it can still be done, but might
> require a spec change. And who's gonna pay for that?
>
> :-D
>
> Thanks
>
> On Tue, 10 Sep 2019 at 01:17, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> On 10/09/2019 9:09 am, Stefan Reich wrote:
>> >     But you're not talking about bytecode here you're talking about
>> inside
>> >     the VM. If there is an invokespecial on this$1 of type A then the
>> >     constant pool lookup of its type will be A and we will resolve the
>> call
>> >     based on A's methods. If it were of type B then the resolution
>> process
>> >     would be different. There's nowhere to "insert a cast" here.
>> >
>> >
>> > Can invokespecials on this$0/this$1 happen? I'm struggling to imagine a
>> > case for this.
>> >
>> > invokespecial invokes private instance methods, superclass methods or
>> > constructors. Superclass methods don't apply, neither do constructors.
>> > And calls to private methods happen through bridges (just verified this
>> > for myself again :):
>> >
>> >        13: aload_0
>> >        14: getfield      #1                  // Field this$0:Lbla;
>> >        17: invokestatic  #4                  // Method
>> > bla.access$000:(Lbla;)V
>> >
>> > So what remains?
>>
>> This changed in JDK 11 with the addition of nestmates. Now inner classes
>> have direct private access, no bridges needed, and we use invokespecial
>> or invokevirtual as appropriate. For private methods invokevirtual is
>> mainly used now, but of course we don't do virtual dispatch - there are
>> special rules for private method resolution and selection.
>>
>> class A {
>>    void m() {}
>>    class InnerA {
>>      void callM() { m(); }
>>    }
>> }
>>
>>   void callM();
>>      descriptor: ()V
>>      flags: (0x0000)
>>      Code:
>>        stack=1, locals=1, args_size=1
>>           0: aload_0
>>           1: getfield      #1                  // Field this$0:LA;
>>           4: invokevirtual #13                 // Method A.m:()V
>>           7: return
>>        LineNumberTable:
>>          line 4: 0
>>
>> >     BTW what introspection tool did you use to show this?
>> >
>> > My own tools ("JavaX")... here's the example program:
>> > http://code.botcompany.de/1025166
>>
>> Thanks for the pointer.
>>
>> Cheers,
>> David
>>
>> > Many greetings :)
>>
>
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems