(Also, note that the commit message is unfortunately wrong; it should say "Ensure ConsString isn't visible to Java" -- I originally set out to do something about not exposing ScriptObject either to Java, but the team came to the decision that it's ultimately a bad idea.)
Attila. On Nov 1, 2013, at 3:40 PM, Attila Szegedi <[email protected]> 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]> 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. >> >> On 10/14/2013 01:13 AM, Rick Bullotta wrote: >>> I do think it is a reasonable requirement when using any arbitrary library >>> that in some cases a wrapper would be required. Having a method signature >>> with "Object" is not exactly ideal for even weakly typed >>> interaction...kinda like an XML schema with "xsd:any". I think the key is >>> to avoid having to make the script developer do goofy stuff. If it >>> requires a developer to wrap some 3rd party library to provide necessary >>> typing or type munging in some edge cases, that certainly seems reasonable, >>> doesn't it? >>> >> >
