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?
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tal Liron Sent: Sunday, October 13, 2013 12:42 PM To: [email protected] Subject: Re: A ConsString Gotcha Your proposal solves the generics problem nicely enough, but many 3rd party libraries out there have methods with Object argument signatures. I still think that blanket conversion is best, configurable with a flag. The performance issue might be fixable like so: if ever a ConsString needs to be converted to a String, it would happen once and only once, effectively internally replacing the ConsString with a String instance. The performance hit would be momentary. And again, can be disabled with a flag. On 10/14/2013 12:28 AM, Jim Laskey (Oracle) wrote: > The complication there is that every time you have an Object > argument/field you would have to have an if instanceof ConsString cast > String sequence, which is a huge performance hit. ConsString was > introduced to significantly improve performance (high frequency > operation), so it's a bit of a dilemma. The team has debated this > several times. It might be better in the long run to be able to > properly declare the HashMap with something like; > > var StringHashMap = Java.type("java.util.HashMap<java.lang.String, > java.lang.Object>"); > > or even better > > var JObject = Java.type("java.lang.Object"); > var JString = Java.type("java.lang.String"); > var StringHashMap = Java.type("java.util.HashMap", JString, JObject); >
