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