You're right about that, Rémi. However, even in Java you can twist things with
unchecked casts so that you pass a List<Object> to this method and force it
into a ClassCastException, so I'm not sure if us going out of our way to inject
a suitable conversion would be desired.
On Nov 27, 2014, at 12:59 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
>
> On 11/27/2014 12:37 AM, Tim Fox wrote:
>> Hi Attila,
>>
>> I understand the generic type info is erased, but my question was whether
>> there is any way I can "force" Nashorn to convert the elements as Long
>> rather than Integer when doing the conversion, e.g. using some special
>> Nashorn specific syntax, e.g.
>>
>> var arr = [123];
>> arr.forceConversionAsLong = true; // A contrived example but you get the
>> point :)
>> obj.foo(arr);
>>
>> (or whatever)
>
> BTW, generic info like this one are preserved because javac need them to
> cross compile.
> so nashorn could inspect the generic signature and if there is one try to do
> the suitable conversion.
>
> Rémi
>
>>
>>
>> On 26/11/14 21:50, Attila Szegedi wrote:
>>> I don't think so. As the types are erased at run time all we see is a
>>> method with signature foo(List list). I think if you tried to add two
>>> methods to a class:
>>>
>>> public void foo(List<Long> x) { }
>>> public void foo(List<Integer> x) { }
>>>
>>> then javac would refuse to compile it saying that both have the same
>>> erasure.
>>>
>>> Attila.
>>>
>>> On Nov 26, 2014, at 10:45 PM, Tim Fox <timvo...@gmail.com> wrote:
>>>
>>>> Hello folks,
>>>>
>>>> I have a Java method:
>>>>
>>>> public void foo(List<Long> list) {
>>>> System.out.println("elem0 is " + list.get(0));
>>>> }
>>>>
>>>> Which I call from JS with a JS array:
>>>>
>>>> obj.foo([123]);
>>>>
>>>> This results in a ClassCastException as Nashorn converts the JS Array into
>>>> a java.util.List instance which contains a java.lang.Integer element (not
>>>> java.lang.Long)
>>>>
>>>> Is there any way to force Nashorn to convert the array elements as Longs
>>>> not Integers?
>>>>
>>>> Thanks.
>>
>
