Adding some thoughts of my own… On Oct 11, 2011, at 1:00 AM, Rémi Forax wrote:
> And at the end, all predefined Javascript objects should be re-written > in Javascript, > with some native calls to Java but it will be easier for providing the > core API. > By example, for javascript Number, it should be a j.l.Double but with > it's own vtable > to add all Javascript predefined methods. > The idea is that j.l.Double and Javascript Number are the same object at > runtime but > are seen differently in Java and in Javascript. Yes. You can do this really nicely with Dynalink linkers, here's how: - in your invoke dynamic bootstrapped, define two linkers as your prioritized linkers. First one is the public one (the one whose class you export in META-INF/services). The other is a private linker that only acts on java.lang.Number, java.lang.String, and java.lang.Boolean, and provides extra JS operations on them. That way, if your runtime encounters any of these types + a JS only method invocation (or type conversion) on them, you can implement the required JS semantics in this private linker. Further to Remi's points, I was looking at your usage of the linker, and I think you might be using it wrong :-). First, all your linkages seem to be unconditional (there's never a guard). This doesn't seem right, as you can't relink if your call site gets a POJO instead of a JS object. You're also using the linker to link a static "print" method -- you shouldn't use a dynamic linker for that; you should just emit the INVOKESTATIC at the call site instead of making it an INVOKEDYNAMIC call. Alternatively, you can prefix that too with "dynjs:", see below. In general, for every usage were you'd just unconditionally link, you should just have an INVOKESTATIC/INVOKESPECIAL to a method in your runtime and not go through Dynalink. Your linker should first check whether what it was given is a DynObject (it should in fact implement TypeBasedGuardingDynamicLinker and claim it only links DynObject (or maybe DynAtom), and if so, provide the linking for the standard "dyn:*" operations on them. Mind you, you can still have your private "dynjs:*" operations defined by linker, that's fine (i.e. if you want to, replace "print" with "dynjs:print" too), just don't link them unconditionally, always link them with a guard of "instanceof DynAtom/Scope/DynObject, or what's applicable. That way, you make your system more interoperable by allowing users of your runtime to supply -- if they know how to and want to -- definitions for these operations in their own linkers for their own objects. Attila. > > cheers, > Rémi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
