Re: Closure compiler removal ?

2016-06-10 Thread Juan Pablo Gardella
Another question related to that. How can be integrated closure
optimization in the build after that?

On Fri, 10 Jun 2016 at 16:32 Hristo Stoyanov  wrote:

> According to this:
> https://gwt-review.googlesource.com/#/c/15110/
>
> The -XenableClosudeCompiler option will be removed from GWT 2.8. This
> impacts Cradle And Maven plugins. I also have 2 question:
> 1. Is specifying -optimte 9 good enough to be the only one left?
> 2. The reason for the removal states that it never worked with source
> maps, but source maps are only useful during development, when noone uses
> optimization?
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Closure compiler removal ?

2016-06-10 Thread Hristo Stoyanov
According to this:
https://gwt-review.googlesource.com/#/c/15110/

The -XenableClosudeCompiler option will be removed from GWT 2.8. This impacts 
Cradle And Maven plugins. I also have 2 question:
1. Is specifying -optimte 9 good enough to be the only one left?
2. The reason for the removal states that it never worked with source maps, but 
source maps are only useful during development, when noone uses optimization?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Any way to apply a prefix to CssResources globally?

2016-06-10 Thread David Becker
You can apply prefixes to a CssResource when @Import-ing with the 
@ImportedWithPrefix("foobar") annotation; or when using the "obfuscated" 
style you can set CssResource.obfuscationPrefix="foobar-".  But, I would 
also like to apply the foobar- prefix (even when not importing) and when 
using the "stable-shorttype" or "stable-notype" styles.  I tried parsing 
through the and stepping through the code, but I don't see any way to do it.

Any suggestions?  Thanks!

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: Issues with GWT 2.8 snapshot

2016-06-10 Thread Thomas Broyer
Also, it addresses Filipe's issue, but Hristo's one is different (and if you 
ask me, not actually a problem with GWT; not until proven otherwise): why does 
a javadoc task look at source files in gwt-user?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: Issues with GWT 2.8 snapshot

2016-06-10 Thread David Becker
The code review link Roberto mentioned says it's still under review and
hasn't been merged yet.

-.. .- ...- .. -.....-... . -.-. -.- . .-.

On Fri, Jun 10, 2016 at 8:50 AM, Hristo Stoyanov 
wrote:

> Thanks Roberto,
> Just a to confirm that the issue is still with us - i did a new build a
> few seconds ago.
>
>
> On Thursday, June 9, 2016 at 10:55:26 PM UTC-7, Roberto Lublinerman wrote:
>>
>> The error messages were introduced by mistake in the JSNI error reporting
>> fix (https://gwt-review.googlesource.com/#/c/15080) and the fix for
>> those is up for review https://gwt-review.googlesource.com/#/c/15120/
>>
>> On Thursday, June 9, 2016 at 8:55:36 AM UTC-7, Hristo Stoyanov wrote:
>>>
>>> Thomas, yes, it is a javadoc failure, and it is still there. I just
>>> re-tried.
>>>
>>> On Thursday, June 9, 2016 at 5:40:24 AM UTC-7, Thomas Broyer wrote:

 I see Hristo's error is in a "javadoc" task, could it be the same (or
 similar) for you?

 On Thursday, June 9, 2016 at 1:18:02 PM UTC+2, Filipe Sousa wrote:
>
> Done that and still have the same errors. Despite the errors the
> project works as if had no errors
>
> $ java -version
> java version "1.8.0_92"
> Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)
>
> $ ant -version
> Apache Ant(TM) version 1.9.7 compiled on April 9 2016
>
> On Thursday, June 9, 2016 at 11:50:47 AM UTC+1, Thomas Broyer wrote:
>>
>> +rluble, +goktug
>>
>> Roberto, Goktug, any idea?
>> This comes from one of these changes:
>> http://build.gwtproject.org/job/gwt/520/changes
>> http://build.gwtproject.org/job/gwt/521/changes
>>
>> All: anyone tried to build it locally to make sure it's not due to a
>> corrupted JAR during upload to Sonatype OSSRH?
>>
>> On Thursday, June 9, 2016 at 11:40:53 AM UTC+2, Henrik wrote:
>>>
>>> Seeing the same problems (maven build).  Worked fine 10 hrs ago
>>> though, so the latest snapshot seems hosed.
>>>
>>> Regards,
>>> Henrik
>>>
>>> On Thursday, June 9, 2016 at 8:14:47 AM UTC+2, Hristo Stoyanov wrote:

 I started getting the following errors with Gradle builds and the
 latest GWT 2.8.-SNAPSHOT - any idea ?


 ===


 /root/.gradle/caches/modules-2/files-2.1/com.google.gwt/gwt-user/2.8.0-SNAPSHOT/c7913836bdcf2423552e6355ad17fbd271ac5207/gwt-user-2.8.0-SNAPSHOT.jar(com/google/gwt/user/client/ui/Widget.java):28:
 error: cannot access Event
 import com.google.gwt.user.client.Event;
  ^
   bad source file:
 /root/.gradle/caches/modules-2/files-2.1/com.google.gwt/gwt-user/2.8.0-SNAPSHOT/c7913836bdcf2423552e6355ad17fbd271ac5207/gwt-user-2.8.0-SNAPSHOT.jar(com/google/gwt/user/client/Event.java)
 file does not contain class com.google.gwt.user.client.Event
 Please remove or make sure it appears in the correct
 subdirectory of the sourcepath.
 /root/.gradle/caches/modules-2/files-2.1/com.google.gwt/gwt-user/2.8.0-SNAPSHOT/c7913836bdcf2423552e6355ad17fbd271ac5207/gwt-user-2.8.0-SNAPSHOT.jar(com/google/gwt/event/shared/HandlerRegistration.java):23:
 error: cannot access HandlerRegistration
 public interface HandlerRegistration extends
 com.google.web.bindery.event.shared.HandlerRegistration {

 ^
   bad source file:
 /root/.gradle/caches/modules-2/files-2.1/com.google.gwt/gwt-user/2.8.0-SNAPSHOT/c7913836bdcf2423552e6355ad17fbd271ac5207/gwt-user-2.8.0-SNAPSHOT.jar(com/google/web/bindery/event/shared/HandlerRegistration.java)
 file does not contain class
 com.google.web.bindery.event.shared.HandlerRegistration
 Please remove or make sure it appears in the correct
 subdirectory of the sourcepath.
 2 errors
 :gwt-errai:javadoc FAILED

>>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at 

Re: Issues with GWT 2.8 snapshot

2016-06-10 Thread Hristo Stoyanov
Thanks Roberto,
Just a to confirm that the issue is still with us - i did a new build a few 
seconds ago.

On Thursday, June 9, 2016 at 10:55:26 PM UTC-7, Roberto Lublinerman wrote:
>
> The error messages were introduced by mistake in the JSNI error reporting 
> fix (https://gwt-review.googlesource.com/#/c/15080) and the fix for those 
> is up for review https://gwt-review.googlesource.com/#/c/15120/
>
> On Thursday, June 9, 2016 at 8:55:36 AM UTC-7, Hristo Stoyanov wrote:
>>
>> Thomas, yes, it is a javadoc failure, and it is still there. I just 
>> re-tried.
>>
>> On Thursday, June 9, 2016 at 5:40:24 AM UTC-7, Thomas Broyer wrote:
>>>
>>> I see Hristo's error is in a "javadoc" task, could it be the same (or 
>>> similar) for you?
>>>
>>> On Thursday, June 9, 2016 at 1:18:02 PM UTC+2, Filipe Sousa wrote:

 Done that and still have the same errors. Despite the errors the 
 project works as if had no errors

 $ java -version
 java version "1.8.0_92"
 Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
 Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

 $ ant -version
 Apache Ant(TM) version 1.9.7 compiled on April 9 2016

 On Thursday, June 9, 2016 at 11:50:47 AM UTC+1, Thomas Broyer wrote:
>
> +rluble, +goktug
>
> Roberto, Goktug, any idea?
> This comes from one of these changes:
> http://build.gwtproject.org/job/gwt/520/changes
> http://build.gwtproject.org/job/gwt/521/changes
>
> All: anyone tried to build it locally to make sure it's not due to a 
> corrupted JAR during upload to Sonatype OSSRH?
>
> On Thursday, June 9, 2016 at 11:40:53 AM UTC+2, Henrik wrote:
>>
>> Seeing the same problems (maven build).  Worked fine 10 hrs ago 
>> though, so the latest snapshot seems hosed. 
>>
>> Regards,
>> Henrik
>>
>> On Thursday, June 9, 2016 at 8:14:47 AM UTC+2, Hristo Stoyanov wrote:
>>>
>>> I started getting the following errors with Gradle builds and the 
>>> latest GWT 2.8.-SNAPSHOT - any idea ?
>>>
>>>
>>> ===
>>>
>>>
>>> /root/.gradle/caches/modules-2/files-2.1/com.google.gwt/gwt-user/2.8.0-SNAPSHOT/c7913836bdcf2423552e6355ad17fbd271ac5207/gwt-user-2.8.0-SNAPSHOT.jar(com/google/gwt/user/client/ui/Widget.java):28:
>>>  
>>> error: cannot access Event
>>> import com.google.gwt.user.client.Event;
>>>  ^
>>>   bad source file: 
>>> /root/.gradle/caches/modules-2/files-2.1/com.google.gwt/gwt-user/2.8.0-SNAPSHOT/c7913836bdcf2423552e6355ad17fbd271ac5207/gwt-user-2.8.0-SNAPSHOT.jar(com/google/gwt/user/client/Event.java)
>>> file does not contain class com.google.gwt.user.client.Event
>>> Please remove or make sure it appears in the correct 
>>> subdirectory of the sourcepath.
>>> /root/.gradle/caches/modules-2/files-2.1/com.google.gwt/gwt-user/2.8.0-SNAPSHOT/c7913836bdcf2423552e6355ad17fbd271ac5207/gwt-user-2.8.0-SNAPSHOT.jar(com/google/gwt/event/shared/HandlerRegistration.java):23:
>>>  
>>> error: cannot access HandlerRegistration
>>> public interface HandlerRegistration extends 
>>> com.google.web.bindery.event.shared.HandlerRegistration {
>>> 
>>> ^
>>>   bad source file: 
>>> /root/.gradle/caches/modules-2/files-2.1/com.google.gwt/gwt-user/2.8.0-SNAPSHOT/c7913836bdcf2423552e6355ad17fbd271ac5207/gwt-user-2.8.0-SNAPSHOT.jar(com/google/web/bindery/event/shared/HandlerRegistration.java)
>>> file does not contain class 
>>> com.google.web.bindery.event.shared.HandlerRegistration
>>> Please remove or make sure it appears in the correct 
>>> subdirectory of the sourcepath.
>>> 2 errors
>>> :gwt-errai:javadoc FAILED
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: JsInterop and Java collections?

2016-06-10 Thread Kirill Prazdnikov
Hi 

Performance also matters. We build the clint for 3 platforms: iOS, Android, 
GWT.
Storing data in nio.Buffers has HUGE performance impact on mobile 
platforms. 
I see no problem with java->C++ interop with byte[] and float[] for mobile 
platforms (RoboVM, Android) and desktop.

I can do the same in TemVM. All primitive arrays there are Native. 

So that I can write portable and fast code for heavy application like 3d 
editor.  

The problem is that GWT does not support that. 
I must have 2 implementations for type[] for .get .set typed-array.
Using..get .set abstraction is very slow on mobile. It is virtual call. An 
array access 20x-30x times faster.

This is not OK. It would be nice if the GWT compiler had such option (off 
by default). 
It should be possible to preserve all compatibility by adding a new command 
line switch to the compiler command-line. 

I`m ok to break JSNI contact. And we use SSO, the only one and default 
implementation.



On Friday, June 10, 2016 at 1:33:19 PM UTC+3, Thomas Broyer wrote:
>
>
>
> On Friday, June 10, 2016 at 11:12:27 AM UTC+2, Kirill Prazdnikov wrote:
>>
>> Hi Thomas
>>
>> Lets forget about java.util, what about simple arrays ? 
>>
>> It seems that we already have java [] array -> JS Array marshalling. 
>> And It would be very nice if we had these type of marshalling with zero 
>> performance penalty:
>>
>>  java byte[] -> Int8ArrayNative
>>  java short[] -> Int16ArrayNative
>>  java float[] -> FloatArrayNative
>>
>> Currently, there is no way of writing GWT compatible portable code that 
>> operates with  byte[] short[] int[] float[] without java array[] -> JS 
>> TypedArray performance issues
>>
>
> I think there was an experiment to actually implement byte[] et al. as JS 
> typed arrays, but there were issues with it (browser compatibility to begin 
> with, meaning that some browsers would have JS Arrays and some JS typed 
> arrays, so interop with JS would be made harder and errorprone; not to 
> mention that the compiler would then need to know which kind of output it 
> needs to use depending on the permutation, something I don't know it can do 
> today; backwards compatibility: some libraries rely on "conversion" from 
> one type to another by passing through the JSNI boundary, so you can easily 
> send a int[] to JSNI and have it return back the same object as a double[] 
> –maybe–, using an Int32Array to implement int[] would break that; also 
> casting to Object[] conflicts with the new-implemented treatment of 
> java.lang.Double the same as 'double', so double[] and java.lang.Double[] 
> are implemented the exact same way, so you could retrieve a JS Float64Array 
> as a java.lang.Double[] and then it would likely break when cast to 
> Object[])
> In the end, JS type arrays are more like typed java.nio.Buffers 
> (java.nio.DoubleBuffer, etc.) than arrays; so you'd better work with a 
> similar abstraction than with Java arrays.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Adding a new fonctionnality on a legacy CheckBox

2016-06-10 Thread 129pierre
Hi,

I still have a problem with my wrapped SimpleCheckBox.

I used :
SimpleCheckBoxcb = 
SimpleCheckBox.wrap(Document.get().getElementById("idCb"));
for getting a checkbox configured on a legacy server application that I 
cannot change.


This CheckBox has already a fonctionnaly "A"  from the server set with an 
onClick js action.

I want to add another independant functionnality "B" using gwt.  
So I added an ClickHandler to it but the problem is that the  fonctionnaly 
"A" is now broken.

How can I make them works both ?


Thanks in avance
Pierre

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: NPAPI-Plug-in

2016-06-10 Thread Frank
As Thomas said you should use SuperDevMode. More information (although it 
seems a little outdated) can be found here 
: http://www.gwtproject.org/articles/superdevmode.html




On a side note. Some pageson the GWT-Project need an URGENT udpate :
http://www.gwtproject.org/gettingstarted.html --> Uses old DevMode

http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html#SuperDevMode
 
--> Says SDM is only for early adopters

I think several pages from the tutorials, or linked from the tutorials are 
all using DevMode 
like http://www.gwtproject.org/doc/latest/tutorial/debug.html

http://www.gwtproject.org/articles/superdevmode.html --> The page about 
SuperDevMode looks outdated to me. I think it is more than a year ago that 
I used bookmarklets for SuperDevMode. I thought that was deprecated ?

IMO all references to old devmode should be removed completely from the 
website




Also I think some examples using some external libraries should be added. 
Jackson for JSon parsing, Bootstrap3GWT... But I see some examples using 
Polymer so maybe that is false.



In the meantime I learned that the website is just on GitHub, and you don't 
need to do special Gerrit stuff to do a pull request. So maybe if I can 
find some time...

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: JsInterop and Java collections?

2016-06-10 Thread Thomas Broyer


On Friday, June 10, 2016 at 11:12:27 AM UTC+2, Kirill Prazdnikov wrote:
>
> Hi Thomas
>
> Lets forget about java.util, what about simple arrays ? 
>
> It seems that we already have java [] array -> JS Array marshalling. 
> And It would be very nice if we had these type of marshalling with zero 
> performance penalty:
>
>  java byte[] -> Int8ArrayNative
>  java short[] -> Int16ArrayNative
>  java float[] -> FloatArrayNative
>
> Currently, there is no way of writing GWT compatible portable code that 
> operates with  byte[] short[] int[] float[] without java array[] -> JS 
> TypedArray performance issues
>

I think there was an experiment to actually implement byte[] et al. as JS 
typed arrays, but there were issues with it (browser compatibility to begin 
with, meaning that some browsers would have JS Arrays and some JS typed 
arrays, so interop with JS would be made harder and errorprone; not to 
mention that the compiler would then need to know which kind of output it 
needs to use depending on the permutation, something I don't know it can do 
today; backwards compatibility: some libraries rely on "conversion" from 
one type to another by passing through the JSNI boundary, so you can easily 
send a int[] to JSNI and have it return back the same object as a double[] 
–maybe–, using an Int32Array to implement int[] would break that; also 
casting to Object[] conflicts with the new-implemented treatment of 
java.lang.Double the same as 'double', so double[] and java.lang.Double[] 
are implemented the exact same way, so you could retrieve a JS Float64Array 
as a java.lang.Double[] and then it would likely break when cast to 
Object[])
In the end, JS type arrays are more like typed java.nio.Buffers 
(java.nio.DoubleBuffer, etc.) than arrays; so you'd better work with a 
similar abstraction than with Java arrays.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: JsInterop and Java collections?

2016-06-10 Thread Kirill Prazdnikov
Hi Thomas

Lets forget about java.util, what about simple arrays ? 

It seems that we already have java [] array -> JS Array marshalling. 
And It would be very nice if we had these type of marshalling with zero 
performance penalty:

 java byte[] -> Int8ArrayNative
 java short[] -> Int16ArrayNative
 java float[] -> FloatArrayNative

Currently, there is no way of writing GWT compatible portable code that 
operates with  byte[] short[] int[] float[] without java array[] -> JS 
TypedArray performance issues

-K

On Friday, June 10, 2016 at 10:27:58 AM UTC+3, Thomas Broyer wrote:
>
> Except that there is NO marshaling! There are so many cases where it just 
> won't work that it's not even worth trying if you ask me.You
>
>  need to think about isNative vs. "exported" types, method return values 
> vs. parameters vs. fields (which can be both get and set); object 
> identities (calling the getter twice in your example, should it return the 
> same "wrapper" instance? I can already see people complain if that's not 
> the case)
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


GWT Material - Video tutorial #1

2016-06-10 Thread mark kevin ringor
We've just released our gwt-material  first video tutorial - Project Setup 
using gwt-material-archetype with Eclipse IDE and Intelij IDEA.
Also during weeked we will do some shooting to provide the next tutorial 
series.

https://www.youtube.com/watch?v=sEVqfqDUOpE

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: JsInterop and Java collections?

2016-06-10 Thread Vassilis Virvilis
Hi all,

I have already stated that I also believe it is not possible - but as a
thought experiment I believe it would be possible if the two statements
below could hold:

1) The implementations of java.util.List (isNative=true,  namespace =
JsPackage.GLOBAL, name = "Array") (and all other types) can be realized
without private members just with overlay functions.

2) You have to keep the java inheritance structure and constructors correct
for the whole structure to hold (jre emulation). Therefore it must be true
for interfaces and concrete classes.

I believe the above constraints are so hard to meet that it is impossible
to be done. However I am curious (from an academic point of view) if these
are the only requirements or there are more?

 Vassilis


On Fri, Jun 10, 2016 at 10:27 AM, Thomas Broyer  wrote:

> Except that there is NO marshaling! There are so many cases where it just
> won't work that it's not even worth trying if you ask me.You
>
>  need to think about isNative vs. "exported" types, method return values
> vs. parameters vs. fields (which can be both get and set); object
> identities (calling the getter twice in your example, should it return the
> same "wrapper" instance? I can already see people complain if that's not
> the case)
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Vassilis Virvilis

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: JsInterop and Java collections?

2016-06-10 Thread Thomas Broyer
Except that there is NO marshaling! There are so many cases where it just won't 
work that it's not even worth trying if you ask me.You

 need to think about isNative vs. "exported" types, method return values vs. 
parameters vs. fields (which can be both get and set); object identities 
(calling the getter twice in your example, should it return the same "wrapper" 
instance? I can already see people complain if that's not the case)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.