Re: [gwt-contrib] Fwd: jsinterop woes: Part 2: return Double[]

2017-06-26 Thread 'Roberto Lublinerman' via GWT Contributors
>
>
> @Roberto
> Please note that I am not mixing stuff (java and js objects in the same
> array, or different kind of objects in the same array).
>
> D3 is doing the correct thing here. If you pass an array of something,
> let's say T[] you can expect that you will be getting T and T[] out of D3
> functions (can't really remember the specifics). What I am passing are pure
> js objects modeled with jsinterop, and they still count as js, not java. So
> I am expecting to get back what I feed in / declared at the start.
>
>
D3 is a JS api, even if some function says it will return an array of T, it
is a JavaScript array, so there is no (type) guarantee that the array is of
T. So it is an array of things, all of them of type T.

A java T[] has even stronger semantics, if you set an element it will check
that it is the correct type. So the D3 array is like an Object[] that
happens to be filled all with Ts.


> So what do I want: Double[] to be castable to double[] in the GWT js
> context (not in the java context). I don't know if this is possible but it
> is definitely desirable. (The same for String[] and Boolean[]) and a pony
> of course :-)
>
>
Again here Double[] and double[] have very different semantics in Java.

- you can cast Double[] to Object[] but not double[] to Object[]
- you can store nulls in Double[] but not in double[].

They are semantically different. I agree that in some circumstances it
seems convenient to ignore those. But in general GWT follows Java semantics
(with a few exceptions)


> Thanks again.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/CAKbOjExku8sLUm3Ky7B6OF-gx%
> 3DvgvdP_v8nd-Pi0WNeqzyv06g%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7gkupiRhKbO9CAmnKO9LUSh26veVjnQ0LqAGemeJvFWm9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [gwt-contrib] Fwd: jsinterop woes: Part 2: return Double[]

2017-06-26 Thread Vassilis Virvilis
Hi and thanks for answering.

I also tend to believe this is not a bug - but - it is definitely in my
wish list.

@Colin jsinterop is certainly kind of fragile but if you bang your head
against it at the end you start understanding the errors. In most cases you
can fix the error by making the java code or the jsinterop declaration
__better__. This is a case that I had to uglify my bindings. So I don't
believe that is fails in new, unique and interesting ways. It is rather
consistent. It may be somewhat fragile and cryptic but it is consistent and
I don't believe that you will have a problem with element[] (assuming
element is a jsinterop native, and com.google.dom.dontremember.element),
double[] or boolean[]. But you will be in world of hurt if you try to
communicate Double[], Boolean[], String[].

@Roberto
Please note that I am not mixing stuff (java and js objects in the same
array, or different kind of objects in the same array).

D3 is doing the correct thing here. If you pass an array of something,
let's say T[] you can expect that you will be getting T and T[] out of D3
functions (can't really remember the specifics). What I am passing are pure
js objects modeled with jsinterop, and they still count as js, not java. So
I am expecting to get back what I feed in / declared at the start.

That part works.

I am putting Date[] --> I am getting back Date[] . Correct
I am putting double[] --> I am getting back double[] . Correct
I am putting Double[] --> I am getting back exception. Not so nice.

That basically means that I can't have a generic function that will work
with all kind of GenericTypes because double is not an object in java. That
means I have to special case the interface like this

  V get(T t); --> works great for JsObects as it should
  double getDouble(T t) --> ugly huh?

So what do I want: Double[] to be castable to double[] in the GWT js
context (not in the java context). I don't know if this is possible but it
is definitely desirable. (The same for String[] and Boolean[]) and a pony
of course :-)

Thanks again.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKbOjExku8sLUm3Ky7B6OF-gx%3DvgvdP_v8nd-Pi0WNeqzyv06g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [gwt-contrib] Fwd: jsinterop woes: Part 2: return Double[]

2017-06-26 Thread Ignacio Baca Moreno-Torres
Oh, the classic array problem! ;)
https://github.com/gwtproject/gwt/issues/9318

IMO as you are wrapping a client lib, and this code is not going to be
shared (used in JRE), so just use elemental2.core.Array. Probably
JsArrayLike is enough as an argument but returning an Array it is easier to
use.

I use native arrays extensively in DTO, but I stick to some limitations and
it works pretty well. I only use primitive, Boolean, Double or
JsType(native) arrays. And as I use it in DTOs if I want to do anything I
always make defensive copies. In practice, this makes much sense because
you almost everytime need to do some filter/mapping/peek with those arrays,
so I just use Stream.of(array) do whatever I want (filter/map/...) and
either use forEach/collect/toArray. So the resulting collection has type
markers so it gets back to safety.

In general using native arrays with JS libs it's not a good idea for does
problems. So try to avoid. You can always overload this method so you can
pass a native array but returns a JsType Array. And anyways, returning a
native array is not very friendly as you are probably expecting something
mutable (add/remove) so the java native array is really not a good
container here. In some weird cases, I have been using the manolo's hack ;)
(
https://github.com/manolo/gwt-api-generator/blob/master/lib/com/vaadin/polymer/Polymer.java#L522)
to make it mutable as a Java List, but it is pretty hacky.

On Mon, Jun 26, 2017 at 7:32 PM 'Roberto Lublinerman' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> On Mon, Jun 26, 2017 at 10:16 AM, Colin Alworth 
> wrote:
>
>> The example isn't doing instanceof though, it is just making that the
>> return type for the method (albeit through the use of generics). Does this
>> suggest that we should stop using arrays to refer to raw JS data, or at
>> least expect that generics may fail in interesting ways around them (and at
>> runtime of all places)?
>>
>
> It is the programmers responsibility to make sure JS methods that are
> called satisfy the Java contract they declare, same thing as in JSNI. If
> you use non native arrays in JsInterop members you should be getting
> "unusable-by-js" warnings.
>
> Also I forgot to mention that you can definitely return JS arrays as
> Object[] too.
>
> Of course you can do tricks (as people used to in JSNI) if you know the
> edges in the semantics. E.g. returning a Date[] if you are sure there will
> be no casts. You also have to be aware that when you use generics there
> will be casts at the invocation sites.
>
> If you have raw JS array you should model it with either a NativeJsType[]
> or an Object[].
>
>
>> elemental2.Array is full of cases where [] or ... are used as arguments,
>> though this includes generic arrays (as opposed to generics _of_ arrays).
>> If I understand you correctly, valid Java code that is passed a String[] or
>> Double[] (or for example Element[]) may fail in exciting ways if passed one
>> of these 'arrays'.
>>
>
> varargs is a different animal, JS varargs are always cast appropriately
> (there is always prelude on Java methods that implement a native method
> with JS varargs that takes care of this).
>
> Yes valid Java code might fail for instance if there is a (instanceof
> String[] call, etc).
>
>
>>
>> In case those are correctly handled, and it is important only to tell
>> JsInterop about an array of generics  instead of generic representing an
>> array, perhaps Vassilis should have another AccessorFunction which handles
>> arrays instead? (Actually maye need 3 more, , , ,
>> so I don't think this is a serious suggestion).
>> Otherwise your email seems to suggest that we need a type in
>> jsinterop.base for all JS arrays instead of our current situation of
>> pretending that java arrays and js arrays are compatible.
>>
>
> You can always use Object[], and nothing will fail.
>
>
>>
>> --
>>   Colin Alworth
>>   co...@colinalworth.com
>>
>>
>>
>> On Mon, Jun 26, 2017, at 12:09 PM, 'Roberto Lublinerman' via GWT
>> Contributors wrote:
>>
>> The short answer is that this is also not a bug.
>>
>> Java arrays are typed, JS arrays are not. So none of the examples you
>> have will fully work.
>>
>> E.g. If you do array instanceof Date[] on an array built in JS filled
>> with Dates it will fail.
>>
>> A native array is best modeled as SomeNativeJsType[] where there are not
>> expectations on the contents of the array from the Java perspective.
>>
>> We would have loved to have a more seamless array JsInterop.
>>
>>
>>
>> On Mon, Jun 26, 2017 at 1:31 AM, Vassilis Virvilis 
>> wrote:
>>
>> Originally posted in gwt-users.
>> The question here is the same with the previous one.
>>
>> Is this considered a bug? Should I report it as an issue? and if so where?
>>
>>  Thanks.
>>
>>
>> -- Forwarded message --
>> From: *Vassilis Virvilis* 
>> Date: Fri, Feb 24, 2017 at 

Re: [gwt-contrib] Fwd: jsinterop woes: Part 2: return Double[]

2017-06-26 Thread 'Roberto Lublinerman' via GWT Contributors
On Mon, Jun 26, 2017 at 10:16 AM, Colin Alworth 
wrote:

> The example isn't doing instanceof though, it is just making that the
> return type for the method (albeit through the use of generics). Does this
> suggest that we should stop using arrays to refer to raw JS data, or at
> least expect that generics may fail in interesting ways around them (and at
> runtime of all places)?
>

It is the programmers responsibility to make sure JS methods that are
called satisfy the Java contract they declare, same thing as in JSNI. If
you use non native arrays in JsInterop members you should be getting
"unusable-by-js" warnings.

Also I forgot to mention that you can definitely return JS arrays as
Object[] too.

Of course you can do tricks (as people used to in JSNI) if you know the
edges in the semantics. E.g. returning a Date[] if you are sure there will
be no casts. You also have to be aware that when you use generics there
will be casts at the invocation sites.

If you have raw JS array you should model it with either a NativeJsType[]
or an Object[].


> elemental2.Array is full of cases where [] or ... are used as arguments,
> though this includes generic arrays (as opposed to generics _of_ arrays).
> If I understand you correctly, valid Java code that is passed a String[] or
> Double[] (or for example Element[]) may fail in exciting ways if passed one
> of these 'arrays'.
>

varargs is a different animal, JS varargs are always cast appropriately
(there is always prelude on Java methods that implement a native method
with JS varargs that takes care of this).

Yes valid Java code might fail for instance if there is a (instanceof
String[] call, etc).


>
> In case those are correctly handled, and it is important only to tell
> JsInterop about an array of generics  instead of generic representing an
> array, perhaps Vassilis should have another AccessorFunction which handles
> arrays instead? (Actually maye need 3 more, , , ,
> so I don't think this is a serious suggestion).
> Otherwise your email seems to suggest that we need a type in
> jsinterop.base for all JS arrays instead of our current situation of
> pretending that java arrays and js arrays are compatible.
>

You can always use Object[], and nothing will fail.


>
> --
>   Colin Alworth
>   co...@colinalworth.com
>
>
>
> On Mon, Jun 26, 2017, at 12:09 PM, 'Roberto Lublinerman' via GWT
> Contributors wrote:
>
> The short answer is that this is also not a bug.
>
> Java arrays are typed, JS arrays are not. So none of the examples you have
> will fully work.
>
> E.g. If you do array instanceof Date[] on an array built in JS filled with
> Dates it will fail.
>
> A native array is best modeled as SomeNativeJsType[] where there are not
> expectations on the contents of the array from the Java perspective.
>
> We would have loved to have a more seamless array JsInterop.
>
>
>
> On Mon, Jun 26, 2017 at 1:31 AM, Vassilis Virvilis 
> wrote:
>
> Originally posted in gwt-users.
> The question here is the same with the previous one.
>
> Is this considered a bug? Should I report it as an issue? and if so where?
>
>  Thanks.
>
>
> -- Forwarded message --
> From: *Vassilis Virvilis* 
> Date: Fri, Feb 24, 2017 at 2:44 PM
> Subject: jsinterop woes: Part 2: return Double[]
> To: google-web-tool...@googlegroups.com
>
>
> Hi,
>
> I am not sure if it is a bug but it kills my beautiful jsinterop mappings.
> Let's say that I have a native js function (d3.extent) that returns an
> array of something. It may be dates it may be doubles..
>
> This is mapped nicely with
>
> public static native  V[] extent(T[] data,
> AccessorFunction accessor);
>
>
> Where AccessorFunction is
>
> @JsFunction
> public static interface AccessorFunction {
> public V get(T d);
> }
>
>
> The above scheme works for Date and other objects but it fails with
> Double. If I specify another variant of d3.extent that returns double[] it
> works
> Here is the javascript exception
>
> Uncaught Error: java.lang.ClassCastException
> at java_lang_ClassCastException_ClassCastException__V.java_lang
> _Throwable_createError__Ljava_lang_String_2Ljava_lang_Object_2 [as
> package_private$java_lang$createError__Ljava_lang_String_2Ljava_lang_Object_2]
> (dashboard-0.js:7245)
> at java_lang_ClassCastException_ClassCastException__V.java_lang
> _Throwable_initializeBackingError__V [as 
> private$java_lang_Throwable$initializeBackingError__V]
> (dashboard-0.js:7300)
> at 
> java_lang_ClassCastException_ClassCastException__V.java_lang_Throwable_Throwable__V
> (dashboard-0.js:7133)
> at 
> java_lang_ClassCastException_ClassCastException__V.java_lang_Exception_Exception__V
> (dashboard-0.js:7381)
> at java_lang_ClassCastException_ClassCastException__V.java_lang
> _RuntimeException_RuntimeException__V (dashboard-0.js:29760)
> at 

Re: [gwt-contrib] Fwd: jsinterop woes: Part 2: return Double[]

2017-06-26 Thread Colin Alworth
The example isn't doing instanceof though, it is just making that the
return type for the method (albeit through the use of generics). Does
this suggest that we should stop using arrays to refer to raw JS data,
or at least expect that generics may fail in interesting ways around
them (and at runtime of all places)?
elemental2.Array is full of cases where [] or ... are used as arguments,
though this includes generic arrays (as opposed to generics _of_
arrays). If I understand you correctly, valid Java code that is passed a
String[] or Double[] (or for example Element[]) may fail in exciting
ways if passed one of these 'arrays'.
In case those are correctly handled, and it is important only to tell
JsInterop about an array of generics  instead of generic representing an
array, perhaps Vassilis should have another AccessorFunction which
handles arrays instead? (Actually maye need 3 more, , ,
, so I don't think this is a serious suggestion).
Otherwise your email seems to suggest that we need a type in
jsinterop.base  for all JS arrays instead of our current situation of
pretending that java arrays and js arrays are compatible.
--
  Colin Alworth
  co...@colinalworth.com



On Mon, Jun 26, 2017, at 12:09 PM, 'Roberto Lublinerman' via GWT Contributors 
wrote:> The short answer is that this is also not a bug.
> 
> Java arrays are typed, JS arrays are not. So none of the examples you
> have will fully work.> 
> E.g. If you do array instanceof Date[] on an array built in JS filled
>  with Dates it will fail.> 
> A native array is best modeled as SomeNativeJsType[] where there are
> not expectations on the contents of the array from the Java
> perspective.> 
> We would have loved to have a more seamless array JsInterop.
> 
> 
> 
> On Mon, Jun 26, 2017 at 1:31 AM, Vassilis Virvilis
>  wrote:>> Originally posted in gwt-users.
>> The question here is the same with the previous one.
>> 
>> Is this considered a bug? Should I report it as an issue? and if
>> so where?>> 
>>  Thanks.
>> 
>> 
>> -- Forwarded message --
>> From: *Vassilis Virvilis* 
>> Date: Fri, Feb 24, 2017 at 2:44 PM
>> Subject: jsinterop woes: Part 2: return Double[]
>> To: google-web-tool...@googlegroups.com
>> 
>> 
>> Hi,
>> 
>> I am not sure if it is a bug but it kills my beautiful jsinterop
>> mappings.>> Let's say that I have a native js function (d3.extent) that 
>> returns
>> an array of something. It may be dates it may be doubles..>> 
>> This is mapped nicely with 
>> 
>>> public static native  V[] extent(T[] data,
>>> AccessorFunction accessor);
>> 
>> Where AccessorFunction is 
>> 
>>> @JsFunction
>>> public static interface AccessorFunction {
>>> public V get(T d);
>>> }
>> 
>> The above scheme works for Date and other objects but it fails with
>> Double. If I specify another variant of d3.extent that returns
>> double[] it works>> Here is the javascript exception
>> 
>>> Uncaught Error: java.lang.ClassCastException
>>> at java_lang_ClassCastException_ClassCastException__V.java_lang-
>>> _Throwable_createError__Ljava_lang_String_2Ljava_lang_Object_2
>>> [as package_private$java_lang$createError__Ljava_lang_String_2L-
>>> java_lang_Object_2] (dashboard-0.js:7245)>>> at 
>>> java_lang_ClassCastException_ClassCastException__V.java_lang-
>>> _Throwable_initializeBackingError__V [as
>>> private$java_lang_Throwable$initializeBackingError__V] (dashboard-
>>> 0.js:7300)>>> at 
>>> java_lang_ClassCastException_ClassCastException__V.java_lang-
>>> _Throwable_Throwable__V (dashboard-0.js:7133)>>> at 
>>> java_lang_ClassCastException_ClassCastException__V.java_lang-
>>> _Exception_Exception__V (dashboard-0.js:7381)>>> at 
>>> java_lang_ClassCastException_ClassCastException__V.java_lang-
>>> _RuntimeException_RuntimeException__V (dashboard-0.js:29760)>>> at 
>>> java_lang_ClassCastException_ClassCastException__V (dashboard-
>>> 0.js:57310)>>> at 
>>> javaemul_internal_InternalPreconditions_checkCriticalType__ZV
>>> (dashboard-0.js:72171)>>> at 
>>> javaemul_internal_InternalPreconditions_checkType__ZV (dashboard-
>>> 0.js:72378)>>> at 
>>> com_google_gwt_lang_Cast_castTo__Ljava_lang_Object_2Lcom_goo-
>>> gle_gwt_core_client_JavaScriptObject_2Ljava_lang_Object_2 (dashboard-
>>> 0.js:647)>> 
>> It goes here
>>> function com_google_gwt_lang_Cast_castTo__Ljava_lang_Object_2Lcom_g-
>>> oogle_gwt_core_client_JavaScriptObject_2Ljava_lang_Object_2(src_0,
>>> dstId){>>>   com_google_gwt_lang_Cast_$clinit__V();
>>>   javaemul_internal_InternalPreconditions_checkType__ZV(com_google_-
>>>   gwt_lang_Cast_jsEquals__Ljava_lang_Object_2Ljava_lang_Object_2Z(s-
>>>   rc_0, null) || com_google_gwt_lang_Cast_canCast__Ljava_lang_Objec-
>>>   t_2Lcom_google_gwt_core_client_JavaScriptObject_2Z(src_0, dstId));>>>   
>>> return src_0;
>>> }
>> 
>> 

Re: [gwt-contrib] Fwd: jsinterop woes: Part 2: return Double[]

2017-06-26 Thread 'Roberto Lublinerman' via GWT Contributors
The short answer is that this is also not a bug.

Java arrays are typed, JS arrays are not. So none of the examples you have
will fully work.

E.g. If you do array instanceof Date[] on an array built in JS filled with
Dates it will fail.

A native array is best modeled as SomeNativeJsType[] where there are not
expectations on the contents of the array from the Java perspective.

We would have loved to have a more seamless array JsInterop.



On Mon, Jun 26, 2017 at 1:31 AM, Vassilis Virvilis 
wrote:

> Originally posted in gwt-users.
>
> The question here is the same with the previous one.
>
> Is this considered a bug? Should I report it as an issue? and if so where?
>
>  Thanks.
>
>
> -- Forwarded message --
> From: Vassilis Virvilis 
> Date: Fri, Feb 24, 2017 at 2:44 PM
> Subject: jsinterop woes: Part 2: return Double[]
> To: google-web-tool...@googlegroups.com
>
>
> Hi,
>
> I am not sure if it is a bug but it kills my beautiful jsinterop mappings.
>
> Let's say that I have a native js function (d3.extent) that returns an
> array of something. It may be dates it may be doubles..
>
> This is mapped nicely with
>
> public static native  V[] extent(T[] data,
>> AccessorFunction accessor);
>>
>
> Where AccessorFunction is
>
> @JsFunction
>> public static interface AccessorFunction {
>> public V get(T d);
>> }
>>
>
> The above scheme works for Date and other objects but it fails with
> Double. If I specify another variant of d3.extent that returns double[] it
> works
>
> Here is the javascript exception
>
> Uncaught Error: java.lang.ClassCastException
>> at java_lang_ClassCastException_ClassCastException__V.java_lang
>> _Throwable_createError__Ljava_lang_String_2Ljava_lang_Object_2 [as
>> package_private$java_lang$createError__Ljava_lang_String_2Ljava_lang_Object_2]
>> (dashboard-0.js:7245)
>> at java_lang_ClassCastException_ClassCastException__V.java_lang
>> _Throwable_initializeBackingError__V [as 
>> private$java_lang_Throwable$initializeBackingError__V]
>> (dashboard-0.js:7300)
>> at 
>> java_lang_ClassCastException_ClassCastException__V.java_lang_Throwable_Throwable__V
>> (dashboard-0.js:7133)
>> at 
>> java_lang_ClassCastException_ClassCastException__V.java_lang_Exception_Exception__V
>> (dashboard-0.js:7381)
>> at java_lang_ClassCastException_ClassCastException__V.java_lang
>> _RuntimeException_RuntimeException__V (dashboard-0.js:29760)
>> at java_lang_ClassCastException_ClassCastException__V
>> (dashboard-0.js:57310)
>> at javaemul_internal_InternalPreconditions_checkCriticalType__ZV
>> (dashboard-0.js:72171)
>> at javaemul_internal_InternalPreconditions_checkType__ZV
>> (dashboard-0.js:72378)
>> at com_google_gwt_lang_Cast_castTo__Ljava_lang_Object_2Lcom_
>> google_gwt_core_client_JavaScriptObject_2Ljava_lang_Object_2
>> (dashboard-0.js:647)
>>
>
> It goes here
>
>> function com_google_gwt_lang_Cast_castTo__Ljava_lang_Object_2Lcom_
>> google_gwt_core_client_JavaScriptObject_2Ljava_lang_Object_2(src_0,
>> dstId){
>>   com_google_gwt_lang_Cast_$clinit__V();
>>   javaemul_internal_InternalPreconditions_checkType__ZV(com_
>> google_gwt_lang_Cast_jsEquals__Ljava_lang_Object_2Ljava_lang_Object_2Z(src_0,
>> null) || com_google_gwt_lang_Cast_canCast__Ljava_lang_Object_2Lcom_
>> google_gwt_core_client_JavaScriptObject_2Z(src_0, dstId));
>>   return src_0;
>> }
>>
>
> Arguments:
>
>- src_0:
>   - evaluated: js array of numbers as it should be
>   - dstId:
>   - evaluated: 2396
>
> and then it goes to
>
> function com_google_gwt_lang_Cast_canCast__Ljava_lang_Object_2Lcom_
>> google_gwt_core_client_JavaScriptObject_2Z(src_0, dstId){
>>   com_google_gwt_lang_Cast_$clinit__V();
>>   if (com_google_gwt_lang_Cast_instanceOfString__Ljava_lang_Object_2Z(src_0))
>> {
>> return !!com_google_gwt_lang_Cast_stringCastMap[dstId];
>>   }
>>else if (src_0.java_lang_Object_castableTypeMap) {
>> return !!src_0.java_lang_Object_castableTypeMap[dstId];
>>   }
>>else if 
>> (com_google_gwt_lang_Cast_instanceOfDouble__Ljava_lang_Object_2Z(src_0))
>> {
>> return !!com_google_gwt_lang_Cast_doubleCastMap[dstId];
>>   }
>>else if 
>> (com_google_gwt_lang_Cast_instanceOfBoolean__Ljava_lang_Object_2Z(src_0))
>> {
>> return !!com_google_gwt_lang_Cast_booleanCastMap[dstId];
>>   }
>>   return false;
>> }
>>
>
> where it fails.
>
> Would it be possible to handle transparently also Double[] (and possibly
> String[])? as double[]?
>
>Thank you for reading that far...
>
> Vassilis
>
>
>
>
>
>
>
> --
> Vassilis Virvilis
>
>
>
> --
> Vassilis Virvilis
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 

[gwt-contrib] Fwd: jsinterop woes: Part 2: return Double[]

2017-06-26 Thread Vassilis Virvilis
Originally posted in gwt-users.

The question here is the same with the previous one.

Is this considered a bug? Should I report it as an issue? and if so where?

 Thanks.


-- Forwarded message --
From: Vassilis Virvilis 
Date: Fri, Feb 24, 2017 at 2:44 PM
Subject: jsinterop woes: Part 2: return Double[]
To: google-web-tool...@googlegroups.com


Hi,

I am not sure if it is a bug but it kills my beautiful jsinterop mappings.

Let's say that I have a native js function (d3.extent) that returns an
array of something. It may be dates it may be doubles..

This is mapped nicely with

public static native  V[] extent(T[] data,
> AccessorFunction accessor);
>

Where AccessorFunction is

@JsFunction
> public static interface AccessorFunction {
> public V get(T d);
> }
>

The above scheme works for Date and other objects but it fails with Double.
If I specify another variant of d3.extent that returns double[] it works

Here is the javascript exception

Uncaught Error: java.lang.ClassCastException
> at java_lang_ClassCastException_ClassCastException__V.java_
> lang_Throwable_createError__Ljava_lang_String_2Ljava_lang_Object_2 [as
> package_private$java_lang$createError__Ljava_lang_String_2Ljava_lang_Object_2]
> (dashboard-0.js:7245)
> at java_lang_ClassCastException_ClassCastException__V.java_
> lang_Throwable_initializeBackingError__V [as 
> private$java_lang_Throwable$initializeBackingError__V]
> (dashboard-0.js:7300)
> at 
> java_lang_ClassCastException_ClassCastException__V.java_lang_Throwable_Throwable__V
> (dashboard-0.js:7133)
> at 
> java_lang_ClassCastException_ClassCastException__V.java_lang_Exception_Exception__V
> (dashboard-0.js:7381)
> at java_lang_ClassCastException_ClassCastException__V.java_
> lang_RuntimeException_RuntimeException__V (dashboard-0.js:29760)
> at java_lang_ClassCastException_ClassCastException__V
> (dashboard-0.js:57310)
> at javaemul_internal_InternalPreconditions_checkCriticalType__ZV
> (dashboard-0.js:72171)
> at javaemul_internal_InternalPreconditions_checkType__ZV
> (dashboard-0.js:72378)
> at com_google_gwt_lang_Cast_castTo__Ljava_lang_Object_
> 2Lcom_google_gwt_core_client_JavaScriptObject_2Ljava_lang_Object_2
> (dashboard-0.js:647)
>

It goes here

> function com_google_gwt_lang_Cast_castTo__Ljava_lang_Object_
> 2Lcom_google_gwt_core_client_JavaScriptObject_2Ljava_lang_Object_2(src_0,
> dstId){
>   com_google_gwt_lang_Cast_$clinit__V();
>   javaemul_internal_InternalPreconditions_checkType__ZV(com_google_gwt_
> lang_Cast_jsEquals__Ljava_lang_Object_2Ljava_lang_Object_2Z(src_0, null)
> || com_google_gwt_lang_Cast_canCast__Ljava_lang_Object_
> 2Lcom_google_gwt_core_client_JavaScriptObject_2Z(src_0, dstId));
>   return src_0;
> }
>

Arguments:

   - src_0:
  - evaluated: js array of numbers as it should be
  - dstId:
  - evaluated: 2396

and then it goes to

function com_google_gwt_lang_Cast_canCast__Ljava_lang_Object_
> 2Lcom_google_gwt_core_client_JavaScriptObject_2Z(src_0, dstId){
>   com_google_gwt_lang_Cast_$clinit__V();
>   if (com_google_gwt_lang_Cast_instanceOfString__Ljava_lang_Object_2Z(src_0))
> {
> return !!com_google_gwt_lang_Cast_stringCastMap[dstId];
>   }
>else if (src_0.java_lang_Object_castableTypeMap) {
> return !!src_0.java_lang_Object_castableTypeMap[dstId];
>   }
>else if 
> (com_google_gwt_lang_Cast_instanceOfDouble__Ljava_lang_Object_2Z(src_0))
> {
> return !!com_google_gwt_lang_Cast_doubleCastMap[dstId];
>   }
>else if 
> (com_google_gwt_lang_Cast_instanceOfBoolean__Ljava_lang_Object_2Z(src_0))
> {
> return !!com_google_gwt_lang_Cast_booleanCastMap[dstId];
>   }
>   return false;
> }
>

where it fails.

Would it be possible to handle transparently also Double[] (and possibly
String[])? as double[]?

   Thank you for reading that far...

Vassilis







-- 
Vassilis Virvilis



-- 
Vassilis Virvilis

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKbOjEzUf3LAK90Gnq%2B8B5Yzq7akyZPC%3DJ9ch1DFieqoOCJJVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.