Re: [gwt-contrib] Re: Problem with JsInterop

[Arnaud TOURNIER]

Thanks a lot for your answer.

I tried the solution with defender methods earlier but it did not work, as
far as i remember the compiler refused @JsOverlay defender methods on the
JsFunction. The @JsFunction documentation says that : "A JsFunction
interface cannot have defender methods."
I will try again in this direction and let you know if i find a bug.

Thanks
Arnaud

Le ven. 2 sept. 2016 à 05:28, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> a écrit :

> The limitation around @JsFunction is basically driven from the limitations
> of being a function. I think there was an earlier discussion in the
> contibutor list where we explained this in more detail.
>
> Being said that, you can handle some overloading in JsFunction interfaces
> via defender methods marked with @JsOverlay that are delegating to a main
> method. Something like:
>
>
> @JsFunction
> public interface Resolver {
>
> void resolve(Object value);
>
> @JsOverlay
> default void resolve() { resolve(null); }
> @JsOverlay
> default void resolve(T value) { resolve(value); }
> @JsOverlay
> default void resolve(Promise value) { resolve(value); }
> }
>
> Let's us know before it is too late if you hit any bugs around this :)
>
>
> On Tue, Aug 30, 2016 at 7:13 AM, Arnaud TOURNIER 
> wrote:
>
>> Oh thanks! I'll try that.
>> Once I think we need to merge our work on those topics...
>> Thanks!
>>
>> Le mar. 30 août 2016 16:06, Paul Stockley  a
>> écrit :
>>
>>> If you are passing  Resolver into some function. You could instead
>>> create 3 Resolver interfaces and then overload the function so that it took
>>> each of the resolver interfaces.
>>>
>>>
>>> On Saturday, August 27, 2016 at 9:51:50 AM UTC-4, Arnaud TOURNIER wrote:

 Hi,

 I am playing with js Promises and maybe there's a problem with
 JsInterop or i don't understand something.

 When wrapping the promises with JsInterop, i come to define the
 Resolver interface which represents the resolving callback that is given
 when constructing a promise. In Javascript it is a function and not an
 object, so the interface has the @JsFunction annotation.

 Here is the Resolver interface (inspired from the TypeScript definition
 of Promises...) :

 @JsFunction
 @FunctionalInterface
 public interface Resolver
 {
 void resolve( T value );
 }

 Since the Javascript "resolve" function can be called without
 parameters and also with a Promise instead of a value, i would like to make
 those versions available in the interface.

 But the @JsFunction annotation prevents from having this :

 @JsFunction
 public interface Resolver
 {
 void resolve();

 void resolve( T value );

 void resolve( Promise value );
 }

 That's because it allows only one method in the annotated interface.

 That is what i don't understand : AFAIK, the gwt compiler has to call
 the same function in the same way for the three declared methods (because
 of the semantic of the @JsFunction annotation), just changing the calling
 parameters. So i don't understand why is there the limitation of having
 only one method allowed in @JsFunction interfaces... If it would it would
 give even much power to JsInterop !

 Could you please bring light to my misunderstanding ?

 Thanks !

 Arnaud

>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "GWT Contributors" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/google-web-toolkit-contributors/pNmyrzkfPWo/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, 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/a5ebf0e5-2e7f-40b9-ac82-a52c4b9ee5a6%40googlegroups.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/CANjaDnd6AzYDRpzLdPFkpzw5j6To6BN-22NqPyQVyaB9ER%2B9hQ%40mail.gmail.com
>> 
>> .
>
>
>> For more options, visit 

Re: [gwt-contrib] Re: Problem with JsInterop

['Goktug Gokdogan' via GWT Contributors]

The limitation around @JsFunction is basically driven from the limitations
of being a function. I think there was an earlier discussion in the
contibutor list where we explained this in more detail.

Being said that, you can handle some overloading in JsFunction interfaces
via defender methods marked with @JsOverlay that are delegating to a main
method. Something like:


@JsFunction
public interface Resolver {

void resolve(Object value);

@JsOverlay
default void resolve() { resolve(null); }
@JsOverlay
default void resolve(T value) { resolve(value); }
@JsOverlay
default void resolve(Promise value) { resolve(value); }
}

Let's us know before it is too late if you hit any bugs around this :)


On Tue, Aug 30, 2016 at 7:13 AM, Arnaud TOURNIER  wrote:

> Oh thanks! I'll try that.
> Once I think we need to merge our work on those topics...
> Thanks!
>
> Le mar. 30 août 2016 16:06, Paul Stockley  a écrit :
>
>> If you are passing  Resolver into some function. You could instead
>> create 3 Resolver interfaces and then overload the function so that it took
>> each of the resolver interfaces.
>>
>>
>> On Saturday, August 27, 2016 at 9:51:50 AM UTC-4, Arnaud TOURNIER wrote:
>>>
>>> Hi,
>>>
>>> I am playing with js Promises and maybe there's a problem with JsInterop
>>> or i don't understand something.
>>>
>>> When wrapping the promises with JsInterop, i come to define the Resolver
>>> interface which represents the resolving callback that is given when
>>> constructing a promise. In Javascript it is a function and not an object,
>>> so the interface has the @JsFunction annotation.
>>>
>>> Here is the Resolver interface (inspired from the TypeScript definition
>>> of Promises...) :
>>>
>>> @JsFunction
>>> @FunctionalInterface
>>> public interface Resolver
>>> {
>>> void resolve( T value );
>>> }
>>>
>>> Since the Javascript "resolve" function can be called without parameters
>>> and also with a Promise instead of a value, i would like to make those
>>> versions available in the interface.
>>>
>>> But the @JsFunction annotation prevents from having this :
>>>
>>> @JsFunction
>>> public interface Resolver
>>> {
>>> void resolve();
>>>
>>> void resolve( T value );
>>>
>>> void resolve( Promise value );
>>> }
>>>
>>> That's because it allows only one method in the annotated interface.
>>>
>>> That is what i don't understand : AFAIK, the gwt compiler has to call
>>> the same function in the same way for the three declared methods (because
>>> of the semantic of the @JsFunction annotation), just changing the calling
>>> parameters. So i don't understand why is there the limitation of having
>>> only one method allowed in @JsFunction interfaces... If it would it would
>>> give even much power to JsInterop !
>>>
>>> Could you please bring light to my misunderstanding ?
>>>
>>> Thanks !
>>>
>>> Arnaud
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "GWT Contributors" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/
>> topic/google-web-toolkit-contributors/pNmyrzkfPWo/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/a5ebf0e5-2e7f-
>> 40b9-ac82-a52c4b9ee5a6%40googlegroups.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/CANjaDnd6AzYDRpzLdPFkpzw5j6To6
> BN-22NqPyQVyaB9ER%2B9hQ%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/CAN%3DyUA0eP2NCTC6nWX8y4dF6T4X0TdSrJWVuGk_7E1KKoLs_bA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Kendo UI GWT wrapper library

[Transplant]

On Wednesday, January 20, 2016 at 2:16:37 AM UTC-8, Aron Homberg wrote:
>
> Hi everyone,
>
> I'm wondering if there is any need for a Kendo UI wrapper library. Kendo 
> UI is, as some of you may know, an enterprise front-end web/mobile 
> JavaScript library. It is based on jQuery and comes with a large set of 
> HTML5 widgets, themes, responsiveness etc. pp. It is also compatible with 
> Bootstrap and Angular JS [1].  
>
> Because there is (as far as I know) no GWT support for Kendo UI right now, 
> I started working on my own GWT wrapper library. The implementation is 
> based on GWT 2.8 JsInterop (final) and comes with UiBinder support (a 
> custom element for each Kendo widget). It has a declarative (markup) and a 
> programmatic interface. My goal is to cover all the 70+ Kendo UI widgets 
> soon.
>
> Please let me know if you are interested in such a GWT wrapper library for 
> Kendo UI.
>
>
>
Also interested here - any update? 

-- 
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-contrib] Re: Ext.form.field.File not working with gwt2.8.0-rc2 (with gwt2.8.0-beta1 it works)

[Jens]

> Do you pass --generateJsInteropExports to GWT? I think that's now required 
> for @JsFunction⋅s to be callable from JS.
>

You don't need --generateJsInteropExports to make @JsFunction work, that 
would be bad. Just verified it using RC2 and event listener on button 
element.

But you need --generateJsInteropExports now if anything in the above code 
is a non-native JsType. In Beta1 it worked accidentally in SDM without the 
flag.

-- J.



-- 
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/58331112-ba33-4bf2-a692-116bc18f1904%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Ext.form.field.File not working with gwt2.8.0-rc2 (with gwt2.8.0-beta1 it works)

[Thomas Broyer]

Do you pass --generateJsInteropExports to GWT? I think that's now required 
for @JsFunction⋅s to be callable from JS.

On Thursday, September 1, 2016 at 5:59:41 PM UTC+2, Teletin Alin wrote:
>
> Hi all,
>
> I have a problem with an upload button which sends the selected file to a 
> servlet and takes some action on servlet response.
> This is the code:
>
> //all ESExtXXX or ExtXXX from following code are wrapped javascript with 
> jsinterop
> ESExtCreateParams *uploadPanelParams* = new 
> ESExtCreateParams();
> uploadPanelParams.setWidth(60);
> uploadPanelParams.setHeight(24);
> uploadPanelParams.setLayout("fit");
> ExtFormPanel *panelForm* = (ExtFormPanel) ESExt.create("Ext.form.Panel", 
> uploadPanelParams);
>
> ESExtCreateParams *loadButtonParams* = new ESExtCreateParams();
> loadButtonParams.setButtonText("LoadJsonFile");
> loadButtonParams.setAutoHeight(true);
> // loadButtonParams.setAutoWidth(true);
> loadButtonParams.setHideLabel(true);
> loadButtonParams.setButtonOnly(true);
> loadButtonParams.setFlex(1);
> ExtFormFile *loadButton* = (ExtFormFile) 
> ESExt.create("Ext.form.field.File", loadButtonParams);
> loadButton.addListener("change", new ESStandardFunction() {
>
> @Override
> public void exec() {
> ExtFormBasic *basicForm* = panelForm.getForm();
>
> JsOptions options = new JsOptions();
> options.setUrl("urlToMyServlet");
> options.setMethod("POST");
> options.setWaitMsg("Please wait...");
> options.setFileUpload(true);
> options.setSuccess(new JsSubmitFunction() {
>
> @Override
> public void exec(ExtFormBasic basic, ExtFormSubmit action) {
> *JavaScriptObject result = action.getResult();*
> useJsonData(JsonUtils.stringify(result));
> loadButton.reset();
> }
> });
> options.setFailure(new JsSubmitFunction() {
>
> @Override
> public void exec(ExtFormBasic basic, ExtFormSubmit action) {
> *loadButton.reset();*
> }
> });
>
> basicForm.submit(options);
> }
> });
>
> panelForm.add(loadButton);
>
> This panelForm is added to a ext toolbar which is used in a GWT app.
>
> *As I saw, I can choose a file to upload, that file goes to my servlet, my 
> servlet does its job, but the bold code(functions from on success or on 
> failure) is not called. It should be called when servlet response is 
> returned.*
> I do have in the result a json containing "success" : true or false.
>
> This code works with gwt2.8.0-beta1 but not with gwt2.8.0-rc1 or rc2.
>
> Any suggestions?
>
> Thank you,
> AlinT.
>

-- 
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/ca5d337d-f6d4-4f85-bf1a-353cbab193a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Documentation site on github

[Hristo Stoyanov]

How about using www.gitbook.com? 
Several OSS projets are doing it, their docs look great, for example: 
www.keycloak.org/documentation.html

On Thursday, January 8, 2015 at 2:04:28 PM UTC-8, Julien Dramaix wrote:
>
> Dear GWT Community,
>
> In order to increase the number of contributions on the GWT documentation, 
> we've decided to move the documentation on Github and accept pull requests.
>
> We have also spent time to convert all the documentation in markdown 
> syntax. In addition to that, each documentation page has now an edit 
> button. When you click on, you are redirected to the corresponding markdown 
> page on Github in edit mode. You can easily modify a page and when you save 
> your change Github will automatically fork the project (if needed) and 
> creates a pull request for you. 
>
> This is for the documentation only, the code for GWT will stay on gerrit, 
> simply because gerrit is a much powerful tool to do code review of code.
>
> Julien
>

-- 
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/50dfbb6f-6167-4776-994d-198e33cfba34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Ext.form.field.File not working with gwt2.8.0-rc2 (with gwt2.8.0-beta1 it works)

[Teletin Alin]

Hi all,

I have a problem with an upload button which sends the selected file to a 
servlet and takes some action on servlet response.
This is the code:

//all ESExtXXX or ExtXXX from following code are wrapped javascript with 
jsinterop
ESExtCreateParams *uploadPanelParams* = new 
ESExtCreateParams();
uploadPanelParams.setWidth(60);
uploadPanelParams.setHeight(24);
uploadPanelParams.setLayout("fit");
ExtFormPanel *panelForm* = (ExtFormPanel) ESExt.create("Ext.form.Panel", 
uploadPanelParams);

ESExtCreateParams *loadButtonParams* = new ESExtCreateParams();
loadButtonParams.setButtonText("LoadJsonFile");
loadButtonParams.setAutoHeight(true);
// loadButtonParams.setAutoWidth(true);
loadButtonParams.setHideLabel(true);
loadButtonParams.setButtonOnly(true);
loadButtonParams.setFlex(1);
ExtFormFile *loadButton* = (ExtFormFile) 
ESExt.create("Ext.form.field.File", loadButtonParams);
loadButton.addListener("change", new ESStandardFunction() {

@Override
public void exec() {
ExtFormBasic *basicForm* = panelForm.getForm();

JsOptions options = new JsOptions();
options.setUrl("urlToMyServlet");
options.setMethod("POST");
options.setWaitMsg("Please wait...");
options.setFileUpload(true);
options.setSuccess(new JsSubmitFunction() {

@Override
public void exec(ExtFormBasic basic, ExtFormSubmit action) {
*JavaScriptObject result = action.getResult();*
useJsonData(JsonUtils.stringify(result));
loadButton.reset();
}
});
options.setFailure(new JsSubmitFunction() {

@Override
public void exec(ExtFormBasic basic, ExtFormSubmit action) {
*loadButton.reset();*
}
});

basicForm.submit(options);
}
});

panelForm.add(loadButton);

This panelForm is added to a ext toolbar which is used in a GWT app.

*As I saw, I can choose a file to upload, that file goes to my servlet, my 
servlet does its job, but the bold code(functions from on success or on 
failure) is not called. It should be called when servlet response is 
returned.*
I do have in the result a json containing "success" : true or false.

This code works with gwt2.8.0-beta1 but not with gwt2.8.0-rc1 or rc2.

Any suggestions?

Thank you,
AlinT.

-- 
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/b8930437-e1fc-412f-8955-53995647e86c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: synchronously waiting for a Promise

[Jens]

> Jens, my suggestion was to propagate the asyncs up the call stack to all 
> callers of the function, automatically changing each one to return a 
> promise, and use await on the calls to the async functions, which would 
> work fine except for losing the atomic synchonization of the functions 
> effects in JS, relative to other events
>
 
I see, yeah ok that might work however I think it would instantly break 
your code assumptions because of state modifications.

The reason is that the code that schedules an asynchronous task is 
synchronous in itself. So if you have a long call stack and at the bottom 
you schedule an XMLHttpRequest then everything is still executed 
synchronously, only the result of the request comes in asynchronously and 
only the code that runs when retrieving the result executes asynchronously.

If you now rewrite that to async / await and propagate it through the call 
stack then you have lots of await keywords in your call stack now and at 
all those locations suddenly other code can execute. So when looking at 
your Java code from a higher level you can never be sure if two lines of 
code within the same method body execute synchronously or not.

-- J.

-- 
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: CalenderUtil Date Math BUG - GWT 2.8 RC2

[Michael Joyner]

  
  
As we are not calling a "set" operation but an "addMonthsToDate"
  operation and as a result we find this behavior surprising - and a
  little non-intuitive.
Calendar does not "skip" a month when using "add" month, the days
  are adjusted to the end of the next month to prevent month
  "skipping".
It does behave as described with a month "skip" if using "set"
  month instead.
See also: http://stackoverflow.com/a/14618664/1341731


On 09/01/2016 09:20 AM, Paul Robinson
  wrote:


  
git tells me CalendarUtil.java is the same in 2.7 and
  2.8RC2. So yes, the code should behave the same.


But the above behaviour is not wrong because it's standard Java
behaviour.


Whether you use Date.setMonth(n) or
  Calendar.set(Calendar.MONTH, n) Java behaves the same way.
  That is, if you start on August 31, and set the month to
  September, then you find you are on October 1.


  
  
On Thu, Sep 1, 2016 at 10:01 AM, Daniel
  Kurka 
  wrote:
  
Does this code do the same thing in 2.7?


  

  On Wed, Aug 31, 2016 at 11:41 PM Paul
Robinson 
wrote:
  

  
  

  
You don't say what part of this you
  think is a bug. I presume it's the fact that Aug
  31 plus one month is Oct 1. If so, this is not a
  bug.
Adding one month should do literally
  that, so you get September 31. But there are only
  30 days in September, so this automatically
  becomes October 1.
Paul

  

  

  

  


  




-- 
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: synchronously waiting for a Promise

[Ian Preston]

Jens, my suggestion was to propagate the asyncs up the call stack to all 
callers of the function, automatically changing each one to return a 
promise, and use await on the calls to the async functions, which would 
work fine except for losing the atomic synchonization of the functions 
effects in JS, relative to other events

On Thursday, 1 September 2016 15:10:12 UTC+1, Jens wrote:
>
>
> var _symbol$bar = Symbol("Foo.bar");
>> class Foo {
>>   async getBar() { // Note: transformed to 'async', no 'synchronized'
>> if (this[_symbol$bar] == null) {
>>   var realBar = …;
>>   this[_symbol$bar] = await realBar.get(); // transformed to await
>> }
>> return this[_symbol$bar];
>>   }
>> }
>>
>
> I think this isn't even correct, because "async getBar()" does return a 
> promise simply because its marked async. Given that you can only call await 
> inside async functions I think its nearly impossible to map that to a 
> synchronous Java function while keeping the correct return type or am I 
> missing something?
>
>
> -- J.
>

-- 
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: synchronously waiting for a Promise

[Thomas Broyer]

On Thursday, September 1, 2016 at 4:19:02 PM UTC+2, Thomas Broyer wrote:
>
>
>
> On Thursday, September 1, 2016 at 4:10:12 PM UTC+2, Jens wrote:
>>
>>
>> var _symbol$bar = Symbol("Foo.bar");
>>> class Foo {
>>>   async getBar() { // Note: transformed to 'async', no 'synchronized'
>>> if (this[_symbol$bar] == null) {
>>>   var realBar = …;
>>>   this[_symbol$bar] = await realBar.get(); // transformed to await
>>> }
>>> return this[_symbol$bar];
>>>   }
>>> }
>>>
>>
>> I think this isn't even correct, because "async getBar()" does return a 
>> promise simply because its marked async. Given that you can only call await 
>> inside async functions I think its nearly impossible to map that to a 
>> synchronous Java function while keeping the correct return type or am I 
>> missing something?
>>
>
> That was part of Ian's proposal (emphasis mine):
>
> “If it makes it all the way to a function exposed with JsInterop, then *that 
> function changes signature like the rest of them to return a promise*. 
> The consumer of this function is obviously in JS and so can handle the 
> promise fine. This would equate to translating the synchronous java calls 
> which wait on a CompletableFuture (Promise) to return promises in JS.” 
>

…and yes, that'd mean that one small change in one class could change the 
exposed API from/to a Promise "at the other end" of your project. Good luck 
tracking those changes and never introduce a bug because of them ;-)

-- 
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: synchronously waiting for a Promise

[Jens]

> I think this isn't even correct, because "async getBar()" does return a 
> promise simply because its marked async. Given that you can only call await 
> inside async functions I think its nearly impossible to map that to a 
> synchronous Java function while keeping the correct return type or am I 
> missing something?
>

To be clear:

async getBar() {
  var str = await getSomeStringAsync();
  return str;
}

must map to Promise / CompletableFuture getBar() in Java 
just to get the return type correct. But that defeats the purpose of trying 
to make getBar() look synchronous in Java. And you can not internally 
unwrap that Promise (e.g. through getBar() implemented as 
getBarImpl().then(...)) synchronously.

So I think this can't really work.

-- J.

-- 
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: synchronously waiting for a Promise

[Thomas Broyer]

On Thursday, September 1, 2016 at 4:10:12 PM UTC+2, Jens wrote:
>
>
> var _symbol$bar = Symbol("Foo.bar");
>> class Foo {
>>   async getBar() { // Note: transformed to 'async', no 'synchronized'
>> if (this[_symbol$bar] == null) {
>>   var realBar = …;
>>   this[_symbol$bar] = await realBar.get(); // transformed to await
>> }
>> return this[_symbol$bar];
>>   }
>> }
>>
>
> I think this isn't even correct, because "async getBar()" does return a 
> promise simply because its marked async. Given that you can only call await 
> inside async functions I think its nearly impossible to map that to a 
> synchronous Java function while keeping the correct return type or am I 
> missing something?
>

That was part of Ian's proposal (emphasis mine):

“If it makes it all the way to a function exposed with JsInterop, then *that 
function changes signature like the rest of them to return a promise*. The 
consumer of this function is obviously in JS and so can handle the promise 
fine. This would equate to translating the synchronous java calls which 
wait on a CompletableFuture (Promise) to return promises in JS.” 

-- 
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: synchronously waiting for a Promise

[Jens]

> var _symbol$bar = Symbol("Foo.bar");
> class Foo {
>   async getBar() { // Note: transformed to 'async', no 'synchronized'
> if (this[_symbol$bar] == null) {
>   var realBar = …;
>   this[_symbol$bar] = await realBar.get(); // transformed to await
> }
> return this[_symbol$bar];
>   }
> }
>

I think this isn't even correct, because "async getBar()" does return a 
promise simply because its marked async. Given that you can only call await 
inside async functions I think its nearly impossible to map that to a 
synchronous Java function while keeping the correct return type or am I 
missing something?


-- J.

-- 
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: synchronously waiting for a Promise

[Steve Hannah]

If you require synchronous code you may want to check out TeaVm.  It
supports full Java thread semantics in the browser.

On Thursday, 1 September 2016, Ian Preston  wrote:

> Cool example. You are right.
>
> We are migrating our code to asynchronous. :-)
>
>
>
> On Thursday, 1 September 2016 13:59:45 UTC+1, Thomas Broyer wrote:
>>
>> Consider the following code:
>>
>> class Foo {
>>   String bar;
>>
>>   synchronized String getBar() {
>> if (bar == null) { // OK, we all know this is bad in the Java world,
>> just bear with me for this sample code
>>   Future realBar = …; // make a call that returns a
>> CompletableFuture
>>   bar = realBar.get();
>> }
>> return bar;
>>   }
>> }
>>
>> You're proposing that it's somehow translated more or less to:
>>
>> var _symbol$bar = Symbol("Foo.bar");
>> class Foo {
>>   async getBar() { // Note: transformed to 'async', no 'synchronized'
>> if (this[_symbol$bar] == null) {
>>   var realBar = …;
>>   this[_symbol$bar] = await realBar.get(); // transformed to await
>> }
>> return this[_symbol$bar];
>>   }
>> }
>>
>> Now imagine that while await⋅ing realBar.get(), getBar() is called again,
>> on the same Foo instance (triggered by an event; for example, getBar() is
>> called from a click handler, and the … returning the
>> CompletableFuture fetches some resource through HTTP).
>> Looking at the original Java code, you'd expect that the second call is
>> blocked until the first one terminates and releases the lock on the Foo
>> object, so the first call would set the bar field and the second call would
>> skip the 'if' branch.
>> In JS though, the second call would *enter* the 'if' branch and make a
>> second call; then, when each 'realBar' is completed, the private (through
>> Symbol) property is set: twice; and if the call that returned a
>> CompletableFuture is stateful, that means the state has been
>> modified twice.
>> What kind of JS would you produce that'd prevent this from happening?
>>
>> I wouldn't trade "emulating CompletableFuture#get" for "bloated JS and a
>> much more complex compiler". The Pareto rule tells us that you should just
>> embrace asynchrony and live with only the non-blocking API (CompletionStage
>> basically, plus getNow() and a few others).
>>
>> On Thursday, September 1, 2016 at 11:53:45 AM UTC+2, Ian Preston wrote:
>>>
>>> Interesting question, Thomas. I believe it should still work. Consider
>>> the following:
>>>
>>> 1. A 'thread' comes into a method and obtains a lock on A.
>>> 2. whilst holding the lock, it makes an async call to
>>> CompletableFuture.get()
>>> 3. Somewhere down the call stack some state which is guarded by the lock
>>> on A is modified
>>> On the JVM, either that lock is not re-entrant, in which case it is a
>>> deadlock, or it is re-entrant and modifying the state is fine. We only have
>>> one thread in JS so it is fine.
>>>
>>> Correct me if I'm wrong, but I believe this means that GWT could
>>> continue to ignore synchronization, and get the same results assuming non
>>> deadlocking programs, which can't be translated without a full emulator
>>> like doppio anyway.
>>>
>>>
>>> On Thursday, 1 September 2016 10:22:08 UTC+1, Thomas Broyer wrote:



 On Wednesday, August 31, 2016 at 11:58:51 PM UTC+2, Ian Preston wrote:
>
> One idea, which would be awesome from a user perspective, is the
> following:
>
> Emulate CompletableFuture with native Promises. Then if the
> synchronous cf.get() call is used, then translate that to await, and make
> the function it is in async (in JS land). This would automatically change
> the signature to a CompletableFuture, and then propagate this up to all
> callers. If it makes it all the way to a function exposed with JsInterop,
> then that function changes signature like the rest of them to return a
> promise. The consumer of this function is obviously in JS and so can 
> handle
> the promise fine. This would equate to translating the synchronous java
> calls which wait on a CompletableFuture (Promise) to return promises in 
> JS.
> This wouldn't require any changes to the Java code - it could continue in
> its synchronous style, and not disrupt JVM based users of the same code.
>

> Thoughts?
>

 'await' is not synchronous, which means things can happen while
 awaiting, which could mutate state you'd rely on being immutable because
 you 'synchronized' it (in other words: how would your proposal work with
 the 'synchronized' keyword? GWT currently simply ignores 'synchronized'
 because JS is single-threaded anyway; now what if you call
 CompletableFuture#get() within a 'synchronized' function, possibly several
 levels deep in the call-stack?).

 There are good reasons why only async functions can call async
 functions, and only async functions can use the await keyword: explicit vs.

Re: synchronously waiting for a Promise

[Ian Preston]

Cool example. You are right. 

We are migrating our code to asynchronous. :-)



On Thursday, 1 September 2016 13:59:45 UTC+1, Thomas Broyer wrote:
>
> Consider the following code:
>
> class Foo {
>   String bar;
>
>   synchronized String getBar() {
> if (bar == null) { // OK, we all know this is bad in the Java world, 
> just bear with me for this sample code
>   Future realBar = …; // make a call that returns a 
> CompletableFuture
>   bar = realBar.get();
> }
> return bar;
>   }
> }
>
> You're proposing that it's somehow translated more or less to:
>
> var _symbol$bar = Symbol("Foo.bar");
> class Foo {
>   async getBar() { // Note: transformed to 'async', no 'synchronized'
> if (this[_symbol$bar] == null) {
>   var realBar = …;
>   this[_symbol$bar] = await realBar.get(); // transformed to await
> }
> return this[_symbol$bar];
>   }
> }
>
> Now imagine that while await⋅ing realBar.get(), getBar() is called again, 
> on the same Foo instance (triggered by an event; for example, getBar() is 
> called from a click handler, and the … returning the 
> CompletableFuture fetches some resource through HTTP).
> Looking at the original Java code, you'd expect that the second call is 
> blocked until the first one terminates and releases the lock on the Foo 
> object, so the first call would set the bar field and the second call would 
> skip the 'if' branch.
> In JS though, the second call would *enter* the 'if' branch and make a 
> second call; then, when each 'realBar' is completed, the private (through 
> Symbol) property is set: twice; and if the call that returned a 
> CompletableFuture is stateful, that means the state has been 
> modified twice.
> What kind of JS would you produce that'd prevent this from happening?
>
> I wouldn't trade "emulating CompletableFuture#get" for "bloated JS and a 
> much more complex compiler". The Pareto rule tells us that you should just 
> embrace asynchrony and live with only the non-blocking API (CompletionStage 
> basically, plus getNow() and a few others).
>
> On Thursday, September 1, 2016 at 11:53:45 AM UTC+2, Ian Preston wrote:
>>
>> Interesting question, Thomas. I believe it should still work. Consider 
>> the following: 
>>
>> 1. A 'thread' comes into a method and obtains a lock on A.
>> 2. whilst holding the lock, it makes an async call to 
>> CompletableFuture.get()
>> 3. Somewhere down the call stack some state which is guarded by the lock 
>> on A is modified
>> On the JVM, either that lock is not re-entrant, in which case it is a 
>> deadlock, or it is re-entrant and modifying the state is fine. We only have 
>> one thread in JS so it is fine. 
>>
>> Correct me if I'm wrong, but I believe this means that GWT could continue 
>> to ignore synchronization, and get the same results assuming non 
>> deadlocking programs, which can't be translated without a full emulator 
>> like doppio anyway. 
>>
>>
>> On Thursday, 1 September 2016 10:22:08 UTC+1, Thomas Broyer wrote:
>>>
>>>
>>>
>>> On Wednesday, August 31, 2016 at 11:58:51 PM UTC+2, Ian Preston wrote:

 One idea, which would be awesome from a user perspective, is the 
 following:

 Emulate CompletableFuture with native Promises. Then if the synchronous 
 cf.get() call is used, then translate that to await, and make the function 
 it is in async (in JS land). This would automatically change the signature 
 to a CompletableFuture, and then propagate this up to all callers. If it 
 makes it all the way to a function exposed with JsInterop, then that 
 function changes signature like the rest of them to return a promise. The 
 consumer of this function is obviously in JS and so can handle the promise 
 fine. This would equate to translating the synchronous java calls which 
 wait on a CompletableFuture (Promise) to return promises in JS. This 
 wouldn't require any changes to the Java code - it could continue in its 
 synchronous style, and not disrupt JVM based users of the same code. 

>>>
 Thoughts?

>>>
>>> 'await' is not synchronous, which means things can happen while 
>>> awaiting, which could mutate state you'd rely on being immutable because 
>>> you 'synchronized' it (in other words: how would your proposal work with 
>>> the 'synchronized' keyword? GWT currently simply ignores 'synchronized' 
>>> because JS is single-threaded anyway; now what if you call 
>>> CompletableFuture#get() within a 'synchronized' function, possibly several 
>>> levels deep in the call-stack?).
>>>
>>> There are good reasons why only async functions can call async 
>>> functions, and only async functions can use the await keyword: explicit vs. 
>>> implicit.
>>>
>>>

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

Re: CalenderUtil Date Math BUG - GWT 2.8 RC2

[Paul Robinson]

git tells me CalendarUtil.java is the same in 2.7 and 2.8RC2. So yes, the
code should behave the same.

But the above behaviour is not wrong because it's standard Java behaviour.

Whether you use Date.setMonth(n) or Calendar.set(Calendar.MONTH, n) Java
behaves the same way. That is, if you start on August 31, and set the month
to September, then you find you are on October 1.


On Thu, Sep 1, 2016 at 10:01 AM, Daniel Kurka 
wrote:

> Does this code do the same thing in 2.7?
>
> On Wed, Aug 31, 2016 at 11:41 PM Paul Robinson  wrote:
>
>> You don't say what part of this you think is a bug. I presume it's the
>> fact that Aug 31 plus one month is Oct 1. If so, this is not a bug.
>>
>> Adding one month should do literally that, so you get September 31. But
>> there are only 30 days in September, so this automatically becomes October
>> 1.
>>
>> Paul
>>
>> --
>> 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.
>

-- 
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: synchronously waiting for a Promise

[Thomas Broyer]

Consider the following code:

class Foo {
  String bar;

  synchronized String getBar() {
if (bar == null) { // OK, we all know this is bad in the Java world, 
just bear with me for this sample code
  Future realBar = …; // make a call that returns a 
CompletableFuture
  bar = realBar.get();
}
return bar;
  }
}

You're proposing that it's somehow translated more or less to:

var _symbol$bar = Symbol("Foo.bar");
class Foo {
  async getBar() { // Note: transformed to 'async', no 'synchronized'
if (this[_symbol$bar] == null) {
  var realBar = …;
  this[_symbol$bar] = await realBar.get(); // transformed to await
}
return this[_symbol$bar];
  }
}

Now imagine that while await⋅ing realBar.get(), getBar() is called again, 
on the same Foo instance (triggered by an event; for example, getBar() is 
called from a click handler, and the … returning the 
CompletableFuture fetches some resource through HTTP).
Looking at the original Java code, you'd expect that the second call is 
blocked until the first one terminates and releases the lock on the Foo 
object, so the first call would set the bar field and the second call would 
skip the 'if' branch.
In JS though, the second call would *enter* the 'if' branch and make a 
second call; then, when each 'realBar' is completed, the private (through 
Symbol) property is set: twice; and if the call that returned a 
CompletableFuture is stateful, that means the state has been 
modified twice.
What kind of JS would you produce that'd prevent this from happening?

I wouldn't trade "emulating CompletableFuture#get" for "bloated JS and a 
much more complex compiler". The Pareto rule tells us that you should just 
embrace asynchrony and live with only the non-blocking API (CompletionStage 
basically, plus getNow() and a few others).

On Thursday, September 1, 2016 at 11:53:45 AM UTC+2, Ian Preston wrote:
>
> Interesting question, Thomas. I believe it should still work. Consider the 
> following: 
>
> 1. A 'thread' comes into a method and obtains a lock on A.
> 2. whilst holding the lock, it makes an async call to 
> CompletableFuture.get()
> 3. Somewhere down the call stack some state which is guarded by the lock 
> on A is modified
> On the JVM, either that lock is not re-entrant, in which case it is a 
> deadlock, or it is re-entrant and modifying the state is fine. We only have 
> one thread in JS so it is fine. 
>
> Correct me if I'm wrong, but I believe this means that GWT could continue 
> to ignore synchronization, and get the same results assuming non 
> deadlocking programs, which can't be translated without a full emulator 
> like doppio anyway. 
>
>
> On Thursday, 1 September 2016 10:22:08 UTC+1, Thomas Broyer wrote:
>>
>>
>>
>> On Wednesday, August 31, 2016 at 11:58:51 PM UTC+2, Ian Preston wrote:
>>>
>>> One idea, which would be awesome from a user perspective, is the 
>>> following:
>>>
>>> Emulate CompletableFuture with native Promises. Then if the synchronous 
>>> cf.get() call is used, then translate that to await, and make the function 
>>> it is in async (in JS land). This would automatically change the signature 
>>> to a CompletableFuture, and then propagate this up to all callers. If it 
>>> makes it all the way to a function exposed with JsInterop, then that 
>>> function changes signature like the rest of them to return a promise. The 
>>> consumer of this function is obviously in JS and so can handle the promise 
>>> fine. This would equate to translating the synchronous java calls which 
>>> wait on a CompletableFuture (Promise) to return promises in JS. This 
>>> wouldn't require any changes to the Java code - it could continue in its 
>>> synchronous style, and not disrupt JVM based users of the same code. 
>>>
>>
>>> Thoughts?
>>>
>>
>> 'await' is not synchronous, which means things can happen while awaiting, 
>> which could mutate state you'd rely on being immutable because you 
>> 'synchronized' it (in other words: how would your proposal work with the 
>> 'synchronized' keyword? GWT currently simply ignores 'synchronized' because 
>> JS is single-threaded anyway; now what if you call CompletableFuture#get() 
>> within a 'synchronized' function, possibly several levels deep in the 
>> call-stack?).
>>
>> There are good reasons why only async functions can call async functions, 
>> and only async functions can use the await keyword: explicit vs. implicit.
>>
>>

-- 
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: synchronously waiting for a Promise

[Ian Preston]

Interesting question, Thomas. I believe it should still work. Consider the 
following: 

1. A 'thread' comes into a method and obtains a lock on A.
2. whilst holding the lock, it makes an async call to 
CompletableFuture.get()
3. Somewhere down the call stack some state which is guarded by the lock on 
A is modified
On the JVM, either that lock is not re-entrant, in which case it is a 
deadlock, or it is re-entrant and modifying the state is fine. We only have 
one thread in JS so it is fine. 

Correct me if I'm wrong, but I believe this means that GWT could continue 
to ignore synchronization, and get the same results assuming non 
deadlocking programs, which can't be translated without a full emulator 
like doppio anyway. 


On Thursday, 1 September 2016 10:22:08 UTC+1, Thomas Broyer wrote:
>
>
>
> On Wednesday, August 31, 2016 at 11:58:51 PM UTC+2, Ian Preston wrote:
>>
>> One idea, which would be awesome from a user perspective, is the 
>> following:
>>
>> Emulate CompletableFuture with native Promises. Then if the synchronous 
>> cf.get() call is used, then translate that to await, and make the function 
>> it is in async (in JS land). This would automatically change the signature 
>> to a CompletableFuture, and then propagate this up to all callers. If it 
>> makes it all the way to a function exposed with JsInterop, then that 
>> function changes signature like the rest of them to return a promise. The 
>> consumer of this function is obviously in JS and so can handle the promise 
>> fine. This would equate to translating the synchronous java calls which 
>> wait on a CompletableFuture (Promise) to return promises in JS. This 
>> wouldn't require any changes to the Java code - it could continue in its 
>> synchronous style, and not disrupt JVM based users of the same code. 
>>
>
>> Thoughts?
>>
>
> 'await' is not synchronous, which means things can happen while awaiting, 
> which could mutate state you'd rely on being immutable because you 
> 'synchronized' it (in other words: how would your proposal work with the 
> 'synchronized' keyword? GWT currently simply ignores 'synchronized' because 
> JS is single-threaded anyway; now what if you call CompletableFuture#get() 
> within a 'synchronized' function, possibly several levels deep in the 
> call-stack?).
>
> There are good reasons why only async functions can call async functions, 
> and only async functions can use the await keyword: explicit vs. implicit.
>
>

-- 
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: Public and war folders in the maven project layout (tbroyer plugin)?

[Thomas Broyer]

On Thursday, September 1, 2016 at 11:33:53 AM UTC+2, Bruno Salmon wrote:
>
> Hi,
>
> The GWT documentation 
> 
>  
> describes the project layout using Eclipse, but I have a couple of 
> questions when transposing it into the maven project layout (using the 
> tbroyer plugin):
>
> - where is the public folder located in the maven project layout? I tried 
> different places (such as src/public, src/main/public, 
> src/main/resources/public) but it was never found by the compiler
>

The 'public' folder always comes as a subpackage of where your *.gwt.xml 
lives. So if your module is com.example.testapp.TestApp (ultimately a 
com/example/testapp/TestApp.gwt.xml file in the classpath), your public 
folder would be (using the default convention) com/example/testapp/public. 
You could technically put it either in src/main/java or src/main/resources, 
though src/main/resources would be preferred in a gwt-app or gwt-lib 
project.
 

> - where can I put my host page and other html/css sources files? The 
> documentation talks about the war folder, but this directory seems to be 
> the webappDirectory in the tbroyer plugn, so it's a an output directory 
> under the target folder which is not a good place for sources files (they 
> are erased with maven clean).
>

The 'war folder' is used as both input (for static assets and your WEB-INF/ 
folder) and output (where GWT will write the compilation output), but Maven 
(and many other build tools) have a clear/clean separation of input(source) 
and output(target) folders.
It's impossible to accurately answer your questions, because it depends 
what you're building and how you build it.

If you're building a webapp with a server part, then use the 
src/main/webapp from your server/webapp Maven module (you use distinct 
modules for client and server parts, right?); in other words, the host page 
is part of your webapp, not your GWT app. See 
https://github.com/tbroyer/gwt-maven-archetypes
If you build a standalone client application, then use the 'public path' in 
a gwt-app Maven module; that way the WAR/ZIP file created by your build 
will include both the JS output from GWT and your static assets, actually 
copied there by the GWT compiler. (You could also use the 
resources:copy-resources in the prepare-package phase to copy from, say, 
src/main/webapp to the target folder, but running your app in development 
mode would be a bit more complicated).

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

Public and war folders in the maven project layout (tbroyer plugin)?

[Bruno Salmon]

Hi,

The GWT documentation 

 
describes the project layout using Eclipse, but I have a couple of 
questions when transposing it into the maven project layout (using the 
tbroyer plugin):

- where is the public folder located in the maven project layout? I tried 
different places (such as src/public, src/main/public, 
src/main/resources/public) but it was never found by the compiler

- where can I put my host page and other html/css sources files? The 
documentation talks about the war folder, but this directory seems to be 
the webappDirectory in the tbroyer plugn, so it's a an output directory 
under the target folder which is not a good place for sources files (they 
are erased with maven clean).

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: synchronously waiting for a Promise

[Thomas Broyer]

On Wednesday, August 31, 2016 at 11:58:51 PM UTC+2, Ian Preston wrote:
>
> One idea, which would be awesome from a user perspective, is the following:
>
> Emulate CompletableFuture with native Promises. Then if the synchronous 
> cf.get() call is used, then translate that to await, and make the function 
> it is in async (in JS land). This would automatically change the signature 
> to a CompletableFuture, and then propagate this up to all callers. If it 
> makes it all the way to a function exposed with JsInterop, then that 
> function changes signature like the rest of them to return a promise. The 
> consumer of this function is obviously in JS and so can handle the promise 
> fine. This would equate to translating the synchronous java calls which 
> wait on a CompletableFuture (Promise) to return promises in JS. This 
> wouldn't require any changes to the Java code - it could continue in its 
> synchronous style, and not disrupt JVM based users of the same code. 
>

> Thoughts?
>

'await' is not synchronous, which means things can happen while awaiting, 
which could mutate state you'd rely on being immutable because you 
'synchronized' it (in other words: how would your proposal work with the 
'synchronized' keyword? GWT currently simply ignores 'synchronized' because 
JS is single-threaded anyway; now what if you call CompletableFuture#get() 
within a 'synchronized' function, possibly several levels deep in the 
call-stack?).

There are good reasons why only async functions can call async functions, 
and only async functions can use the await keyword: explicit vs. implicit.

-- 
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: CalenderUtil Date Math BUG - GWT 2.8 RC2

[Daniel Kurka]

Does this code do the same thing in 2.7?

On Wed, Aug 31, 2016 at 11:41 PM Paul Robinson  wrote:

> You don't say what part of this you think is a bug. I presume it's the
> fact that Aug 31 plus one month is Oct 1. If so, this is not a bug.
>
> Adding one month should do literally that, so you get September 31. But
> there are only 30 days in September, so this automatically becomes October
> 1.
>
> Paul
>
> --
> 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.