Superb! It will feel good to remove my hacks.
On 11/01/2013 10:40 PM, Attila Szegedi wrote:
Hey Tal,
just a heads up that I figured out how to ensure that ConsString never
crosses the boundary from Nashorn to Java API:
<http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/98bab0cdd7bf>.
Cheers,
Attila.
On Oct 13, 2013, at 7:29 PM, Tal Liron <[email protected]
<mailto:[email protected]>> wrote:
Reasonable, but only to an extent. :)
I think JVM languages should integrate more naturally with Java
libraries, without needing specialized wrappers. This is especially
true for a language like JavaScript, which has almost no standard
library of its own, and is thus very dependent on Java libraries.
Part of the reason for choosing to develop with a dynamic language on
the JVM (JRuby, Jython, Scala, etc.) is the ability to access the
huge extant JVM ecosystem, and of course you don't expect developers
of those 3rd party libraries to specifically target one specific
dynamic language engine, especially when some of these language
engines do not yet exist.
Other JVM language engines seem to do a better job than Nashorn at
this, at least currently. I'll continue to argue my case on specific
issues, but it's clear to me now that the Nashorn team has a
different set of convictions/priorities.
The alternative for me, right now, is some weird Nashorn-specific
hacks. Here's an example I just committed to the MongoDB driver:
var status = application.globals.get(String('mongoDb.status.'
+ client.hashCode())) // workaround to avoid ConsString in Nashorn
A JavaScript programmer would be confused. And, this is unnecessary
with Rhino.
