Can we define a method name alias when using a Java object/class form Nashorn?

[Jim Laskey (Oracle)]

You might consider using an ordinary JS object to wrap the Java Promise Object.  Even though the wrapper exists, the indirection should eventually optimize out (more so than for JSObject.)  As far as having more objects about, I think it’s small relative to other objects in the background (MethodHandles.)  This will also give you the advantage of having Promise be a real JS Object.  Who knows what kinds of things users hang off of the promise.

Cheers,

— Jim




> On Mar 9, 2017, at 8:20 AM, Paulo Lopes <pmlopes at gmail.com> wrote:
> 
> Hi,
> 
> For the Vert.x project I've created a simple Promise implementation as
> available in a Browser.
> 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
> 
> I've then played with babel to transpile the ES7 async - await to Promises
> and I must say that it works fine under Nashorn.
> 
> Now my concern is that since this code is always in the hot-path I'd like
> to translate it to Java so it could be executed/jitted faster, however the
> Promise API has a small issue with that, it defines a method named: "catch"
> 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/catch
> 
> This is forbidden name for a java method since according to the JLS "catch"
> is a reserved word and Java is way more strict than JS. My question is, now:
> 
> Do I need to implement this using the JSObject interface where I can react
> to a "getMember" to return a Function and then handle it on the "call"
> method, or is there some "magic" where I can keep it all under a single
> Java object and make an alias?
> 
> I expect that if I implement the JSObject that I'll start making to many
> small lived objects and the performance improvements would be lost with the
> GC pressure...