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?
>> 
> 

Reply via email to