A ConsString Gotcha

[Tal Liron]

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