SES on JVM: struggling with __proto__ cycle for Function

[dckc]

I've got an application where most of the deployment platform is the JVM and I'd like to re-write it in SES. I mentioned this to @erights and he said figuring out how to do SES on the JVM would be useful; for example, for interoperability with RChain.

Legend has it Nashorn on Java 9 has pretty good javascript support. At first it walk balking at const but i learned:

To activate ES6 support, use --language=es6 on the command line. -- Laskey

That got me a little further; in particular, I'm using openjdk 10 via docker:

# start in the shim/examples directory of the proposal-realms repo

docker run -v $(cd ..; /bin/pwd):/opt -w /opt --rm -it openjdk:10 \
       jjs --language=es6 dist/realm-shim.js examples/simple.js

But no joy:

Exception in thread "main" java.lang.RuntimeException: dist/realm-shim.js:95:10 ES6 destructuring is not yet implemented
    const { contextFunction } = contextRec;

context: 3ccc45a646d https://github.com/tc39/proposal-realms

p.s. is there a better repo in which to raise this issue? It sorta belongs in proposal-realms, but I'm not sure this is tc39 business.

[dckc]

Wrong result in test: destructuring, declarations - with objects -- https://gist.github.com/winston01/49273505e4e98662b606ddec9c33079c

odd... because jep 292 from 2014/11 says:

These are candidates for inclusion in JDK 9 update releases:

• Arrow functions
• Enhanced object literals
• Destructuring assignment
• ...

Created	Updated
2014/11/27 00:31	2017/03/09 13:36

[dckc]

https://kangax.github.io/compat-table/es6/#nashorn10 shows 28%. :-/

[dckc]

I wonder if transpiling away the features Nashorn doesn't support is fair game.

[dckc]

After transpiling away destructuring, spread parameters and classes, the next challenge is:

lib/realm-shim.js:306 TypeError: Cannot redefine property "name" of function () {
throw new Error("Not available");
}

ses-on-jvm.zip

• a4e650a - cannot redefine name of function

[dckc]

Using GraalVM I get a different failure mode:

docker run -v $(/bin/pwd):/opt -w /opt --rm -it findepi/graalvm \
	js \
		src/realm-shim.js \
		src/simple.js
ReferenceError: document is not defined
	at <js> createBrowserContext(src/realm-shim.js:340:11073-11080)
	at <js> createContextRec(src/realm-shim.js:353:11434-11448)
	at <js> Realm(src/realm-shim.js:883:28096-28113)
	at <js> :program(src/simple.js:6:132-142)

[dckc]

Aha... graalvm acts more like node if you invoke it as node. But then it complains about a proto cycle:

docker run -v $(/bin/pwd):/opt -w /opt --rm -it findepi/graalvm \
	node \
		src/realm-shim.js \
		src/simple.js
/opt/src/realm-shim.js:294
    setPrototypeOf(TamedFunction, contextFunction.prototype.constructor);
    ^

TypeError: Cannot create__proto__ cycle for [object Function]
    at setPrototypeOf (native)
    at repairFunction (/opt/src/realm-shim.js:294:5)
    at repairFunctions (/opt/src/realm-shim.js:306:5)
    at sanitize (/opt/src/realm-shim.js:319:5)
    at createContextRec (/opt/src/realm-shim.js:366:5)
    at getCurrentContextRec (/opt/src/realm-shim.js:378:12)
    at /opt/src/realm-shim.js:939:46
    at /opt/src/realm-shim.js:2:83
    at Object.<anonymous> (/opt/src/realm-shim.js:1:64)
    at Module._compile (module.js:652:30)

[dckc]

Is Cannot redefine property "name" of function a failure of Nashorn to comply with ES specs? Or is it shim black magic that doesn't quite work in this context?

Likewise Cannot create__proto__ cycle for [object Function] in GraalVM?

@jfparadis @warner @erights

[erights]

https://kangax.github.io/compat-table/es6/#nashorn10 shows 28%. :-/

I think that disqualifies nashorn :(

[dckc]

And GraalVM?

[erights]

And GraalVM?

do we have any conformance numbers on it?

[dckc]

I can look more for conformance numbers, but first, would you please help me understand the specific case of whether Cannot create__proto__ cycle for [object Function] indicates a failure of GraalVM to conform?

[dckc]

By the way... 28% was not 28% conformance on test262. It was 28% support for leading-edge features.

[erights]

Not clear. It is conformant to prevent proto cycles, but this code should not have tried to create one. So it depends on why it thought it had a proto cycle that needed to be rejected.

[erights]

Hi @dckc , at https://github.com/Agoric/Jessie/blob/master/src/bundle/whitelist.js (derived from https://github.com/Agoric/SES/blob/master/src/bundle/whitelist.js ) I list a first attempt at the subset of the SES runtime to be included in Jessie. I picked this to try to find a sweetspot between enabling a standalone implementation of Jessie to be simple vs including enough to keep it pleasant to program in Jessie; especially writing smart contracts. How does this look regarding both goals?

[dckc]

Looks OK at a glance. (String is missing a }).

Why is Boolean empty? I guess I can't think of anything that I would expect to be there, so I guess that's OK.

As to implementing... WeakMap is the first thing that doesn't look easy. But I see Java has WeakHashMap in the standard library. Presuming that works well enough, this looks straightforward.

For writing smart contracts, I'd have to try it to be confident it's good enough.

[dckc]

Oh! Object.assign seems to be missing. I use that a lot, as in:

const withPB = Object.assign({ peanutButter: 11 }, noPeanutButter);

Any particular reason to leave it out?

[erights]

const withPB = {peanutButter: 11, ...noPeanutButter};

[dckc]

oh. right. spread. Modern JS is pretty nice :)