Review request for JDK-8023373

Attila Szegedi attila.szegedi at oracle.com
Wed Aug 21 05:32:14 PDT 2013


What do you mean by synthesizing methods twice? Anyway, I can look into modifying it to have Java.super() -- I might have to retain the "super$" methods though, as I think the JVM verifier will reject a different class trying to do INVOKESPECIAL for a super call - as far as I know, INVOKESPECIAL can't call outside its own class hierarchy…

So basically, I would need to keep the super$Xxx methods in the adapter, and the object returned from Java.super(adapter) would need to delegate to adapter.super$Xxx. Then the only question is whether I keep the super$ methods public and thus give two ways to people to invoke these methods, or make them package private so only the Java.super() class can invoke them as part of the delegation.

On Aug 21, 2013, at 2:09 PM, "Jim Laskey (Oracle)" <james.laskey at oracle.com> wrote:

> I lean toward 2) because of the elegance and consistency.  super$ looks hacked in.  I also like the fact you don't have to synthesize methods x2.  super should be reasonably rare.  I've only needed it once so far (using MethodHandle hack.)
> 
> Cheers,
> 
> -- Jim
> 
> 
> On 2013-08-21, at 8:17 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
>> I was thinking of how to properly implement super calls. Basically, I had two ideas:
>> 
>> 1) add methods with prefix "super$" to adapters:
>> 
>> var cap = new java.io.FilterWriter(w) {
>>   write: function(s, off, len) {
>>       cap.super$write(capitalize(s), off, len)
>>   }
>> }
>> 
>> function capitalize(s) { ... } // capitalizes a string
>> 
>> (I'll use this "capitalizing writer" example throughout)
>> 
>> 2) Add a separate Java.super() function that creates a super-invoking adapter for another adapter:
>> 
>> var cap = new java.io.FilterWriter(w) {
>>   write: function(s, off, len) {
>>       cap_super.write(capitalize(s), off, len)
>>   }
>> }
>> var cap_super = Java.super(cap)
>> 
>> Solution (1) seems simpler to use and is simpler to implement. It is also apparently compatible with how Rhino exposes super methods. Solution (2) has the advantage of not introducing synthetic identifiers into the method namespace of adapters. From conceptual elegance point of view, I'd say (2), but my pragmatic self nudges me towards (1). For a while I was hoping I can sneak in the result of Java.super() into the literal itself and thus avoid using cap_super as another top-level identifier, like this:
>> 
>> var cap = new java.io.FilterWriter(w) {
>>   super: Java.super(cap),
>>   write: function(s, off, len) {
>>       this.super.write(capitalize(s), off, len)
>>   }
>> }
>> 
>> but unfortunately, this doesn't fly: cap is not yet defined when Java.super(cap) is evaluated, and it'd require using the somewhat awkward looking "this.super." construct too. That said, I can still add Java.super() if people think it'd be nicer; the two are actually not even mutually exclusive.
>> 
>> Attila.
>> 
>> On Aug 21, 2013, at 1:07 PM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:
>> 
>>> +1. It would be nice if we had a more consistent way to express it like Java.super or something, though, for consistency. Even though Rhino does it this way. What do you other guys think?
>>> 
>>> /M
>>> 
>>> On Aug 21, 2013, at 11:19 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>> 
>>>> Please review JDK-8023373 at http://cr.openjdk.java.net/~attila/8023373/webrev.00
>>>> 
>>>> Much of the change is just refactoring -- we already had code for emitting super calls, as overridable methods that did not have an overridde specified by an adapter instance had to delegate to the super call, so the change really was to extract it into emitSuperCall() method, which in turn made generateSuperMethod() really trivial. The rest of the changes in generateMethod() are really just  refactorings, and moving some code around (e.g. definition of nextLocalVar was moved closer to the point where it was used). 
>>>> 
>>>> Thanks,
>>>> Attila.
>>> 
>> 
> 



More information about the nashorn-dev mailing list