A ConsString Gotcha

Tal Liron tal.liron at threecrickets.com
Fri Nov 1 07:44:37 PDT 2013


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 <tal.liron at threecrickets.com 
> <mailto:tal.liron at threecrickets.com>> 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.



More information about the nashorn-dev mailing list