Re: Deploying symbolMaps in a production build

[Colin Alworth]

Symbol maps are distinct from source maps, the serve different purposes. 
Sourcemaps, when deployed with your actual source, allow the browser to ask 
the server for your Java source, so you can see if when you debug - this 
may not be something most production applications want their customers to 
be able to find.

In contrast, symbol maps are used by the server, so when the client sends 
the server a stack trace, it can figure out what that stack trace should 
have looked like in Java (see 
com.google.gwt.core.server.StackTraceDeobfuscator). This will work without 
enabling sourcemaps.

The "// #sourceURL=" is used to say to the browser "pretend that this 
string you are eval()ing is actually a file with this name and path". If 
used in conjunction with sourcemaps, then *if you have deployed sourcemaps*, 
viewing the source in your browser will show all Java classes.

To turn on production sourcemaps, add this to your .gwt.xml file (assuming 
the CrossSiteIframeLinker, which it appears you are using) if you just want 
them always on (assumes one permutation):

  

If you have more than one permutation, you'll want to set up a pattern in 
here, based on the docs in CrossSiteIframeLinker.gwt.xml:
  

This only adds the missing "// #sourceMappingURL=" to your output, but the 
sourcemaps has to actually be there for you to use it, and in the right 
place - using those custom URL features will help you change where it goes. 

Keep in mind that your webserver will not serve any content in WEB-INF/, so 
you'll need to build those somewhere else for the client to see it (see the 
-deploy flag). You would also need to add all of your java sources, and 
they are also expected to be found in the same directory as the sourcemap 
file, and remember that this may allow your users to see the app's sources.



On Tuesday, November 14, 2017 at 7:34:40 AM UTC-6, AJ wrote:
>
> Hello,
> I have an issue that only manifests in a deployed GWT application and so 
> am trying to enable source maps in the production build.
>
> I have added...
>
> 
> 
>
> ...to the project.ui.xml file and have passed -saveSource to the compiler
>
> In my war I see the WEB-INF/deploy/ProjectName/symbolMaps folder
>  containing 1A2B3C.symbolMap and 1A2B3C_sourceMap0.json
>
> My understanding is that I need to have the following comment at the 
> bottom of the various generated javascript files which are pulled in by the 
> bootstrap code
> //# sourceMappingURL=myUrl
>
> so I should see that at the bottom of 1A2B3C.cache.js found in the project 
> folder of the war (same folder as myProject.nocache.js)
>
> What I see at the end of that file is...
>
> //# sourceURL=Utmc-0.js
>
> ... and this is what is delivered in chrome devtools when I try to find 
> the source
>
> Has anyone else tried this and, if so, what am I missing?
>
>

-- 
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: Deploying to org.gwtproject.* groupId

[Colin Alworth]

I've been over your gwt-events - looked good from 30 mins or so of poking 
around, but largely copy/paste, so that makes sense right?

Removing old browsers seems reasonable - if we get issues filed asking for 
old browser support, we can deal with that as needed, but these are meant 
to be modern builds of modules that still have support for old browsers. 
GWT 3 won't support the modern browsers, and even IE11 doesn't support 
Promises, so implementing Scheduler.scheduleFinally might not be possible 
without JSNI and $entry anyway... That's always been my understanding of 
the approach at least.

I'll read those other three today, but if the tests pass and the API holds 
(aside from renaming packages), it sounds like they could already be out 
there and ready for use ;). So what's the holdup? I'm being facetious, but 
I'm hoping we can make a plan that even we active contributors can follow, 
and set an easy example for others to follow.

That said, with Jens's reply in mind: If we want a CLA for projects that 
get under gwtproject.org, if we want strict code review (though I did put 
the checkstyle in my sample project), I'm going to advocate strongly for 
individual projects and personal groupIds to start with, until people who 
want to build that process are happy with it and have it deployed. The 
downside of having strict standards seems clear: not even active 
contributors are trying to meet them. At least Git gives us the ability to 
look back in history, and see where code came from in an external project, 
make sure everyone is on board with moving to gwtproject.

On Wednesday, November 15, 2017 at 11:14:34 AM UTC-6, Thomas Broyer wrote:
>
>
>
> On Wednesday, November 15, 2017 at 6:02:03 PM UTC+1, Colin Alworth wrote:
>>
>> Thanks guys - I guess I'm confused as to why Daniel and Thomas have their 
>> projects so far in their own repos, and not in github.com/gwtproject - I 
>> was following that example. If you guys are ready to move them now and ship 
>> them (0.9 or 1.0-beta-n, either works for me) to central, then I have no 
>> objection.
>>
>> My main goal was to lower the barrier to entry - if we don't ship things 
>> that aren't under gwtproject, and we don't even put *our own projects* 
>> on gwtproject, I was concerned about how this might look to external 
>> contributors, especially given how many small projects we're going to need 
>> to have started and finished in the near future. 
>>
>> If you guys can move your projects and get them out on central,
>>
>
> I'd prefer if someone reviewed them before (particularly gwt-events; 
> gwt-http, gwt-window and gwt-history have nothing controversial in there 
> IIRC, except maybe for the fact I removed support for "old browsers" –they 
> should theoretically work in IE10+, Firefox ESR, and evergreen browsers).
> Also wrt the choice of groupId and artifactId.
> If you'd prefer that I don't wait before I move them, that works for me; 
> but I'd rather have a second pair of (critical) eyes look at the code 
> before I push anything to Central (btw, we need to ask Sonatype OSSRH for 
> the org.gwtproject groupId, and grant release rights to a few people; who 
> does that?)
>
> I'll change my yet-unpublished advice to be "start the project in your own 
>> repo, and ask it be moved once it is ready" or perhaps "ask for a new repo 
>> to be created in gwtproject, then push your sources there in a large pull 
>> request"?
>>
>
> I'd rather go for the second advice then.
>
> (fwiw, I tried to follow your yet-unpublished blog post for gwt-http, 
> gwt-window and gwt-history, and have it show clearly and cleanly in the 
> commit history; it took some time but at least they can serve as examples)
>

-- 
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/ac438217-1e68-4d98-9b4f-b53fded66538%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

[Colin Alworth]

Thanks guys - I guess I'm confused as to why Daniel and Thomas have their 
projects so far in their own repos, and not in github.com/gwtproject - I 
was following that example. If you guys are ready to move them now and ship 
them (0.9 or 1.0-beta-n, either works for me) to central, then I have no 
objection.

My main goal was to lower the barrier to entry - if we don't ship things 
that aren't under gwtproject, and we don't even put *our own projects* on 
gwtproject, I was concerned about how this might look to external 
contributors, especially given how many small projects we're going to need 
to have started and finished in the near future. 

If you guys can move your projects and get them out on central, I'll change 
my yet-unpublished advice to be "start the project in your own repo, and 
ask it be moved once it is ready" or perhaps "ask for a new repo to be 
created in gwtproject, then push your sources there in a large pull 
request"?

-- 
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/7e14e048-a2ba-4d56-b314-909a19cc55b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Deploying to org.gwtproject.* groupId

[Colin Alworth]

 I'm about to put out a blog post with a bunch of details on how one might 
port gwt-user.jar modules out (thanks to the hard work of those who have 
started this effort already, especially Dan Kurka and Thomas Broyer), and 
once those are ready to be consumed, we'll certainly want the various 
artifacts on maven central. The goal in this is to start motivating 
contributors and community members to assist in the migration work 
necessary to get us within reach of a GWT 3 ecosystem.

The topic of "where we deploy early efforts" has come up a few times behind 
relatively closed doors - multiple times in steering calls, and of course 
at length at GwtCon this year. So, opening it up for broad discussion: 
should we expect to start pushing release to org.gwtproject.* right away, 
and if not, are we encouraging individual contributors to push to their own 
groupIds until we *are* ready?

Case for org.gwtproject: "centralized" jenkins server with creds to push, 
making it easy to add a project (automatically?) and get it out there so 
others can use it. Might want some manual checks on what is going out (or 
else whoever is responsible for the groupId will look silly if it turns out 
we are shipping malware), which implies full or partial review (manual 
process) of each release before pushing the button. Makes it clear right 
away to people searching maven central that they have found the right new 
modules, since they are all under the org.gwtproject umbrella.

Case for individual groupIds: makes it clear to early adopters that these 
are "incubator" projects, and they should probably vet them themselves, or 
they are relying on the community and goodwill of other developers, and 
that these migrated modules are *not* official - at least not yet. Lower 
friction, gets snapshots and releases out faster.

No matter how we go, I am certain that we'll want to push to org.gwtproject 
once these modules are stabilizing and we (gwt maintainers and 
contributors) are confident in the code being shipped. 

Thoughts? Which ever way we go, I'd like to see the already ready-for-use 
artifacts deployed within a few days - if that is too soon for 
org.gwtproject, then I think that makes the choice clear, or else who knows 
how long we'll be waiting.

-- 
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/88b63997-3178-4d63-9f32-61cf531461c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT csrf protection EXPERIMENTAL methods

[Colin Alworth]

To answer the original question, no - no changes are planned in the Xsrf 
variants of generator-based RPC. We should remove those comments. I am 
aware of no reason to not use the Xsrf variants in production code.

Looking forward, beyond gwt-user.jar, I have the core of RPC working 
correctly in Annotation Processors (i.e. so that it is compatible with GWT 
3). I do not have the equivalent of RemoteService ready yet, but when I get 
there I will make sure tools are available akin to XsrfProtectedService. 
However, while migration should be minimal to this updated version, it will 
not be zero - at the very least a different servlet will be required, and a 
constructor call instead of GWT.create.

-- 
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/12402d44-1c27-459f-9b11-4c8665f00b0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] GWT 2.8.2 release

[Colin Alworth]

Today we released the next version of GWT, version 2.8.2. A few quick 
highlights from this new release:

   - GWT can now run on Java 9 (though Java 9 features are not yet 
   supported, coming soon!)
   - Chrome 61 change in getAbsoluteTop/Left has been fixed
   - Errors on the page reported from window.onerror are now reported to 
   your uncaught exception handler
   - GWT now generates CSP compliant dom elements

The release notes can be found at 
http://www.gwtproject.org/release-notes.html#Release_Notes_2_8_2. Get yours 
from Maven Central, or from the zip release .
Special thanks to Max Barkley of RedHat who helped lead the release effort 
this time, and to all of the fantastic testers who helped us ensure that 
this release was ready to go.

-- 
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/c22fab4d-87ee-4c75-a49a-460cdc6ac3a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

On Wed, Oct 11, 2017, at 02:01 PM, 'Goktug Gokdogan' via GWT Contributors 
wrote:> 
> PS: pls avoid the urge to discuss technical stuff in steering commitee
> and try to keep it in the contributor list ;)
If we could get the monthly (weekly?) contrib calls going again so we
have someone to pick their brains, that would help a lot. Emails work,
but a lot of this is far faster to solve and pass around in bursty low-
latency discussion.
Make them 15 minutes, officially, and of folks have time to stick around
longer, great?
Alternatively, gitter.im/gwtproject/gwt is extremely active, and only
missing representation from google. LIkewise could schedule some time to
quickly discuss things.
Otherwise it all ends up in private IMs and hangouts, opaque to the rest
of the world. Of course, a cynic might suggest that this has been the
M.O. of gwt development even since the tool was open sourced... Do
notice how light on details the original email in this thread was (and
incorrect, too, based on the work Thomas and I have done since).

-- 
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/1507749348.1785788.1135633168.03C3AE58%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

Patch is accepted and merged into upstream HtmlUnit, see
https://sourceforge.net/p/htmlunit/bugs/1924/ for more detail.
Daniel, when you can take a look at Thomas's question, we can get this
change made to open source GWT as you requested.

-- 
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/1507651680.2148273.1134128816.6B394BE1%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: application compiles in 2.8 but does not run

[Colin Alworth]

I can report that at least as of 2.8.1, you get an exception if you specify 
an  that doesn't implement EntryPoint, but still has the 
correct public void onModuleLoad() signature. I didn't investigate too 
deeply, but the compiled output was something like null.onModuleLoad(), 
which indicated to me that it knew the right method to call, just wasn't 
willing to create the type.

-- 
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: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

Like we do for
com.google.gwt.junit.RunStyleHtmlUnit.HostedJavaScriptEngine so we can
hook in the "plugin". Looks like that idea might be a winner! Just make
sure to swap it in both cases, don't want to kill tests in old dev mode.

-- 
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/1507388064.2777465.1131047224.1BEFE507%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

Exactly - I wasn't planning on adding the javaToJs(), but was going to 
unwrap the exception before calling onerror (or have ScriptException 
implement Scriptable). Have a short test that demonstrates the issue 
without gwt (but wow they have a lot of GWT in their source tree), and am 
was waiting for my svn->git sync to finish to confirm what you did by hand. 
Just in case we decide to rebase it along, or make other improvements down 
the road...

-- 
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/46ee5450-a14f-4a0f-a4c9-302d5a4c1709%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

It was not my intention to get this into 2.8.2, but to wait for 2.9. If
we think it is important enough, I can look into it, but I figure we
have to draw the line somewhere...

-- 
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/1507316699.1518390.1130428640.1A4FAD8C%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

Okay, I'm about 80% sure that I understand and can remedy the problem 
within HtmlUnit itself. Will update once I finish syncing the apparently 
canonical SVN repo to git, so I can go over the history more carefully and 
ensure that this break isn't deliberate.

A question for my fellow GWT maintainers: should I patch the version of 
HtmlUnit that we presently use, so that we avoid breaking downstream 
expectations (plugins that specify specific browsers, use if IE8 or IE11 as 
a user agent to run the tests as)? Or should I see about getting this patch 
into the next version of HtmlUnit, and we wait on their release cycle, and 
leave this broken until then?

-- 
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/7647939e-7606-4697-84f7-da4f79f07aed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

[Colin Alworth]

Good news is that getting past the failed to start shell issue isn't that 
bad, mostly transitive dependency changes (man there are times I love 
maven, mostly when I'm not using it...), but also losing the ability to run 
tests in IE8, IE11. Not sure that is a great loss.

Bad news is that it doesn't help - the same errors still happen, the same 
tests still fail.

Patch from current HEAD and logs of failures in 
GWTTestCaseSetupTearDownTest (the only one I ran as a representative 
example) are attached if anyone wants to eyeball it quick, see if I did 
anything too dumb.

With that out of the way, I'll try to understand the root issue, see if I 
can't figure out what has changed in HtmlUnit that causes this. Failing 
that, I'll roll back to the older jetty/htmlunit, and hopefully that will 
jog something loose in my head.

-- 
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/4bd5c079-c06a-46ae-8f92-fdb89161dccd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Testsuite: com.google.gwt.junit.client.GWTTestCaseSetupTearDownTest
Tests run: 7, Failures: 3, Errors: 2, Skipped: 0, Time elapsed: 28.256 sec
- Standard Output ---
Logging initialized @1669ms
jetty-9.2.z-SNAPSHOT
Started 
c.g.g.j.@358ee631{/,file:/Users/colin/workspace/gwt/build/out/user/test/web-htmlunit/www/,AVAILABLE}{/Users/colin/workspace/gwt/build/out/user/test/web-htmlunit/www}
Started ServerConnector@2448bc21{HTTP/1.1}{0.0.0.0:64644}
Started @2300ms
warning: message=[RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object com.gargoylesoftware.htmlunit.ScriptException: 
junit.framework.AssertionFailedError: testSetUpTearDownFailAsync (script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)#346) of class com.gargoylesoftware.htmlunit.ScriptException 
where it expected String, Number, Boolean or Scriptable instance. Please check 
your code for missing Context.javaToJS() call.] sourceName=[script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)] line=[56] lineSource=[null] lineOffset=[0]
warning: message=[RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object com.gargoylesoftware.htmlunit.ScriptException: 
junit.framework.AssertionFailedError: testSetUpTearDownFailAsync (script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)#346) of class com.gargoylesoftware.htmlunit.ScriptException 
where it expected String, Number, Boolean or Scriptable instance. Please check 
your code for missing Context.javaToJS() call.] sourceName=[script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)] line=[25] lineSource=[null] lineOffset=[0]
warning: message=[RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object com.gargoylesoftware.htmlunit.ScriptException: 
junit.framework.AssertionFailedError: testSetUpTearDownFailAsync (script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)#346) of class com.gargoylesoftware.htmlunit.ScriptException 
where it expected String, Number, Boolean or Scriptable instance. Please check 
your code for missing Context.javaToJS() call.] sourceName=[script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)] line=[220] lineSource=[null] lineOffset=[0]
warning: message=[RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object com.gargoylesoftware.htmlunit.ScriptException: 
junit.framework.AssertionFailedError: testSetUpTearDownFailAsync (script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)#346) of class com.gargoylesoftware.htmlunit.ScriptException 
where it expected String, Number, Boolean or Scriptable instance. Please check 
your code for missing Context.javaToJS() call.] sourceName=[script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)] line=[63] lineSource=[null] lineOffset=[0]
runtimeError: message=[Java class 
"com.gargoylesoftware.htmlunit.ScriptException" has no public instance field or 
method named "__java$exception".] sourceName=[script in 
http://localhost:64644/com.google.gwt.junit.JUnit.JUnit/junit.html from (-1, 
-1) to (-1, -1)] line=[159] lineSource=[null] lineOffset=[0]
warning: message=[RHINO USAGE WARNING: Missed Context.javaToJS() conversion:
Rhino runtime detected object com.gargoylesof

Re: [gwt-contrib] Last call for GWT 2.8.2 patches, and testers needed!

[Colin Alworth]

Juan, you just signed up, thanks to you and Boris for being so
consistently helpful with GWT.

Anyone else can feel free to either reply to the list, or email me
personally.

-- 
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/1507036647.1515209.1126285264.127BA0AA%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Super slow compilation in projects with many wildcard generics

[Colin Alworth]

Seems like a good reason to defer to GWT 2.9.

On Mon, Oct 2, 2017, at 02:48 AM, Thomas Broyer wrote:
> Note that this means GWT will effectively require JDK 8 for
> development (gwt-servlet could possibly still work with 1.7, though at
> that point I'd push for 1.8 too)> 
> https://www.eclipse.org/projects/project-plan.php?planurl=
> http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_8.xml#appendix

-- 
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/1506931368.2852966.1124699816.6D50723D%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] NodeList and JsArrayList.asArray

[Colin Alworth]

Using GWT 2.8.1, I'm trying to iterate through items found via a query 
selector:

Arrays.asList(document.querySelectorAll("button.with-some-class").asArray
()).forEach(
item -> doSomething(item)
);

Unfortunately, this seems to always fail - querySelectorAll returns a 
NodeList, and while asArray() seems to specify Js.uncheckedCast, 
the resulting generated code is 

$forEach_1(new Arrays$ArrayList(*castToJsArray*(($clinit_DomGlobal() , 
document_0).querySelectorAll('button.with-some-class'))), new 
SampleClass$lambda$0$Type);

Predictable, the bolded castToJsArray causes an exception at runtime, since 
a NodeList isn't actually a JS Array at all.

Is there a correct way to do this, or perhaps a nicer way to iterate 
through NodeLists?

I assume this should be a bug filed against jsinterop-base, but am not 
seeing a repo for it, or is this a bug in GWT itself?

-- 
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/4764126b-ed92-409a-bb4b-d1d1fead2e3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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, <T, V[]>, <T[], V>,
<T[], V[]>, 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
> <vasv...@gmail.com> 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* <vasv...@gmail.com>
>> 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 <T, V> V[] extent(T[] data,
>>> AccessorFunction<T, V> accessor);
>> 
>> Where AccessorFunction is 
>> 
>>> @JsFunction
>>> public static interface AccessorFunction<T, V> {
>>> 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_2Lco

Re: [gwt-contrib] Fwd: Usage of file handles/file streams in GWT source code

[Colin Alworth]

I fixed a few of these once upon a time in 2.6 or so to deal with an fd
exhaustion issue on linux, would be willing to take on more. In that
case even in success they were leaking, as opposed to only causing
issues in cases of failures (more on this below).
If you have a list of cases that are used wrong (returning an
InputStream isn't necessarily bad of course, since the calling code
itself might have a try-with-resources), I can hit them and see what
falls out.
I'm not sure copying literally every InputStream you see into a
ByteArrayInputStream is a constructive suggestion, since of course to be
defensive, anything given an InputStream needs to make yet another copy,
or all of these APIs need to be adjusted to take ByteArrayInputStream,
etc as a parameter to be clear that the stream has been closed. Is there
another best practice that can make this cleaner, perhaps rewritting
something like the Response interface so it implements AutoClosable so
that _it_ can be try-with-resource'd?
Quickly reviewing all cases where Responses.newBinaryStreamResponse is
called (transitively), all usages either return right away (so no error
can happen), or com.google.gwt.dev.codeserver.WebServer#handleRequest
where yes, it is possible for a NPE or something could happen prior to
page-send (which then cleans up correctly in a try/finally), but that
would point to rather broken code. Response can't be null, target can't
be null, the logger really shouldn't throw and the response shouldn't be
able to throw in setHeader). Or is there something concerning in
handleRequest that you see which can surprisingly error out before
page.send(...) can be reached?
--
  Colin Alworth
  co...@colinalworth.com



On Mon, Jun 12, 2017, at 04:29 AM, Thomas Broyer wrote:
> Moving discussion to GWT Contrib.
> 
> On Sunday, June 11, 2017 at 9:35:30 PM UTC+2, mr.g...@gmail.com wrote:>> 
> Reading and writing of files should only be done using try-with-
>> resources. This might not be an issue on Linux, but it is a serious
>> issue on Windows where I repeatedly get conflicts with GWT DevMode
>> server not releasing file handles, ie. resulting in situations where
>> it cannot even read its own cache files.>> 
>> One example: Output.openSourceFile returns a file input stream.
>> SourceHandler.makeSourcePage then does>> 
>> return Responses.newBinaryStreamResponse("text/plain", pageBytes);
>> 
>> where it eventually might get closed if no error happens... and on
>> top of that the stream is kept open as long as the client wishes to
>> stall reading the response data.>> 
>> I suggest setting up a GWT-internal standard for handling file
>> resources. My recommendation would be to use try-with-resources and
>> processing a file copy that is stored fully in RAM.>> 
>> 
> 


> --
>  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/ec381da9-f031-4a37-940d-748c32a4b826%40googlegroups.com[1].>
>   For more options, visit https://groups.google.com/d/optout.


Links:

  1. 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/ec381da9-f031-4a37-940d-748c32a4b826%40googlegroups.com?utm_medium=email_source=footer

-- 
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/1497279445.1859930.1006679184.782BF228%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Java 9

[Colin Alworth]

Are there specific Java9 JRE classes that we should focus on to get into 
GWT?

Would making GWT support Java9 sources and running in a Java9 env cause 
backward incompatible changes that prevent GWT from running in Java8?

On Wednesday, June 7, 2017 at 2:56:46 PM UTC-5, James Nelson wrote:
>
> As I've mentioned elsewhere, 
> https://plus.google.com/+JamesNelsonX/posts/gBfpBDnwV9V , java 9 support 
> is entirely possible.
>
> When I last tried it out, it required a fair number of hacks, but it 
> worked fine.
> I expect the final version of java 9 modules to require slightly fewer 
> hacks,
> and for it to take a fair amount of time to properly refactor gwt jars 
> enough to be usable in java 9 systems.
>
> If you are in a rush to get java 9, you are going to have to roll up your 
> sleeves, hold your nose, and dive into the early-access bug-zone.
> I can get you jars that (can be made to) work, but are very likely to 
> change when integrated properly into Gwt
> (I did some unspeakable things to make it work the weekend I did it as my 
> project).
>
> If you are comfortable waiting until there is more official support, I 
> can't really tell you what Google is planning...
> I, however, will be releasing my fork w/ java 9 support when I am sure the 
> underlying module system is completely done changing;
> a few colleagues and I are considering opening a gwt-shop with support for 
> the 2.X line, and would handle this kind of stuff directly,
> however, it's still being done in my "spare" time, which is actually 
> supposed to be for building a new ui templating language for gwt,
> coming up with an javax.model replacement for gwt generators, and building 
> a social network to fix democracy...  hehe.
> "Sleep is the Cousin of Death" :D
>

-- 
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/ccb9b604-e8f7-498a-b1fe-f22fa8282dcf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8.1 release

[Colin Alworth]

I think you may be misremembering - the jars were released to maven as 
experimental last summer, then as beta in April, and only after that were 
they on github.

J2CL is not expected to be dropped until it is "ready", but as with 
elemental2, this isn't going to mean "bugfree" but more like "complete 
enough to be reviewed and used".

On Wednesday, June 7, 2017 at 1:10:37 PM UTC-5, Vassilis Virvilis wrote:
>
> Looks like they are also here in source form
>
> https://github.com/google/elemental2
> https://github.com/google/jsinterop-generator
>
> I thought google didn't want to release them before they were "ready". So 
> either they changed their mind, or they feel it is ready or I don't 
> remember correctly :-)
>
>  Vassilis
>
> On Wed, Jun 7, 2017 at 7:17 PM, Colin Alworth <nilo...@gmail.com 
> > wrote:
>
>> The groupId has changed - using the mvnrepository site, try 
>> https://mvnrepository.com/artifact/com.google.elemental2 to see all of 
>> the jars now available.
>>
>>
>> On Wednesday, June 7, 2017 at 11:14:33 AM UTC-5, Bruno Salmon wrote:
>>>
>>>
>>>
>>>> Additionally, this supports the recent beta release of jsinterop.base 
>>>> and elemental2, available from Maven Central.
>>>>
>>>>
>>>>
>>> Where can we find that elemental2  beta release (I can see only the June 
>>> 2016 version on that page 
>>> <https://mvnrepository.com/artifact/com.google.gwt/elemental2-experimental>
>>> )?
>>>
>>> Thanks for all your amazing work.
>>>
>>

-- 
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: GWT 2.8.1 release

[Colin Alworth]

The groupId has changed - using the mvnrepository site, try 
https://mvnrepository.com/artifact/com.google.elemental2 to see all of the 
jars now available.

On Wednesday, June 7, 2017 at 11:14:33 AM UTC-5, Bruno Salmon wrote:
>
>
>
>> Additionally, this supports the recent beta release of jsinterop.base and 
>> elemental2, available from Maven Central.
>>
>>
>>
> Where can we find that elemental2  beta release (I can see only the June 
> 2016 version on that page 
> 
> )?
>
> Thanks for all your amazing work.
>

-- 
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: [gwt-contrib] Re: Upgraded from GWT 2.6 to 2.8 - now Chrome Extension API doesn't work...

[Colin Alworth]

If it is the linker, going back to your 2.6 code and changing to the 
current xsiframe linker might show the bug - if so, you know it is related 
to the default linker change. If not, debugging your JSNI to see what the 
value of chrome is before and after the GWT version change will be helpful, 
or whatever the different wiring is (chrome.runtime.connect perhaps).

My guess (which is what Goktug is pointing to I think) is that you really 
should have all usages of chrome prefixed with "$wnd." so that there is no 
ambiguity about which object is being used, and which frame it is from.

If the above code is simple enough to demonstrate the issue, can you put a 
minimal project together so that we can reproduce the issue, including 
build instructions? Aside from that and the above suggestions (which is 
just rehashing of 
http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsJSNI.html and the 
earlier emails), we don't really have anything to go on...

On Wednesday, May 3, 2017 at 3:22:27 PM UTC-5, TimOnGmail wrote:
>
> On Wednesday, May 3, 2017 at 1:08:14 PM UTC-7, Goktug Gokdogan wrote:
>>
>> Maybe related to $wnd, but here we are basically shooting in the dark. 
>> You should debug your code and tell us where it behaves unexpectedly 
>> otherwise we cannot help much...
>>
>
> I have indeed debugged the code, and wasn't able to figure out what was 
> going on, which is why I posted this here. :-)
>
> What level of debugging are you hoping for?  The Chrome JavaScript APIs 
> are a bit obtuse to debug.
>
> The above example is pretty simple - I can send you a working example if 
> you like, a complete Eclipse project plus an example Chrome app to 
> demonstrate the issue.
>
> - Tim
>
>

-- 
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/cc64048c-d87b-43c4-b96d-39b147729dd6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Upgraded from GWT 2.6 to 2.8 - now Chrome Extension API doesn't work...

[Colin Alworth]

What had been the care previously? Were you calling the chrome methods in 
some way other than through JSNI? Java methods can't call raw JavaScript 
without JSNI (or JsInterop, which didn't exist in GWT 2.6). 
Otherwise I'm not sure what you changed it _from_ to get to the psuedocode 
in your post.

I'm not aware of breaking changes that should have happened (though it has 
been three years between the releases). It is possible that you were using 
JSNI in a way that probably shouldn't have worked previously, and since 
then it has been "fixed"?

On Monday, May 1, 2017 at 5:02:09 PM UTC-5, TimOnGmail wrote:
>
> So it appears that this is caused by JSNI methods somehow being morphed 
> when the GWT app is compiled.  I don't know how, but I do know that calls 
> to Chrome proprietary APIs aren't working correctly.  I modified my code to 
> do the following:
>
> Java method calls JSNI method
> JSNI method calls raw JavaScript method in base app loading page (a JSP 
> page)
>
> ... and it now works.  So the GWT compiler is doing something funny to 
> JSNI methods that cause the Chrome API calls not to work as expected.
>
> Anyone know what's happened there?
>
> - Tim
>
>

-- 
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/a47e43d7-22da-4bc5-8f47-0462ef235888%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] GWT 2.8.1 release

[Colin Alworth]

 

I'm very pleased to announce the release of GWT 2.8.1. This contains many 
bugfixes and a few enhancements to JsInterop.


Highlights from release notes:

   - 
   
   Elemental1's JSON parser now correctly throws an exception when a 
   string, object, or array is not correctly ended.
   - 
   
   Support filtering JsInterop types for export, with whitelist/blacklist 
   and wildcards. The -generateJsInteropExport flag is still used to enable 
   the feature, but -includeJsInteropExport and -excludeJsInteropExport now 
   exist to specify packages with optional * wildcards. Later arguments and 
   patterns override earlier ones.
   - 
   
   Support "*" (any) and "?" (unknown) types as a JsType native name. The 
   "Unknown" type can be preferred over Object if the type is unknown, while 
   "any" is preferred supertype of any JS type, including primitives.
   

Additionally, this supports the recent beta release of jsinterop.base and 
elemental2, available from Maven Central.


Please check out the full release notes 
, then 
download the release zip  or update your project to 
get version 2.8.1 from Maven Central.

-- 
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/1a96667b-6e36-400d-a329-da0680d7d320%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GWT 2.8.1 release

[Colin Alworth]

 

I'm very pleased to announce the release of GWT 2.8.1. This contains many 
bugfixes and a few enhancements to JsInterop.


Highlights from release notes:

   - 
   
   Elemental1's JSON parser now correctly throws an exception when a 
   string, object, or array is not correctly ended.
   - 
   
   Support filtering JsInterop types for export, with whitelist/blacklist 
   and wildcards. The -generateJsInteropExport flag is still used to enable 
   the feature, but -includeJsInteropExport and -excludeJsInteropExport now 
   exist to specify packages with optional * wildcards. Later arguments and 
   patterns override earlier ones.
   - 
   
   Support "*" (any) and "?" (unknown) types as a JsType native name. The 
   "Unknown" type can be preferred over Object if the type is unknown, while 
   "any" is preferred supertype of any JS type, including primitives.
   

Additionally, this supports the recent beta release of jsinterop.base and 
elemental2, available from Maven Central.


Please check out the full release notes 
, then 
download the release zip  or update your project to 
get version 2.8.1 from Maven Central.

-- 
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: Time to remove GWT-RPC from WebAppCreator sample app?

[Colin Alworth]

Dissenting opinion, mostly for the sake of discussion (though I'll admit to 
being an RPC fanboy too):

This came up in discussion in ##gwt today, from the other perspective - the 
stockwatcher app uses JsonpRequestBuilder, which is incompatible with 
JsType without some seriously fugly casts (as far as we could figure out), 
and hasn't been updated since GWT 1.6 was new.

I might almost take the other perspective - at least RPC (with or without 
@JsType annotations so the loaded objects could be used in external JS) 
will at least work in modernized gwt, but JsonpRequestBuilder requires some 
hoops to jump through to make sense. Anything talking about Element or 
other JSOs is likely to become confusing as well in the very near future, 
as JSO.cast() is bound to JSO subtypes, so you need to cast first to Object 
and then to the appropriate JsType. 

  JsArray results;//from JsonpRequestBuilder callback
  MyJsType instance = (MyJsType) (Object) results.get(0);//or a JSNI 
'cast', which also won't exist in GWT 3

In contrast (donning my asbestos suit...) RPC still works as-is today and 
doesn't have any serious GWT-compatible future-proof competition in terms 
of sending graphs of plain Java objects. There appears to be the risk that 
GWT 3 may not support the so-called "violator pattern", but until we have 
the ability to actually run the compiler, there is no guarantee of that - 
at worst, they can be @JsTyped so the field names won't be renamed... I 
think. A future APT-built set of serializers could walk getters/setters and 
provide the same graph serializer that RPC gets us today (and possibly even 
with less terrible errors...).

If we get rid of RPC docs and samples because Generators are on the way 
out, but replace with RequestBuilder or JsonpRequestBuilder, we're just 
trading one "it probably won't work in 3" for another. Plus, the same logic 
says references to Widgets/UiBinder/etc should be removed as well. If it's 
just for the "there is another way to do it", why be opinionated? I could 
see a disambiguation page to discuss the pros/cons (and relative 
future-proofness, or lack thereof), but outright removing seems... harsh. 

On the other hand, if we have tools (i.e. outside of gwt-user) that work 
with only jsinterop and APT, my points make a lot less sense, but I don't 
think we're there yet.

--

As replacement goes, I like AutoBeans for nearly the same reason as RPC - 
the server-side de/serialization is consistent, predictable, and supports 
Java conventions and apis. Alas, it has the same problems of being rooted 
in the past - JsoSplittable, generators. You can make JAX-RS methods work, 
but the surprise gotchas (server supports polymorphism but client doesn't? 
No easy primitive wrapping or enums? No Java collections, and odd behaviors 
in array instanceof? etc) seem like they would require both that the doc be 
opinionated on which server serialization tool is used, and provide the 
laundry list of things to watch out for. Personally I'd like to see a plan 
around a GWT 3 capable tool that addresses the entire experience before 
talking about removing RPC - and then take JSOs, JSONObject, AutoBean, 
RequestFactory, etc all out at the same time.

On Thursday, April 20, 2017 at 1:33:48 PM UTC-5, Thomas Broyer wrote:
>
> Should we start thinking about removing GWT-RPC from our sample app? (and 
> probably tutorial on the web site)
> What would we replace it with though? I'd suggest plain old HTTP with JSON 
> and JsInterop; but what about the server? Using HTTP POST with 
> manually-encoded application/x-www-form-urlencoded data and org.json (or 
> AutoBean?) to encode the response as JSON?
>

-- 
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/cd5dc7ed-fbe9-4944-9b94-a554093295fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] auto generation of jsinterop from .d.ts

[Colin Alworth]

Is the current plan to open source the experimental part as well? I suspect 
there are people on this list who would be very interested in helping to 
continue that effort.

On Tuesday, April 18, 2017 at 6:52:57 PM UTC-5, Julien Dramaix wrote:
>
> We are working internally on a jsinterop generator that can take closure 
> extern files and d.ts files as input.
> For the time being only the closure part works fine and we use it to 
> generate elemental. We are in the process to opensource it. The d.ts part 
> was an experiment and doesn't work (yet) with the last changes in 
> typescript compiler and need still some work. Unfortunately, it's not our 
> first priority right now and I cannot give you any timeline.
>
>
>
> On Thu, Feb 16, 2017 at 8:44 AM Joshb  
> wrote:
>
>> Hi All,
>>
>> I had seem some conversations a while back about potentially being able 
>> to generate interfaces directly from a typescript definition file.  Did 
>> anything ever come of this?  I have a library I would very much like to get 
>> hooked into GWT and there is a typescript file.  It is quite large, and 
>> this would save a ton of time.  Thanks in advance!
>>
>>
>> -- 
>> 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/68267db6-c9b9-4acb-8499-b92b37a5263d%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/4bdea408-3421-4d37-b4f9-1273a9c490d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] GWT 2.8.1 release testers required!

[Colin Alworth]

We're about ready to release GWT 2.8.1, a bugfix release a variety of 
issues, including getting a stable release out that works with the new 
jsinterop.base and elemental2 beta jars. I will need some help in 
validating this release on our supported platforms, please contact me if 
you are available to spend a little time testing over the next few days, 
and I'll get the ball rolling.

Thanks,
Colin

-- 
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/350e53ba-2148-497c-8d58-eeb9528b7b6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: 2.8.x release

[Colin Alworth]

Yes, there is a plan to do a release - this is in part my fault for failing 
to communicate this correctly (by way of steering committee meeting notes). 

We are waiting on a few patches before we can start the testing process and 
get the release under way.

On Friday, March 17, 2017 at 9:13:09 AM UTC-5, Paul Stockley wrote:
>
> Are there any plans to put out a 2.8.1 release? I see there have been a 
> number of fixes/enhancements since the initial 2.8 release.
>

-- 
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/53aa7da8-9751-4963-8220-9a7c1bdf9793%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: float[] is super slow

[Colin Alworth]

There are other problems too, like supporting object instanceof float[] (or 
even instanceof Object), not that you likely do a lot of things like that. 
I had a patch once upon a time that would let you optionally use typed 
arrays _or_ js lists as primitive arrays (except longs of course), but it 
added small runtime costs in odd places, so was turned down (outside of the 
code review, separate discussion).

The patch is old and stale, but its possible you could do something with 
it, at least for a personal gwt branch. 
https://gwt-review.googlesource.com/#/c/8321/

There is another option too, depending on how this data looks in your array 
- consider java.nio.FloatBuffer. GWT can get support for it from PlayN 
(backed by js typedarrays, as you would expect), I have experience with it 
and have found you can get pretty amazing performance using it). This is 
still cross platform, won't mess with instanceof, only downside is that 
you'll have to do some not-so-cross platform stuff to interact with the 
typedarray side if you need (serializing, writing to canvas, etc). If you 
need more info, let me know, I have a few projects that use it. PlayN is 
still moving forward, just released their 2.0-rc4, and I've found that the 
buffer impls all behave as expected still.

On Monday, February 6, 2017 at 6:09:33 AM UTC-6, Jens wrote:
>
>
> The reason I'm asking is because Super-source solution can not change all 
>> "new int[...]" invocations in my program. 
>> As far as I understand, the SS solution can change some ArrayFactory and 
>> each time I need to use it I have to write ArrayFactory.createFloatArray. 
>> "new float[]" will not be altered with souper-source.   
>>
>> Am I right ?
>>
>
> yes you would need a factory with super source so you can change the way 
> the array is created.
>
> -- 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.

[gwt-contrib] Re: Size of output is little large

[Colin Alworth]

Without actually compiling the code (see my final paragraph...), you
might not even need the safari permutation, but might get by with no
UserAgent wiring at all. You could experiment with your inherits
statements, and see if you can remove User, and only depend on
com.google.gwt.core.Core from the main portion of GWT itself. This at
least will remove the user agent parser (which is there to confirm that
you aren't accidentally running the safari permutation in IE, for
example). Alternatively, you can disable that runtime check:

   

If you go this route, also consider disabling the document mode check,
another piece of GWT sanity check that happens on startup:

  

--

Your code looks like it might be a stripped down version of something
more interesting that you will write later, but if it turns out that you
will be keeping it that simple, consider turning off stack trace
emulation. It doesn't actually *_entirely_* remove the stack trace
collection code (I'm actually already looking into how to fix this), but
it does minimize what is needed for your app to turn on. The three
values are native, emulated, and strip: native assumes that browser
provides some ways to read the stack already, emulated bakes in a ton of
extra debug information into your compiled sources, and both of them
review and attach that information to java Exceptions. Strip, on the
other hand, does nothing except fill the collector-shaped hole so that
the rest of GWT believes everything is working correctly:

  

--

Much of what remains is various Java emulation for types (including some
which are incorrectly not pruned, like ClassCastException in an app
which can't throw such an exception). There isn't a lot in 2.8 that can
be done to remove that code, but for any code more interesting than
creating a single object and attaching it to the window it will be
required to behave like proper Java.

--

After compiling a trivial GWT app (native window.alert from entrypoint)
I don't get any code adding a window listener. I also am not seeing
JsGlobals.getWindow() anywhere in either 2.8 elemental nor
elemental2-experimental 16-06-30. Where is that coming from, and is
there any chance that it has static setup code that wires up the
listener?


On Monday, December 12, 2016 at 10:02:03 AM UTC-6, Kirill Prazdnikov wrote:
>
> Hi, 
>
> I have a simple GWT program:
> https://gist.github.com/kirillp/c443966b28ca68cd21e51ff802fde97d
>
> And it compiles and run. 
> However, in single permutation "safari" and SSO linker it produce about 
> 1100 lines of (auto-formatted) code including
>   user agent parser, adds a window listener, e.t.c 
>
> How can I reduce things I don't need  ?
>
> Thanks
>
>

-- 
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/6de95c20-705b-4267-bc6c-60f129fd9151%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] dead classes and docs

[Colin Alworth]

As previously mentioned, I'm walking over a lot of old GWT and playing with 
some ideas around structure changes. Along the way, I've found some 
apparently dead classes, and some very rotten docs.

For example, at the root of each zip release including 2.8.0, we have 
about.html, which proudly states that GWT's copyright is as of 2009, the 
project is called Google Web Toolkit, and makes note of a few dependencies 
like jetty 6 and mozilla 1.7. The file about.txt is a plain text version of 
the same. COPYING and COPYING.html list the license for the project itself, 
and then go on to list licenses for projects distributed with GWT which 
again, is not at all up to date. Both html files link 
to http://code.google.com/p/google-web-toolkit/ (though at least one of 
them shows off a strict doctype). They've been edited apparently by hand a 
few times since 2009, but inconsistently. If we have legal reasons to keep 
these up to date, we should probably be somewhat more aggressive about 
this, or else remove the inaccurate portions or the files entirely.

The 'doc' subdirectory within the project also contains some treasures, and 
haven't been modified since 2009 or so either (and still reference Google 
prominently). At least these are entirely dead and no longer among us - as 
far as I can tell, they are not used in the final zip at all. It *appears* that 
these assumed that the doclet code (see build_tools/doctool/ I think?) 
would visit these files and update them, as there are html files with @link 
references in them, but to classes that were removed as "obsolete 
documentation" again in 2009.

Along similar lines, there is a directory "helpInfo" inside of doc which 
contains some very short but informative snippets of html, describing some 
features and their gotchas within GWT. These likely all either have a place 
at gwtproject.org already, or are out of date and should be removed. These 
are _also_ shipped in the release zip, despite inaccuracies or extremely 
outdated details.

The doclet generating code _is_ apparently used, mostly for including 
example sources. It also includes a few things I can't entirely work out, 
and suspect aren't useful, but are still used. For example, there is a 
target in doc called "emul-ezt" which runs com.google.doctool.JreDocTool. 
One of the flags is "-out ${project.build}/emul-ezt/fragment.html", which I 
assume means that after this target finishes, there should be a file called 
fragment.html somewhere, but I have yet to find it even when running that 
target directly. There is also a DocTool class in the same package, which 
doesn't appear to be used at all. Removing these classes and the 
corresponding target also results in a fair bit less logspam of the variety 
"(use -source 8 or higher to enable default methods)" and "(use -source 7 
or higher to enable diamond operator)", since apparently this tool/target 
was never updated beyond Java 6 or so.

I'm less certain about this one: the root directory "jni" appears to 
contain wiring for the old "Hosted Mode" that predated our now-deprecated 
Dev Mode. It was apparently all deleted once, in 2009, but quickly restored 
when it was found that some of the native wiring was required for 
windows/IE to correctly perform update checks. The other platforms likely 
do not need this code any more though, right? And can someone confirm that 
update checks are disabled by default anyway? 
CompilerOptionsImpl.isUpdateCheckDisabled returns true unconditionally, 
and ArgHandlerDisableUpdateCheck at least appears to default to disabling 
the check, and further marks this flag as experimental, suggesting we can 
safely remove it?

Finally, a few dead classes in gwt-dev that have no references to them, and 
deleting them seems 
clean: ServletContextTreeLogger, WorkDirs, ArgHandlerLink, 
ArgHandlerLibraries, ArgHandlerOutDir, 
ArgHandlerOutputLibrary, CloseableJarHandlerFactory 
and CloseableJarHandler. None of these are referenced directly, nor by name 
in any String in the codebase - is there a reason to not outright remove 
them, since they are within the compiler itself?

-- 
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/3523772f-fbe4-4299-9fd5-1d0c39bbf2e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with GWT 2.8

[Colin Alworth]

At least it is inconsistent with what the JVM would do, and appears to be 
different from what was seen in earlier versions of GWT. Can you file this 
at github.com/gwtproject/gwt/issues?

On Sunday, November 20, 2016 at 5:35:44 PM UTC-6, Kevin Langille wrote:
>
> Thanks for the reply.
>
> Compiling with pretty shows the issue.
>
> if (!(Math.abs(x - y) < 0.0001))
>
> gets turned into
>
> if (Math.abs(x - y) >= 0.0001)
>
> So when Math.abs(x - y) results in NaN the if always results in false.
>
> In my mind this is a mistake because it doesn't accurately represent what 
> is happening in Java. Is it enough to report it here or what should I do 
> now?
>

-- 
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] Utils

[Colin Alworth]

I've spent a little time over the last week trying again to tease apart GWT 
into smaller modules and working out dependencies between them. This is in 
part to see about a not-ant build system, and in part to see why a minimal 
GWT app is surprisingly big. The target here isn't the user lib, but the 
compiler and associated other pieces that are all compiled together: 
emulation, internal annotations, the generator/linker api, commandline 
tools, testing infrastructure, etc.

Along the way, the biggest snarl I've run into so far is Util, and its 
siblings, Utility and StringUtils. "A smattering of useful methods" indeed.

Utility has the benefit of depending on very little outside the JRE, but 
gets used all over the place (in Util, the compiler, dev mode, linkers, 
generators, command-line tools...) - not such a big deal by itself, just 
need to make sure it is in one of the core modules so that everything else 
can lean on it. StringUtils likewise depends on nothing and is used all 
over with one additional usecase: servlets.

Util on the other hand depends on the generator types 
(treelogger, UnableToCompleteException), on SpeedTracer (what is the status 
of SpeedTracer these days?), and on the org.w3c.dom library. It also gets 
used pretty much everywhere, which adds transitive dependencies to the 
above: the compiler, dev mode, generators, linkers, command line tools. It 
also has this confusing Javadoc:

> Methods in this class are candidates for being moved to {@link 
com.google.gwt.util.tools.Utility} if they would be generally useful to 
tool writers, and don't involve TreeLogger.

Only six methods (out of dozens) take either the logger or throw that 
UnableToCompleteException

I'd tend to say that all generators shouldn't depend on org.w3c.dom or 
SpeedTracer to be on their classpath just to compile including any 
ResourceGenerator for ClientBundle (and yes, admittedly, Generators and 
Linkers are going away when GWT3 starts showing up, but until then...), the 
Link.main() likely doesn't need to depend on generators, etc.

To that end, I'm looking at teasing apart some of these into distinct 
classes, purpose-built for where they are used, and only with the 
dependencies they need. Any objections to this that would prevent it 
getting merged into master?

It is just over 1000 lines long (plus another 350 for Utility), and the 
first cut appears to be taking out org.w3c.dom. This slices out just over 
10%, and at no real cost that I've noticed yet - all the methods were 
private, and at least ant dist-dev passes without them, I'll be running a 
longer build soon.

Thoughts?

-- 
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/617fd0e4-1604-458e-88fe-da686ab6d31d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: About a proposed to change to SafeHtml's UriUtils

[Colin Alworth]

I agree entirely, just trying to see this as a potential contributor with 
its associated steep learning curve, and address the question of "Should we 
stop adding new features?".

we're rather in a situation of "I'd like to add this new feature to GWT; 
> and this is something I could do in my own code"


If (and I stress *if*) we are prepared to stop accepting features requests 
*that 
come with technically correct code*, we should not make that decision 
lightly. There is little doubt that this would be an improvement to GWT, 
and something that generally would make GWT apps better - why should we not 
take it?

My (and your) alternative of using an external safe-* project adds 
boilerplate for using gwt-user features that are considered up-to-date and 
well supported. That is the main basis for my +1, that it isn't sufficient 
to say "well, if you want this browser API, which could be easily supported 
out of the box, here are the hoops you jump through". Find/Replace all use 
of UriUtils leads to prefixed MyCompanyUriUtils for each class in the GWT 
that could/should be better, and does make updating harder, or encourages 
forked copies of GWT which then can be difficult to rebase and keep up to 
date. 

In contrast, transforming a user into a contributor, even if only a 
fraction of them stay with us long term, improves the overall health of the 
project.

The one technical objection I see is that including Collections.emptySet() 
and its transitive tree might add some weight for small projects that avoid 
*any* java collections. String[] might be preferred, but with a minor 
runtime cost last I checked. 

If it is a technically bad patch (style, increases compile time/size in an 
unacceptable way, insufficiently tested/documented, insecure, etc), it 
should be rejected. If it *could* be done in user code (and just about any 
feature request *could* be done), this probably isn't enough to reject it, 
unless we think it is a fringe case which other users are unlikely to avail 
themselves of. But if it improves the sdk in a way that will benefit users, 
and make it clear that GWT is in it for the long haul, improving every 
release, and open to developer contributions? Why should we stand in the 
way of that?

(Again, mostly devil's advocate, trying to address the huge number of 
concerns we've had over the last year or four of "contributing to GWT is 
too hard" or "GWT doesn't move forward and stay current with modern APIs". 
This is a token changeset to address this, and probably not perfect to 
demonstrate these thoughts, but I just wanted to make the point that we 
will be sending a message *whichever direction we take* with this 
changeset.)

-- 
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/39713959-c162-47af-b6d3-803e9c5fe736%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: About a proposed to change to SafeHtml's UriUtils

[Colin Alworth]

With 3.0 on the horizon, we've promised consistency of a sort in 2.x, and 
without 3.0 actually in sight, 2.x is going to need to see active 
development. Encouraging a third generation of url tools is not a bad 
thing, but only switching over half-way leaves something to be desired.

I'll play devil's advocate a bit - I'm not addressing the patch 
specifically (since I haven't fully read all of it or the discussion around 
it, and if it was a bad patch, I'm sure it would have been shot down on its 
own merits) but the thinking to use around what goes into the 2.x branch:
 * (point 1) We're not ready for maintenance mode, at least until we have 
timelines and completed APIs for GWT 3. If we are, we should be forbidding 
all merge requests to gwt-user that don't fix critical bugs. 

 * (point 2 and 3) Can't argue with new tools arriving that solve the 
problem better, especially if they are going into 3 as a cross-platform way 
of solving the problem (gwt/java/j2cl). Obvious caveat here (even for the 
devil's advocate) that with the release of 3, breaking changes off of 2 are 
acceptable and expected.

 * (point 4) Without transitioning the existing GWT Safe* tools, 
SafeHtmlTemplates is stuck in the past, as is UiBinder, I18n Messages, and 
any HasSafeHtml widget (both in GWT and in the general ecosystem). This is 
a lot to leave behind in the name of "but the tool didn't belong in GWT in 
the first place". We've had our chance to properly deprecate it for the 2.8 
release, and if our past timelines are any measure, it is going to be at 
least a year before we finally ship a release with SafeHtml, and all that 
use it, deprecated. And once we've reached that point, unless gwt-user 
depends on (or rebases, etc) safe-html-types or any other successor, all of 
the above downstream classes which use SafeHtml are left effectively broken 
(not unlike the unported Generators and Linkers we have today). 

Obviously ClientBundle/GssResource isn't actually deprecated, but we have 
officially said that new tools should not use the features that it takes 
advantage of. SafeHtml takes this a step further - GssResource got several 
upgrades within the 2.8 release (unlike other generators), despite it being 
deprecated, but with SafeHtml going out, it takes out features within many 
GWT Widgets themselves. There will be no officially supported way to 
correctly assign safe html content into an HTML widget.

Now yes, a bit of hyperbole there - you can of course (as Thomas noted in 
his email) simply asString() the not-gwt SafeHtml and use it, or provide 
your own wrapper, but depending on your project size (and GWT users out 
there have some big ones) that could be hundreds or thousands of sites to 
fix in code. Yet another change would be needed for any widgets that the 
project has which implement HasSafeHtml (so it can still be used in 
UiBinder), UiBinder @UiFields or getters (which return SafeUri for use in 
its embedded SafeHtml handling), Messages (to wrap any incoming url). This 
ignores any use of Messages/Constants in a SafeHtml-using uibinder itself - 
I'm not seeing a clear path there without the use of default methods in 
I18n interfaces (which admittedly, would probably work, but isn't going to 
be pretty).

---

Speaking for myself again, I am not prepared to outright "-2" any 
contribution to gwt-user that isn't a fix for a critical bug. I don't think 
we're ready today to deprecate everything inside of gwt-user that isn't JRE 
emulation or jsinterop-based. Ideally of course aspects of GWT will be spun 
out as community projects and maintained separately, but until we pull it 
off (or even start), any new GWT user will assume that anything in gwt-user 
is the best basis for a GWT project. Actively abandoning most of gwt-user 
is not going to help the already difficult situation we're in there.

-- 
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/63659db1-99a4-45d7-b83a-e20f8d78a63b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: ScriptInjector seems to be broken (2.8-SNAPSHOT)

[Colin Alworth]

Another issue at may warrant attention -
https://github.com/gwtproject/gwt/issues/9424. This was brought up some
time ago, but wasn't reduced to be reproducible until now (which is funny,
given how minimal the test case is).

On Fri, Sep 9, 2016 at 9:30 AM 'Daniel Kurka' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> +Goktug Gokdogan  +Roberto Lublinerman
>   Should we be holding RC3, I guess so right?
>
> On Fri, Sep 9, 2016 at 4:12 PM Jens  wrote:
>
>>
>> Can you file an issue and ping Daniel (by mail or hangout) to delay the
>>> RC3 a bit? (if not already too late, as it's 4pm cest)
>>>
>>
>> Done.
>>
>> --
>> 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/6386bb88-f488-4144-b830-99ddb387b677%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/CALLujirOwMPQTKzDuJtmtF0hF2bXVr%3Dij-V240vzP6Bh5SMRAA%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/CADcXZMz0S2wLjhN%2BKuTs4F84kUfnNHtqkDiKeJtjbqUf_piOhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Missing JsInterop 1.0.0-SNAPSHOT

[Colin Alworth]

Looks like somehow the JsInterop jars are missing from the google-snapshots 
repo now, making it difficult to use the latest nightlies.

http://build.gwtproject.org/job/gwt/615/console shows creating, signing, 
and deploying:
Signing and Deploying ./poms/jsinterop/pom.xml to 
https://oss.sonatype.org/content/repositories/google-snapshots/
Uploading: 
https://oss.sonatype.org/content/repositories/google-snapshots//com/google/jsinterop/jsinterop/1.0.0-SNAPSHOT/jsinterop-1.0.0-20160905.055744-4.pom
1/1K
1K uploaded  (jsinterop-1.0.0-20160905.055744-4.pom)
Signing and Deploying 
/tmp/random-dir-2498515708877027498/gwt-2.8.0-SNAPSHOT/jsinterop-annotations.jar
 
to https://oss.sonatype.org/content/repositories/google-snapshots/
Uploading: 
https://oss.sonatype.org/content/repositories/google-snapshots//com/google/jsinterop/jsinterop-annotations/1.0.0-SNAPSHOT/jsinterop-annotations-1.0.0-20160905.055746-4.jar
3/3K
3K uploaded  (jsinterop-annotations-1.0.0-20160905.055746-4.jar)
Uploading: 
https://oss.sonatype.org/content/repositories/google-snapshots//com/google/jsinterop/jsinterop-annotations/1.0.0-SNAPSHOT/jsinterop-annotations-1.0.0-20160905.055746-4-sources.jar
4/8K
8/8K
8/8K
8K uploaded  (jsinterop-annotations-1.0.0-20160905.055746-4-sources.jar)
Uploading: 
https://oss.sonatype.org/content/repositories/google-snapshots//com/google/jsinterop/jsinterop-annotations/1.0.0-SNAPSHOT/jsinterop-annotations-1.0.0-20160905.055746-4-javadoc.jar
607/607b
607b uploaded  (jsinterop-annotations-1.0.0-20160905.055746-4-javadoc.jar)



But the jars can't be found in maven 
https://oss.sonatype.org/content/repositories/google-snapshots/com/google/jsinterop/jsinterop/,
 
and the latest bom depends on 
it 
https://oss.sonatype.org/content/repositories/google-snapshots/com/google/gwt/gwt/2.8.0-SNAPSHOT/gwt-2.8.0-20160905.055656-339.pom


  com.google.jsinterop
  jsinterop
  1.0.0-SNAPSHOT
  pom
  import




Oddly enough, there is a 1.0.0.j7-SNAPSHOT, apparently generated and 
deployed from http://build.gwtproject.org/job/gwt-java7/, but unless you 
happen to use GWT 2.8.0.j7-SNAPSHOT, this isn't terribly useful.

Any ideas how this might have disappeared (as well as all old versions), 
despite apparently being deployed fresh about 12 hrs ago?

-- 
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/a2e03a76-0b7d-444e-84e0-1ab7542f1fa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Problem with JsInterop

[Colin Alworth]

Part of the problem would come from figuring out how to call from JS back
into Java - if you called resolve(null), was null a T or was null a
Promise? And from JS, how could you typecheck to figure out whether to call
the resolve_1(value) or resolve_2(promise)?

Its also possible in JS to call with too many arguments, and if you call
with not enough, they get a null value, so we'll have a resolve_0() in
there too - but if the wrong number of arguments are there, which do you
invoke?

So, rather than JsInterop being a method lookup layer to translate to Java
method call semantics, JsInterop uses JS semantics and lets you use them
from Java. Just as you would write your resolve method in JS, you should
write it in Java - take the object, and based on the value, decide what to
do with it.

Now I realize that this doesn't directly apply to your case, since you want
to do it the other way around - pass an object implemented in JS into Java
and interact with it there, but JsInterop provides functionality to work in
both directions, and I'm not certain how you could tell JsInterop that you
will never implement an interface in Java, or if that is functionality that
we want. Instead, you could have a single method resolve(Object), and let
JS sort it out, whether you call it with null, a value, or another promise.

(Disclaimer, I'm not a JsInterop expect, but I'm trying to learn quickly.)

On Sat, Aug 27, 2016 at 8:51 AM 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 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/15705e1b-c1cf-46ec-add7-96d2b787f8fe%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/CADcXZMxQAj-TExK50id9AVKB36mWv8JnAW5f%2BK0Zg4%3D9SOi74A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Last call for GWT 2.8.0 RC2

[Colin Alworth]

Kay, can you offer a reproducible example of this, and confirm that you
have no older copy of GWT (like gwt-user/gwt-dev from 2.8.0-beta1) on your
classpath? To test this, I just built some quick autobeans in a simple
project (so that I didn't need a full server to back it):

public DefaultMethodInGeneratorTest implements EntryPoint {
@Override
public void onModuleLoad() {
ABF abf = GWT.create(ABF.class);
abf.bean().as().buildName();
}

public interface ABF extends AutoBeanFactory {
AutoBean bean();
}


public interface SampleBean {
String getFirstName();
String getLastName();
default String buildName() {
return getLastName() + ", " + getFirstName();
}
}
}

This compiles correctly (for me, with 2.8.0-RC1), even though in prior GWT
versions you would need to list buildName() as a @Category.

On Wed, Aug 10, 2016 at 3:13 AM Jens  wrote:

>
> If you feel strongly that something should make RC2 please raise this on
>> this thread. I will be cutting RC2 tomorrow PST time.
>>
>
> To avoid incorrect warnings:
> https://gwt-review.googlesource.com/#/c/16540/
>
> --
> 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/0f8eca73-e432-4074-bb26-019f12b724a3%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/CADcXZMw9aDobHGhgpS9-_Rv%3DU%3DjBqqH00LiQRnPpO943GfFMaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Bean Validation

[Colin Alworth]

What maven repo has the SNAPSHOT in it?

Is https://github.com/ManfredTremmel/gwt-bean-validators the source for
this? Great work, looking forward to putting this to use, and porting it to
annotation processors for long-term GWT support!

I'm working with Frank Hossfeld on porting Editors to APT as well, perhaps
we can work together to provide the extra functionality you require to be
exposed from drivers.

On Thu, Aug 4, 2016 at 9:12 AM ManfredTremmel 
wrote:

> For your information, I've just commited a new gwt-bean-validators
> snapshot, it now:
>
>
>- includes complete validation implementation (ported from gwt
>implementation, so if it'll be removed from gwt it should still work)
>- switched validation-api from 1.0.0.GA to 1.1.0.Final
>- switched hibernate-validator from 4.1.0.Final to 5.2.4.Final
>- reworked validation implementation to work together with new api
>- added some gwt implementations of incompatible
>hibernate-validator 5.2.4 validation routines
>
> It's not ready to release, but if anybody is interested in testing, it can
> be done now. I've also uploaded to maven repository:
>
>
> What to do to let a project use it?
>
>
>
>1. Add the maven dependency:
>
>de.knightsoft-net
>gwt-bean-validators
>0.19.0-SNAPSHOT
>
>
>2. Add/Replace versions in maven configurations of validation-api
>to 1.1.0.Final and hibernate-validator to 5.2.4.Final
>3. In the *.gwt.xml Configuration, replace
>
>
>with
>
>
>4. Replace "com.google.gwt.validation" with
>"de.knightsoftnet.validators" in the project
>
> I've build with gwt 2.7.0, also tested with 2.8.0-rc1 and all my 235
> gwt-unit-tests have passed.
>
> --
> 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/ffe8a4b9-fb83-4f38-94d5-2fcb63b026e8%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/CADcXZMwCJHF_cqCP23_X5RKv1DQ37N0RZ8bs4iidXVEQNZhu4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Adding @JsFunction to java.util.function JRE Emulation?

[Colin Alworth]

No, its not a solution, so much as a "here is a workaround that might
satisfy your specific case as you build your JsInterop-based lib so that it
looks like it can use @FunctionalInterface types". I do not believe it to
be a comprehensive way to provide the feature requested. At some point I'll
try to write it out in more detail in case there is any actual merit to it
(I'm all but sure that there isn't, or you would have thought of it
already).

On Wed, May 11, 2016 at 7:47 PM 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> We cannot impose @JsFunction restrictions on standard library
> @FunctionInterfaces. You can see some of the limitations in the Javadoc.
>
> @Colin: I didn't understand your solution. Feel free to propose something
> more concrete and we can discuss over that.
>
> On Wed, May 11, 2016 at 4:22 PM, Colin Alworth <niloc...@gmail.com> wrote:
>
>> Unfortunately, you can't add the annotation to an interface with more
>> than one method, even if those methods are default methods, at least as it
>> is currently implemented.
>>
>> I can't remember the exact specifics around why this is the case, but
>> believe it has to do with handling functions passed from js into java, and
>> not being able to nicely handle instances that decide to override those
>> other methods as well.
>>
>> You could nearly achieve this effect by just making a method reference to
>> the "apply" or "test" method, and passing that as an actual JsFunction
>> type. I don't right away see a problem with syntactic sugar doing this
>> automatically, but am sure that someone will be able to enlighten us as to
>> what confusing side effects this might have (or alternately confirm that
>> this is a great idea, and point to where in the compiler the changes need
>> to be made).
>>
>>
>> On Wed, May 11, 2016, 6:15 PM David Becker <david.bec...@sencha.com>
>> wrote:
>>
>>> I think it would be good to add @JsFunction to all of the
>>> java.util.function interfaces in the JRE Emulation so that we can use
>>> standard function signatures with JsInterop.
>>>
>>> Would that work?  Any drawbacks?
>>>
>>> If you think that's a good idea, I can submit a patch.
>>>
>>> Thanks!
>>>
>>> --
>>> 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/13df9bed-108f-4cdf-8c00-123f1186e461%40googlegroups.com
>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/13df9bed-108f-4cdf-8c00-123f1186e461%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> 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/CADcXZMzaxRmFrvZUkQMG0VQETyJo5TWmjtFqPsn3msrBBvvLGg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMzaxRmFrvZUkQMG0VQETyJo5TWmjtFqPsn3msrBBvvLGg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>
>
>> 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%3DyUA0CktOO8rpggbAcfPyTPhP7bp3fOTZgxSZiWyGq09waBw%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0CktOO8rpggbAcfPyTPhP7bp3fOTZgxSZiWyGq09waBw%40mail.gmail.com?utm_medium=email_source=footer>
> .
> 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/CADcXZMwvRokmP5nq84jmE40Dmos3eMmPDH-V4RcCz-%2BjbubvxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Adding @JsFunction to java.util.function JRE Emulation?

[Colin Alworth]

Unfortunately, you can't add the annotation to an interface with more than
one method, even if those methods are default methods, at least as it is
currently implemented.

I can't remember the exact specifics around why this is the case, but
believe it has to do with handling functions passed from js into java, and
not being able to nicely handle instances that decide to override those
other methods as well.

You could nearly achieve this effect by just making a method reference to
the "apply" or "test" method, and passing that as an actual JsFunction
type. I don't right away see a problem with syntactic sugar doing this
automatically, but am sure that someone will be able to enlighten us as to
what confusing side effects this might have (or alternately confirm that
this is a great idea, and point to where in the compiler the changes need
to be made).

On Wed, May 11, 2016, 6:15 PM David Becker  wrote:

> I think it would be good to add @JsFunction to all of the
> java.util.function interfaces in the JRE Emulation so that we can use
> standard function signatures with JsInterop.
>
> Would that work?  Any drawbacks?
>
> If you think that's a good idea, I can submit a patch.
>
> Thanks!
>
> --
> 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/13df9bed-108f-4cdf-8c00-123f1186e461%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/CADcXZMzaxRmFrvZUkQMG0VQETyJo5TWmjtFqPsn3msrBBvvLGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Generator and Linker maintenance and changes

[Colin Alworth]

Thanks everyone. Since we don't really have much of a consensus on this, 
perhaps we can take some middle ground here?

I certainly agree that we want people to move away from generators in 
general, though without finished solutions for some of the tricks 
generators can do, this will be tricky. Additionally, APT is not exactly a 
terribly user-friendly option - while I have managed to port a very small 
GWT generator, I wasn't enjoying myself, and am unsure how a larger project 
would be addressed and sanity retained. I have heard great things about 
JavaPoet, but have not yet had the time to learn enough of it to make 
another attempt.

Neither, apparently, has anyone else - AutoBeans/RequestFactionr, I18n, 
UiBinder, ClientBundle, and even the base UserAgent wiring are all 
generator-based - in fact, my SafeHtmlTemplates 
 generator is the only 
one that I'm aware of that has been ported, at least publicly. If weren't 
not prepared to set an example on how to generally solve this, I'm unsure 
how strong of a position we can hold. 

Along the same lines, I agree that official work toward generators doesn't 
make any sense, and that instead work generally should be directed toward 
general solutions to our property/permutation and linker problems (features 
which will vanish with APT and J2CL as far as I can tell, with nothing yet 
set up to replace them). I'll generally agree that we should stop updating 
GWT-provided generators, though we certainly haven't yet stopped - over the 
past 12 months at a very brief glance at history, Thomas made changes in a 
year ago and in October, Julien made changes in June, October, December, I 
made changes in Feb. Some of these were purely bug-fixes, but about half of 
the changes actually appear to be introducing new features. It doesn't 
appear to be our position that further enhancing generators is contrary to 
our message.

My proposal is that first, the change I've submitted only removes unneeded 
(and arguably broken/meaningless) code - I don't see a position where it 
makes sense to keep it and refuse the patch.

Second, future work can be discussed, but actively forbidding contributions 
for fixing or improving existing code would require deprecating these 
classes and aiming to have them moved to their own jars, perhaps to be 
maintained externally. As opposed to my first point, I can see some wiggle 
room in this policy, but refusing changes merely because they improve a 
generator seems silly at best, especially when we have actively improved 
existing generators up until now. (Most of the examples I can come up with 
are pretty gratuitous and don't really make sense, but static or default 
methods in place of categories seems a natural fit for a hacked in feature 
that can be replaced with the real thing.)

Finally, if we are to be serious about this, as a GWT user, contributor, 
and steering committee member, I have to expect to see usable solutions in 
the near future to move away from these tools. This has to include 
tutorials on setting up APT to play nicely with SDM in reasonable 
development environments, a pathway for non-GWT generators to move in, and 
clear evidence that we are not simply abandoning all existing generators 
that are part of GWT itself. More than any other thing we are doing around 
this topic, _this_ is our messaging problem, and efforts to solve it there 
will be a lot clearer for users than closing bugs as WONTFIX or refusing 
patches.

The first is to allow the community the freedom to continue to improve 
before new tools are available, the second recognizes that contributor time 
is not a zero sum game whereby refusing commits will make other work 
magically work faster, and the third brings these new tools into the 
limelight as soon as possible. Ten years of constantly improving generators 
aren't going to be counteracted by ignoring fixes - we need a better 
approach. 

-- 
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/6cc035bd-b89b-4079-ab8c-b03cf23241e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Generator and Linker maintenance and changes

[Colin Alworth]

A few issues have come up (both in my own projects and in the issue 
tracker) where it seemed that continuing to maintain and update the GWT 
Generator and Linker types may be necessary. At least one was fairly 
low-hanging fruit (up for review 
at https://gwt-review.googlesource.com/#/c/14750/), but Daniel raised an 
important question that should be discussed: What is happening with GWT 2.8 
Generators and Linkers.

In general the philosophy seems to be a mix of "if unmaintained, we'll 
phase it out", and "If you keep it up to date, we won't go out of our way 
to break it". Specifically in this case however, we'd like to begin the 
process of phasing out Generators (in favor of APT for your code generation 
needs) and Linkers (in favor of J2CL and the Closure Compiler ability to 
emit JS code and artifacts). 

---

My *personal* position is that GWT 2.8 is set for long-term maintenance - 
we expect point releases to keep it functional for teams not ready to make 
a big shift right away, for a variety of reasons (while I'll leave out to 
keep this short). GWT 2.8 is meant to be a bridge release for apps that 
wish to have modern Java support and JsInterop types at their disposal, and 
as they ready themselves for GWT3/J2CL, they can continue to function and 
stay up to date. The future will only be available beyond 2.8 and 
Generators, but in the meantime, they shouldn't be second class. 

The specific requests here are for static and default methods in AutoBeans 
or RequestFactory Proxies/Contexts. My goal (as stated in the bug reports) 
is not to add new features where getters/setters have their behavior 
altered, or get hooks before/after changes are made, but to let these 
methods be populated and called without breaking the compilation process in 
surprising ways. AutoBeans already support Categories, a sort of externally 
defined method that seems purpose-built to be eventually replaced by 
default methods - thats my goal in my own work here, outside the specific 
filed issues. I expect other features will be made easier to use too, such 
as lambda'd RPC callbacks, safehtmltemplates with logic and loops, and 

On the other hand, if we have published documents ready on what APIs will 
be available easily for linking, or for generating i18n/locale/device 
permutations through the use of external resources or alternate sets of 
constants in compiled code, my ground for complaints is limited to merely 
pointing out the existing stable code that could be better before it is 
ready to be ported. I don't think that this is going to be a hard point to 
sell.

---

So: in the spirit of always building better releases: Where does this 
argument go wrong? How much better off are we by shedding this weight now, 
and what great upgrade paths do we have? Is improving them but also marking 
them all as @Deprecated a good compromise? Please poke holes in this so 
that we can make GWT 2.8 an enduring release that is still able to be seen 
as a powerful tool for Java web developers!

Thanks,
Colin

-- 
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/5abbf455-d7a0-4d36-8b85-ee8a3118e734%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Maven conflict between gwt-dev's and jetty-annotations's asm-commons

[Colin Alworth]

Got it - so GWT is consistent, but the jetty vers we use talks about a 
different one, and our ant process should ignore what jetty asks for in 
favor of our copy.

Filipe, here's the case, in a super-minimal pom, which will fail outright 
without any sources, just a dependency on gwt-dev and the enforcer to 
prevent any conflicts in dependencies:


http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0


  sample
  sample
  0.0.1-SNAPSHOT
  

  com.google.gwt
  gwt-dev
  2.8.0-SNAPSHOT

  


  

  google-snapshots
  https://oss.sonatype.org/content/repositories/google-snapshots/

  
true
  

  


  

  
org.apache.maven.plugins
maven-enforcer-plugin
1.4.1

  
enforce

  

  


  enforce

  

  

  



Build log including grabbing latest gwt:
https://gist.github.com/niloc132/5cf8162ccc3503215f12d151f4c03168

Patch is done, will have it up soon after a bit more poking.

On Friday, April 29, 2016 at 4:38:15 AM UTC-5, Thomas Broyer wrote:
>
>
>
> On Thursday, April 28, 2016 at 11:47:48 PM UTC+2, Colin Alworth wrote:
>>
>> I didn't know how hard and fast we could rely on ASM's backward compat 
>> being.
>>
>
> This is true since ASM 4.0 (released in 2011): 
> http://download.forge.objectweb.org/asm/asm4-guide.pdf
> Fortunately, they changed the groupId for ASM 4.0, so you can safely 
> "converge" to the latest version for org.ow2.asm dependencies, and you 
> should *ban* asm:asm dependencies (ASM 3 and earlier, having no backwards 
> compatibility contract, should have been repackaged –as was done in earlier 
> versions of GWT– rather than simply referenced –as many unfortunately did 
> in earlier versions, such as Hibernate, Jetty, etc.–)
>  
>
>> Probably should also put this in tools so that we are consistent, and 
>> update the ant files so that we don't get slightly different classes in 
>> maven vs zip archive...
>>
>
> We have 5.0.3 in tools, and Maven will "converge" to 5.0.3, so we're 
> consistent. Or am I missing something? (or didn't understand what you're 
> saying)
>

-- 
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/487990c1-dfb3-4fc9-88a5-4fa667f25f1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Maven conflict between gwt-dev's and jetty-annotations's asm-commons

[Colin Alworth]

Should, and does if you have no enforcer. We needed the enforcer due to
arguing between far downstream dependencies from assorted other projects
that kept resulting in fun conflicts (in cases where there was no
guaranteed backward compat).

I'll make up a patch, thanks, I didn't know how hard and fast we could rely
on ASM's backward compat being. Probably should also put this in tools so
that we are consistent, and update the ant files so that we don't get
slightly different classes in maven vs zip archive...

On Thu, Apr 28, 2016 at 3:59 PM Thomas Broyer  wrote:

> Why use 5.0.1 when there's 5.0.3 and ASM guarantees backwards
> compatibility?
> FWIW, Maven should use 5.0.3 by default.
>
> --
> 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/900dbd13-941a-44f2-8497-e1d96fd74a65%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/CADcXZMzaWsJ209wWap4MDizws6r_ryVTJo_OMpWTs8kUms1woA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Maven conflict between gwt-dev's and jetty-annotations's asm-commons

[Colin Alworth]

It looks like a recent change is causing what is technically a version 
conflict in GWT when used from maven. A project I work on uses the 
maven-enforcer-plugin to avoid conflicts, and in a rebuild this morning we 
ran into this error.

[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce) @ gwt-project ---
[WARNING] 
Dependency convergence error for org.ow2.asm:asm-commons:5.0.3 paths to 
dependency are:
+-colins.super.duper:gwt-project:0.0.1-SNAPSHOT
  +-com.google.gwt:gwt-dev:2.8.0-SNAPSHOT
+-org.ow2.asm:asm-commons:*5.0.3*
and
+-colins.super.duper:gwt-project:0.0.1-SNAPSHOT
  +-com.google.gwt:gwt-dev:2.8.0-SNAPSHOT
+-org.eclipse.jetty:jetty-annotations:9.2.14.v20151106
  +-org.ow2.asm:asm-commons:*5.0.1*


This appears to have been introduced 
in https://gwt-review.googlesource.com/#/c/14461/, though it could have 
been earlier. I'm not familiar with how exactly we settled on 5.0.1, and if 
we must use that (and override jetty...), or if we can upgrade to 5.0.3 and 
not risk affecting jetty.

Locally, I'm overriding this by excluding asm-commons from my gwt-dev 
dependencies, and requiring 5.0.3, which seems to be working (minus a 
jsinterop issue, which I am now hunting...). Thoughts on which version we 
should require? I can make the patch once I have feedback.

-- 
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/6a916e9c-6757-4d18-9db3-f100bc1aa206%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.8.0 SNAPSHOT compiler crash

[Colin Alworth]

Agreed - validating supersource is tricky. I've heard of some good options
lately that change how the project interacts with them (like compiling to
.class file and leveraging javac to get the errors), but I don't presently
have any best practices to suggest in general, except tests for each module
so that you see the failure on a module-by-module basis rather than having
to disassemble the entire project as it compiles, and using -strict to
catch uncompilable sources very early.

On Wed, Apr 27, 2016 at 9:12 AM David <david.no...@gmail.com> wrote:

> Yes the org.w3c stuff was my own, it was defined in the html5 module you
> see in the classpath.
> I hope that this was a border case and not typical what happens if you
> have super sources with import statements that cannot be resolved ?
> Because in that case the compiler should give a better error message.
>
> On Wed, 27 Apr 2016 at 15:50, Colin Alworth <niloc...@gmail.com> wrote:
>
>> Thanks. Can you confirm that org.w3c.dom is your own code, and not part
>> of GWT, so it was just out of date? I don't see a jar with that name on
>> your classpath, and neither of the two EntityReference.java files in GWT
>> live in that package or appear have jsinterop annotations.
>>
>>
>> On Wednesday, April 27, 2016 at 8:46:13 AM UTC-5, stuckagain wrote:
>>
>>> Colin,
>>>
>>> The stacktrace was is my initial post.
>>>
>>> Anyway: I managed to find the root cause and solution.
>>>
>>> The super source java file is using JsInterop to map org.w3c.dom API's.
>>> It had annotations like this:
>>> @JsType(isNative=true, namespace=JsNamespace.GLOBAL).
>>>
>>> However, in the snapshot this JsNamespace no longer exists and is now
>>> replaced with JsPackage.GLOBAL.
>>> After changing those references the compilation now succeeds.
>>>
>>> The old sources were like this:
>>> package org.w3c.dom;
>>> import com.google.gwt.core.client.js.JsNamespace;;
>>> import jsinterop.annotations.JsType;
>>>  @JsType(isNative=true,namespace=JsNamespace.GLOBAL)
>>> public interface EntityReference extends Node {
>>> }
>>> I changed it to this:
>>> package org.w3c.dom;
>>> import jsinterop.annotations.JsPackage;
>>> import jsinterop.annotations.JsType;
>>>  @JsType(isNative=true,namespace=JsPackage.GLOBAL)
>>> public interface EntityReference extends Node {
>>> }
>>>
>>>
>>> On Wed, 27 Apr 2016 at 15:32, Colin Alworth <nilo...@gmail.com> wrote:
>>>
>> Can you share the stack trace, the file it is attempting to read, and
>>>> your classpath? It does sound like it might be a bug, but without the
>>>> ability to reproduce, it is difficult to say more. One case where it might
>>>> not be a bug despite its behavior: where it is reusing gwt-unitCache or the
>>>> like from an older version of gwt.
>>>>
>>>> On Wed, Apr 27, 2016 at 8:23 AM David <david...@gmail.com> wrote:
>>>>
>>> I managed to get this to run in a Debugger, from within the maven
>>>>> invocation.
>>>>> The exception is thrown on a super source file in one of my gwt-lib
>>>>> maven artifacts.
>>>>> It is trying to parse a .java file as a class file and this throws the
>>>>> reported exception.
>>>>>
>>>>> This sounds like a bug to me!?
>>>>>
>>>>> On Wed, 27 Apr 2016 at 14:41, David <david...@gmail.com> wrote:
>>>>>
>>>> It was working fine with GWT 2.8.0-beta1 using the exact same pom
>>>>>> files. When I point to GWT-2.8.0-SNAPSHOT I get this error.
>>>>>> So the only thing that changed is the version of GWT moving from
>>>>>> beta1 to SNAPSHOT.
>>>>>>
>>>>>> I am using logLevel ALL but it looks like the 2.8 compiler does not
>>>>>> really use logging. Besides a few INFO and WARNING statements nothing is
>>>>>> logged
>>>>>>
>>>>>> This is the path that is being used.
>>>>>>
>>>>>> [DEBUG]   (s) projectArtifactMap =
>>>>>> {com.google.gwt:gwt-user=com.google.gwt:gwt-user:jar:2.8.0-SNAPSHOT:compile,
>>>>>> com.google.jsinterop:jsinterop-annotations=com.google.jsinterop:jsinterop-annotations:jar:sources:1.0.0-SNAPSHOT:compile,
>>>>>> javax.validation:validation-api=javax.validation:validation-api:jar:sources:1.0.0.GA:compile,
>&

[gwt-contrib] Re: Elemental 2 and J2CL timeline

[Colin Alworth]

I can't speak for J2CL's timelines, as it is an internal project at this 
time. However, it has been stated that it will support GWT's JRE emulation 
and JsInterop out of the box, and the expectation is that it will simply be 
a transpiler and won't support generators (suggested that projects move to 
APT or the like), or linkers (since the Closure Compiler manages this part 
of things).

By itself, this means that Widget can work, though Element will need to be 
reimplemented in JsInterop since JSOs won't exist (and JSNI is likely to 
have a replacement as well). On the other hand, UiBinder uses the GWT 
Generator system, which doesn't at this time have a clear upgrade path.

To think about life without GWT.create(Foo.class), consider APT-based 
projects like AutoValue, where class sources are generated on your 
classpath (by your build tool, and your IDE if configured correctly) so 
that you can reference these generated classes directly from within your 
sources. For cases where you want to pick the right implementation (rtl, 
locale, device formfactor, etc), a factory methods can also be declared 
within the generated code, and you can reference  that rather than a 
constructor.

On Tuesday, April 26, 2016 at 8:30:21 AM UTC-5, Paul Stockley wrote:
>
> Does anyone have any idea when elemental 2 will be available? Also what is 
> a rough timeline for a version on J2CL being available, is it 6 months, a 
> year or more away? 
>
> The reason I ask is that I am thinking about how our company can migrate 
> to the new compiler. We will need widgets and UiBinder for quite a while, 
> even though we will slowly migrate to React. I was contemplating creating a 
> project to port the basic Widget framework to use something like elemental. 
> Also I was thinking about how to build a new version of UiBinder that 
> didn't use GWT.create.
>

-- 
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/1ed4989b-4676-48fb-9450-1e867c5b476c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.8.0 SNAPSHOT compiler crash

[Colin Alworth]

Thanks. Can you confirm that org.w3c.dom is your own code, and not part of 
GWT, so it was just out of date? I don't see a jar with that name on your 
classpath, and neither of the two EntityReference.java files in GWT live in 
that package or appear have jsinterop annotations.

On Wednesday, April 27, 2016 at 8:46:13 AM UTC-5, stuckagain wrote:
>
> Colin,
>
> The stacktrace was is my initial post.
>
> Anyway: I managed to find the root cause and solution.
>
> The super source java file is using JsInterop to map org.w3c.dom API's.
> It had annotations like this:
> @JsType(isNative=true, namespace=JsNamespace.GLOBAL).
>
> However, in the snapshot this JsNamespace no longer exists and is now 
> replaced with JsPackage.GLOBAL.
> After changing those references the compilation now succeeds.
>
> The old sources were like this:
> package org.w3c.dom;
> import com.google.gwt.core.client.js.JsNamespace;;
> import jsinterop.annotations.JsType;
>  @JsType(isNative=true,namespace=JsNamespace.GLOBAL)
> public interface EntityReference extends Node {
> }
> I changed it to this:
> package org.w3c.dom;
> import jsinterop.annotations.JsPackage;
> import jsinterop.annotations.JsType;
>  @JsType(isNative=true,namespace=JsPackage.GLOBAL)
> public interface EntityReference extends Node {
> }
>  
>
> On Wed, 27 Apr 2016 at 15:32, Colin Alworth <nilo...@gmail.com 
> > wrote:
>
>> Can you share the stack trace, the file it is attempting to read, and 
>> your classpath? It does sound like it might be a bug, but without the 
>> ability to reproduce, it is difficult to say more. One case where it might 
>> not be a bug despite its behavior: where it is reusing gwt-unitCache or the 
>> like from an older version of gwt.
>>
>> On Wed, Apr 27, 2016 at 8:23 AM David <david...@gmail.com > 
>> wrote:
>>
>>> I managed to get this to run in a Debugger, from within the maven 
>>> invocation.
>>> The exception is thrown on a super source file in one of my gwt-lib 
>>> maven artifacts.
>>> It is trying to parse a .java file as a class file and this throws the 
>>> reported exception.
>>>
>>> This sounds like a bug to me!?
>>>
>>> On Wed, 27 Apr 2016 at 14:41, David <david...@gmail.com > 
>>> wrote:
>>>
>>>> It was working fine with GWT 2.8.0-beta1 using the exact same pom 
>>>> files. When I point to GWT-2.8.0-SNAPSHOT I get this error.
>>>> So the only thing that changed is the version of GWT moving from beta1 
>>>> to SNAPSHOT.
>>>>
>>>> I am using logLevel ALL but it looks like the 2.8 compiler does not 
>>>> really use logging. Besides a few INFO and WARNING statements nothing is 
>>>> logged
>>>>
>>>> This is the path that is being used.
>>>>
>>>> [DEBUG]   (s) projectArtifactMap = 
>>>> {com.google.gwt:gwt-user=com.google.gwt:gwt-user:jar:2.8.0-SNAPSHOT:compile,
>>>>  
>>>> com.google.jsinterop:jsinterop-annotations=com.google.jsinterop:jsinterop-annotations:jar:sources:1.0.0-SNAPSHOT:compile,
>>>>  
>>>> javax.validation:validation-api=javax.validation:validation-api:jar:sources:1.0.0.GA:compile,
>>>>  
>>>> com.google.gwt:gwt-dev=com.google.gwt:gwt-dev:jar:2.8.0-SNAPSHOT:compile, 
>>>> org.ow2.asm:asm=org.ow2.asm:asm:jar:5.0.3:compile, 
>>>> org.ow2.asm:asm-util=org.ow2.asm:asm-util:jar:5.0.3:compile, 
>>>> org.ow2.asm:asm-tree=org.ow2.asm:asm-tree:jar:5.0.3:compile, 
>>>> org.ow2.asm:asm-commons=org.ow2.asm:asm-commons:jar:5.0.3:compile, 
>>>> org.eclipse.jetty.websocket:websocket-client=org.eclipse.jetty.websocket:websocket-client:jar:9.2.14.v20151106:compile,
>>>>  
>>>> org.eclipse.jetty:jetty-util=org.eclipse.jetty:jetty-util:jar:9.2.14.v20151106:compile,
>>>>  
>>>> org.eclipse.jetty:jetty-io=org.eclipse.jetty:jetty-io:jar:9.2.14.v20151106:compile,
>>>>  
>>>> org.eclipse.jetty.websocket:websocket-common=org.eclipse.jetty.websocket:websocket-common:jar:9.2.14.v20151106:compile,
>>>>  
>>>> org.eclipse.jetty.websocket:websocket-api=org.eclipse.jetty.websocket:websocket-api:jar:9.2.14.v20151106:compile,
>>>>  
>>>> org.eclipse.jetty:jetty-webapp=org.eclipse.jetty:jetty-webapp:jar:9.2.14.v20151106:compile,
>>>>  
>>>> org.eclipse.jetty:jetty-xml=org.eclipse.jetty:jetty-xml:jar:9.2.14.v20151106:compile,
>>>>  
>>>> org.eclipse.jetty:jetty-servlet=org.eclipse.jetty:jetty-servlet:jar:9.2.14.v20151106:compile

Re: [gwt-contrib] Re: GWT 2.8.0 SNAPSHOT compiler crash

[Colin Alworth]

Can you share the stack trace, the file it is attempting to read, and your
classpath? It does sound like it might be a bug, but without the ability to
reproduce, it is difficult to say more. One case where it might not be a
bug despite its behavior: where it is reusing gwt-unitCache or the like
from an older version of gwt.

On Wed, Apr 27, 2016 at 8:23 AM David  wrote:

> I managed to get this to run in a Debugger, from within the maven
> invocation.
> The exception is thrown on a super source file in one of my gwt-lib maven
> artifacts.
> It is trying to parse a .java file as a class file and this throws the
> reported exception.
>
> This sounds like a bug to me!?
>
> On Wed, 27 Apr 2016 at 14:41, David  wrote:
>
>> It was working fine with GWT 2.8.0-beta1 using the exact same pom files.
>> When I point to GWT-2.8.0-SNAPSHOT I get this error.
>> So the only thing that changed is the version of GWT moving from beta1 to
>> SNAPSHOT.
>>
>> I am using logLevel ALL but it looks like the 2.8 compiler does not
>> really use logging. Besides a few INFO and WARNING statements nothing is
>> logged
>>
>> This is the path that is being used.
>>
>> [DEBUG]   (s) projectArtifactMap =
>> {com.google.gwt:gwt-user=com.google.gwt:gwt-user:jar:2.8.0-SNAPSHOT:compile,
>> com.google.jsinterop:jsinterop-annotations=com.google.jsinterop:jsinterop-annotations:jar:sources:1.0.0-SNAPSHOT:compile,
>> javax.validation:validation-api=javax.validation:validation-api:jar:sources:1.0.0.GA:compile,
>> com.google.gwt:gwt-dev=com.google.gwt:gwt-dev:jar:2.8.0-SNAPSHOT:compile,
>> org.ow2.asm:asm=org.ow2.asm:asm:jar:5.0.3:compile,
>> org.ow2.asm:asm-util=org.ow2.asm:asm-util:jar:5.0.3:compile,
>> org.ow2.asm:asm-tree=org.ow2.asm:asm-tree:jar:5.0.3:compile,
>> org.ow2.asm:asm-commons=org.ow2.asm:asm-commons:jar:5.0.3:compile,
>> org.eclipse.jetty.websocket:websocket-client=org.eclipse.jetty.websocket:websocket-client:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-util=org.eclipse.jetty:jetty-util:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-io=org.eclipse.jetty:jetty-io:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty.websocket:websocket-common=org.eclipse.jetty.websocket:websocket-common:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty.websocket:websocket-api=org.eclipse.jetty.websocket:websocket-api:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-webapp=org.eclipse.jetty:jetty-webapp:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-xml=org.eclipse.jetty:jetty-xml:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-servlet=org.eclipse.jetty:jetty-servlet:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-security=org.eclipse.jetty:jetty-security:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-servlets=org.eclipse.jetty:jetty-servlets:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-continuation=org.eclipse.jetty:jetty-continuation:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-http=org.eclipse.jetty:jetty-http:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-annotations=org.eclipse.jetty:jetty-annotations:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-plus=org.eclipse.jetty:jetty-plus:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-jndi=org.eclipse.jetty:jetty-jndi:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:apache-jsp=org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty:jetty-server=org.eclipse.jetty:jetty-server:jar:9.2.14.v20151106:compile,
>> org.eclipse.jetty.toolchain:jetty-schemas=org.eclipse.jetty.toolchain:jetty-schemas:jar:3.1.M0:compile,
>> javax.servlet:javax.servlet-api=javax.servlet:javax.servlet-api:jar:3.0.1:provided,
>> org.mortbay.jasper:apache-jsp=org.mortbay.jasper:apache-jsp:jar:8.0.9.M3:compile,
>> org.mortbay.jasper:apache-el=org.mortbay.jasper:apache-el:jar:8.0.9.M3:compile,
>> com.google.gwt:gwt-elemental=com.google.gwt:gwt-elemental:jar:2.8.0-SNAPSHOT:compile,
>> com.google.inject:guice=com.google.inject:guice:jar:3.0:compile,
>> javax.inject:javax.inject=javax.inject:javax.inject:jar:1:compile,
>> aopalliance:aopalliance=aopalliance:aopalliance:jar:1.0:compile,
>> com.acme.acmeproduct:gui.html5=com.acme.acmeproduct:gui.html5:gwt-lib:0.0.1-SNAPSHOT:compile,
>> com.acme.acmeproduct:gui.editor=com.acme.acmeproduct:gui.editor:gwt-lib:0.0.1-SNAPSHOT:compile,
>> com.acme.acmecommon:common.core=com.acme.acmecommon:common.core:jar:0.0.1-SNAPSHOT:compile,
>> com.acme.acmecommon:common.config=com.acme.acmecommon:common.config:gwt-lib:0.0.1-SNAPSHOT:compile,
>> com.acme.acmecommon:common.servlet=com.acme.acmecommon:common.servlet:jar:0.0.1-SNAPSHOT:compile,
>> com.fasterxml.jackson.core:jackson-core=com.fasterxml.jackson.core:jackson-core:jar:2.7.3:compile,
>> com.fasterxml.jackson.core:jackson-databind=com.fasterxml.jackson.core:jackson-databind:jar:2.7.3:compile,
>> 

Re: [gwt-contrib] Lambda overhead

[Colin Alworth]

Meta: it would make my year if we could get one of these compiler
discussions happening once a week on a public forum like this, both for
better basic understanding about why some of these concepts are not
trivial, and for better visibility into what else is going on in the
process of continuing to improve and grow GWT.


On Mon, Apr 18, 2016 at 12:49 PM 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> I'm ok with restricting them to @JsFunction java8 lambdas. That's
> likely to be the common path for web oriented code for event handling.
>
>
> On Mon, Apr 18, 2016 at 10:47 AM, 'Roberto Lublinerman' via GWT
> Contributors  wrote:
> > That is why I am saying that it will be easy to do for JsFunctions but
> due
> > to Java semantics (regular) lambdas are just not plain functions and
> thus I
> > don't think there is much to gain there.
> >
> > I don't think there is much to gain on the regular lambdas. There are 2
> > different ways we can handle them and reduce a bit of the generated code
> but
> > I don't think there is a lot of potential ways.
> > 1) do not generate anonymous inner classes, rather have the make lambda
> > factory take all the required parameters, i.e. castmap.
> > 2) create an anonymous innerclass based on the class/interface that is
> being
> > extended/implemented when a lambda for that is seen. In that way if an
> > interface is used with many lambdas there is only one supporting class
> > instead of many.
> >
> >
> > On Mon, Apr 18, 2016 at 10:22 AM, 'Ray Cromwell' via GWT Contributors
> >  wrote:
> >>
> >> I understand, but the trampolines cause bloat, and if you're
> >> suggesting treating all non-JsFunction Java8 lambdas as JsFunctions as
> >> far as code-gen is concerned, then you would not be able to make the
> >> following code work:
> >>
> >> foo(Callable x) { bar(x); }
> >> foo(Runnable x) { bar(x); }
> >>
> >> bar(Object x) { if (x instanceof Callable) { print("it's a callable");
> >> } else if (x instanceof Runnable) { print("It's a runnable"); } }
> >>
> >> You need a castMap for that.
> >>
> >>
> >> On Mon, Apr 18, 2016 at 10:17 AM, 'Roberto Lublinerman' via GWT
> >> Contributors  wrote:
> >> > The point is that for JsFunctions you DON'T actually need to do the
> >> > makeLambda(). JsFunction was designed to be able to pass JS functions
> to
> >> > JAVA so there is a code path for that and we can exploit it for
> >> > JsFunction
> >> > lambdas.
> >> >
> >> > So x -> 42  + capture will be represented in the JAva AST as
> >> > class X {
> >> >   {
> >> >  .  new X$0(capture);
> >> >   }
> >> >   // Synthetic lambda method
> >> >   int lambda_f(capture, x) {
> >> >  return 42 + capture;
> >> >   }
> >> >
> >> > // Lambda function implmenetation. Nothing needs to be emitted for
> this
> >> > in
> >> > JS
> >> > class X$0 implements JsFunctionInterface {
> >> >   capture;
> >> >   X$0(capture) {
> >> >this.capture = capture;
> >> >   }
> >> >
> >> >   int m(x) {
> >> >  X.lambda_f(this.capture, x);
> >> >   }
> >> > }
> >> >
> >> >
> >> > In the JS ast we do
> >> >
> >> >   new X$0(capture)  -->  function(x) { X.lambda_f(capture, x) }
> >> >
> >> > So we don't need makeLambda or anything else; we can just treat
> >> > JsFunciton
> >> > implementation as if they were functions passed in from JavaScript
> where
> >> > object methods will go through the regular trampoline into the "JSO"
> >> > implementation.
> >> >
> >> >
> >> >
> >> >
> >> > On Mon, Apr 18, 2016 at 9:55 AM, 'Ray Cromwell' via GWT Contributors
> >> >  wrote:
> >> >>
> >> >> That seems similar to my proposal, only you're doing it in GenJsAST.
> >> >> You'll still need to the makeLambda() trick to allow it to work as a
> >> >> regular obejct as well, with hashCode()/equals()/getClass()
> >> >> properties, as well as castMap installed. But if you use static
> method
> >> >> delegation, the size won't be as ideal if the static method doesn't
> >> >> inline.
> >> >>
> >> >> You want something like x -> 42 + capture to compile to
> >> >> makeLambda(function(x) { return 42 + capture }, castMap, classLit),
> >> >> not function(x) { return Class.foo(capture, x); } do you not?
> >> >>
> >> >>
> >> >> On Mon, Apr 18, 2016 at 9:49 AM, 'Roberto Lublinerman' via GWT
> >> >> Contributors 
> wrote:
> >> >> > The scheme I had in mind does not modify much the Java AST
> >> >> > representation
> >> >> > but is more in the lowering to the JsAST, basically it boils down
> the
> >> >> > the
> >> >> > following:.
> >> >> > 1. You create the lambda body as a static method of the class where
> >> >> > it
> >> >> > appears. This static method has all captures as parameters (thiis
> is
> >> >> > very
> >> >> > similar as 

[gwt-contrib] Re: dev tests failing locally?

[Colin Alworth]

Confirmed, isPublic is true in all three cases, as expected, without the 
old code in place.

On Tuesday, April 19, 2016 at 9:20:10 AM UTC-5, Colin Alworth wrote:
>
> There is no MOD_DEFAULT, at least not yet. I initially attempted to add 
> one and tried to copy the same date from org.objectweb.asm, but their 
> Opcodes type doesn't really have a field that seems to match (no 
> ACC_DEFAULT, etc). If memory serves, bytecode doesn't hold this 
> information, but just has the method marked as not-abstract, and the change 
> to support default methods was in the java lang itself, not the jvm.
>
> This works as expected - here is the test I had stubbed in to confirm that 
> not setting MOD_ABSTRACT still results in it being set (via mapBits):
> public interface Java8Interface {
>   default int defaultImplMethod() {
> return 1;
>   }
>   static int staticImplMethod() {
> return 1;
>   }
>   int noImplMethod();
> }
>
> ...
>   JMethod method = type.getMethod("defaultImplMethod", noParamTypes);
>   assertSame(JPrimitiveType.INT, method.getReturnType());
>   assertEquals(0, method.getParameters().length);
>   assertFalse(method.isStatic());
>   *assertFalse**(method.isAbstract());*
>
>
>   method = type.getMethod("staticImplMethod", noParamTypes);
>   assertSame(JPrimitiveType.INT, method.getReturnType());
>   assertEquals(0, method.getParameters().length);
>   assertTrue(method.isStatic());
>   *assertFalse**(method.isAbstract());*
>
>
>   method = type.getMethod("noImplMethod", noParamTypes);
>   assertSame(JPrimitiveType.INT, method.getReturnType());
>   assertEquals(0, method.getParameters().length);
>   assertFalse(method.isStatic());
>   *assertTrue**(method.isAbstract());*
>
> I've not yet tested public to ensure that it is sane (though was hoping 
> that other unit tests would be unhappy if it wasn't). Before I submit the 
> change, I will check this as well, but the test is currently passing.
>
> On Tuesday, April 19, 2016 at 9:10:05 AM UTC-5, Thomas Broyer wrote:
>>
>>
>>
>> On Tuesday, April 19, 2016 at 2:37:03 PM UTC+2, Colin Alworth wrote:
>>>
>>> As an aside, the fix for the original bug seems to be very easy - the 
>>> code that is building the JMethod instances seems to be overzealous about 
>>> what modifiers must be applied. Aside from the constant failures, all 
>>> compiler tests pass with this change:
>>>
>>> diff --git a/dev/core/src/com/google/gwt/dev/javac/
>>> CompilationUnitTypeOracleUpdater.java b/dev/core/src/com/google/gwt/dev/
>>> javac/CompilationUnitTypeOracleUpdater.java
>>>  
>>> index f63e037..c926ec3 100644 
>>> --- a/dev/core/src/com/google/gwt/dev/javac/
>>> CompilationUnitTypeOracleUpdater.java 
>>> +++ b/dev/core/src/com/google/gwt/dev/javac/
>>> CompilationUnitTypeOracleUpdater.java 
>>> @@ -1121,10 +1121,6 @@ public class CompilationUnitTypeOracleUpdater 
>>> extends TypeOracleUpdater { 
>>>  } 
>>>   
>>>  addModifierBits(method, mapBits(ASM_TO_SHARED_MODIFIERS, methodData
>>> .getAccess())); 
>>> -if (unresolvedType.isInterface() != null) { 
>>> -  // Always add implicit modifiers on interface methods. 
>>> -  addModifierBits(method, Shared.MOD_PUBLIC | Shared.MOD_ABSTRACT); 
>>> -} 
>>>   
>>>  if ((methodData.getAccess() & Opcodes.ACC_VARARGS) != 0) { 
>>>setVarArgs(method);
>>>
>>> With a little more testing, I'll submit this for review, along with a 
>>> test that verifies that it has the desired behavior.
>>>
>>
>> I think this change is overzealous ;-)
>>
>> > Every method declaration in the body of an interface is implicitly 
>> public (§6.6). It is permitted, but discouraged as a matter of style, to 
>> redundantly specify the public modifier for a method declaration in an 
>> interface.
>> > […]
>> > An interface method lacking a default modifier or a static modifier is 
>> implicitly abstract, so its body is represented by a semicolon, not a 
>> block. It is permitted, but discouraged as a matter of style, to 
>> redundantly specify the abstract modifier for such a method declaration.
>> — Source: 
>> https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.4
>>
>> So I think, it should unconditionally add the MOD_PUBLIC bit, and 
>> conditionally add the MOD_ABSTRACT bit if neither MOD_STATIC nor 
>> MOD_DEFAULT is present.
>>
>>
>>

-- 
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/cf930d6e-67b3-49f2-9b23-f5b78ce76cf1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: dev tests failing locally?

[Colin Alworth]

There is no MOD_DEFAULT, at least not yet. I initially attempted to add one 
and tried to copy the same date from org.objectweb.asm, but their Opcodes 
type doesn't really have a field that seems to match (no ACC_DEFAULT, etc). 
If memory serves, bytecode doesn't hold this information, but just has the 
method marked as not-abstract, and the change to support default methods 
was in the java lang itself, not the jvm.

This works as expected - here is the test I had stubbed in to confirm that 
not setting MOD_ABSTRACT still results in it being set (via mapBits):
public interface Java8Interface {
  default int defaultImplMethod() {
return 1;
  }
  static int staticImplMethod() {
return 1;
  }
  int noImplMethod();
}

...
  JMethod method = type.getMethod("defaultImplMethod", noParamTypes);
  assertSame(JPrimitiveType.INT, method.getReturnType());
  assertEquals(0, method.getParameters().length);
  assertFalse(method.isStatic());
  *assertFalse**(method.isAbstract());*


  method = type.getMethod("staticImplMethod", noParamTypes);
  assertSame(JPrimitiveType.INT, method.getReturnType());
  assertEquals(0, method.getParameters().length);
  assertTrue(method.isStatic());
  *assertFalse**(method.isAbstract());*


  method = type.getMethod("noImplMethod", noParamTypes);
  assertSame(JPrimitiveType.INT, method.getReturnType());
  assertEquals(0, method.getParameters().length);
  assertFalse(method.isStatic());
  *assertTrue**(method.isAbstract());*

I've not yet tested public to ensure that it is sane (though was hoping 
that other unit tests would be unhappy if it wasn't). Before I submit the 
change, I will check this as well, but the test is currently passing.

On Tuesday, April 19, 2016 at 9:10:05 AM UTC-5, Thomas Broyer wrote:
>
>
>
> On Tuesday, April 19, 2016 at 2:37:03 PM UTC+2, Colin Alworth wrote:
>>
>> As an aside, the fix for the original bug seems to be very easy - the 
>> code that is building the JMethod instances seems to be overzealous about 
>> what modifiers must be applied. Aside from the constant failures, all 
>> compiler tests pass with this change:
>>
>> diff --git a/dev/core/src/com/google/gwt/dev/javac/
>> CompilationUnitTypeOracleUpdater.java b/dev/core/src/com/google/gwt/dev/
>> javac/CompilationUnitTypeOracleUpdater.java
>>  
>> index f63e037..c926ec3 100644 
>> --- a/dev/core/src/com/google/gwt/dev/javac/
>> CompilationUnitTypeOracleUpdater.java 
>> +++ b/dev/core/src/com/google/gwt/dev/javac/
>> CompilationUnitTypeOracleUpdater.java 
>> @@ -1121,10 +1121,6 @@ public class CompilationUnitTypeOracleUpdater 
>> extends TypeOracleUpdater { 
>>  } 
>>   
>>  addModifierBits(method, mapBits(ASM_TO_SHARED_MODIFIERS, methodData.
>> getAccess())); 
>> -if (unresolvedType.isInterface() != null) { 
>> -  // Always add implicit modifiers on interface methods. 
>> -  addModifierBits(method, Shared.MOD_PUBLIC | Shared.MOD_ABSTRACT); 
>> -} 
>>   
>>  if ((methodData.getAccess() & Opcodes.ACC_VARARGS) != 0) { 
>>setVarArgs(method);
>>
>> With a little more testing, I'll submit this for review, along with a 
>> test that verifies that it has the desired behavior.
>>
>
> I think this change is overzealous ;-)
>
> > Every method declaration in the body of an interface is implicitly 
> public (§6.6). It is permitted, but discouraged as a matter of style, to 
> redundantly specify the public modifier for a method declaration in an 
> interface.
> > […]
> > An interface method lacking a default modifier or a static modifier is 
> implicitly abstract, so its body is represented by a semicolon, not a 
> block. It is permitted, but discouraged as a matter of style, to 
> redundantly specify the abstract modifier for such a method declaration.
> — Source: 
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.4
>
> So I think, it should unconditionally add the MOD_PUBLIC bit, and 
> conditionally add the MOD_ABSTRACT bit if neither MOD_STATIC nor 
> MOD_DEFAULT is present.
>
>
>

-- 
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/e7f1dbbc-a90a-482f-9919-a02f4d22ef92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: dev tests failing locally?

[Colin Alworth]

As an aside, the fix for the original bug seems to be very easy - the code 
that is building the JMethod instances seems to be overzealous about what 
modifiers must be applied. Aside from the constant failures, all compiler 
tests pass with this change:

diff --git a/dev/core/src/com/google/gwt/dev/javac/
CompilationUnitTypeOracleUpdater.java b/dev/core/src/com/google/gwt/dev/
javac/CompilationUnitTypeOracleUpdater.java
 
index f63e037..c926ec3 100644 
--- a/dev/core/src/com/google/gwt/dev/javac/CompilationUnitTypeOracleUpdater
.java 
+++ b/dev/core/src/com/google/gwt/dev/javac/CompilationUnitTypeOracleUpdater
.java 
@@ -1121,10 +1121,6 @@ public class CompilationUnitTypeOracleUpdater extends 
TypeOracleUpdater { 
 } 
  
 addModifierBits(method, mapBits(ASM_TO_SHARED_MODIFIERS, methodData.
getAccess())); 
-if (unresolvedType.isInterface() != null) { 
-  // Always add implicit modifiers on interface methods. 
-  addModifierBits(method, Shared.MOD_PUBLIC | Shared.MOD_ABSTRACT); 
-} 
  
 if ((methodData.getAccess() & Opcodes.ACC_VARARGS) != 0) { 
   setVarArgs(method);

With a little more testing, I'll submit this for review, along with a test 
that verifies that it has the desired behavior.

-- 
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/f687c323-35af-418e-804d-961d78b8a042%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] dev tests failing locally?

[Colin Alworth]

I'm looking into fixing the javac.typemodel.JMethod creation to make it 
support static and default methods in Java8 interfaces so that generators 
(at least autobeans and requestfactory) can easily support categories 
without external classes (see 
https://github.com/gwtproject/gwt/issues/9289, I'm sure there are others). 
Along the way, I ran into a few unit tests that I apparently broke, and 
then discovered that these tests (at least locally) also consistently fail 
at current master. 

com.google.gwt.dev.resource.impl.ClassPathEntryTest
testResourceCreated
testResourceDeleted
testResourceRenamed

com.google.gwt.dev.resource.impl.ResourceAccumulatorTest
testDeleteFile
testMultipleListeners
testSymlinkInfiniteLoop
testSymlinks
testListensInNewDirectories
testRenameFile
testRenameDirectory
testRenameParentDirectory
testAddFile

My local tools dir is up to date, I'm running OS X 10.11.4, with ant 1.9.4 
and jdk 1.8.0_60-b27. Are these tests known to be broken, or is there 
something likely wrong with my setup? I can share the stacktraces 
themselves, but all of these seem to be related to filesystem access. Is 
there something funny about these?

I do see notes about ClassPathEntryTest failing (common.ant.xml and 
dev/BUILD), but ResourceAccumulatorTest doesn't seem to have notes about it 
- but, it isn't added to a test suite. Are these tests broken in ant, but 
not excluded? Is there a better way to be running these aside from `ant 
test` to build sanely?

-- 
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/fb4fdabe-5b33-4004-8d4b-1e8ba13a07cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Differences between permutations

[Colin Alworth]

If you only set one possible permutation, your .nocache.js won't attempt to 
detect which browser is running, and will always use that one. Only if 
there is more than one possible value will it attempt to find out which is 
appropriate. 

On Saturday, March 26, 2016 at 5:38:53 PM UTC-5, Kirill Prazdnikov wrote:
>
> One more question about this.
>
> Assume I selected only 1 configuration by 
>
> 
>
>
> Then how can I ask GWT load it on every browser ? 
>
>
>

-- 
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: [gwt-contrib] Re: New Error caused by recent Chrome Update: RangeError: Maximum call stack size exceeded

[Colin Alworth]

The only issue I know of that causes this is
https://github.com/gwtproject/gwt/issues/8233 (and also apparently
https://github.com/gwtproject/gwt/issues/8229), which is fixed in GWT 2.7.
This issue was caused by invoking a method with many arguments, rather than
wrapping those arguments in a list and invoking with the list itself. It is
possible that you haven't had enough items in the list to cause this, but
that Chrome has changed the size of its stack (or some other implementation
detail) and you are now tickling it.

Just a guess, but if it is the case, upgrading will solve it. If not, is it
possible to get a stack trace out of the error?

On Mon, Mar 28, 2016 at 5:01 AM 'Marius Gerwinn' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Hi Josh,
>
> Just wan't to let you know that we're facing the same issue here. We also
> have a quite large app, using Errai and only experiencing the issue in the
> newer Chrome version.
> No workaround except disabling the optimisation yet. If you found
> something or want some more info about our setup for better understanding
> I'm very happy to help.
>
>
> Am Freitag, 22. Januar 2016 18:18:01 UTC+1 schrieb Joshb:
>>
>> Gilberto,
>>
>> I've done some more digging.  Starting Chrome with
>> --js-flags="--stack-size 6" makes the application work.  I haven't
>> played with the stack size to see what level breaks it.
>>
>> Interestingly, I've tried smaller modules, and the problem persists.  We
>> are using Errai, but the reason I think the issue is more to do with GWT is
>> that
>>
>>
>>- it works in SDM
>>- It works when optimizations are set to 0.  In fact, the output is
>>over 70MB and it still works.
>>- it fails when optimizations are >0
>>
>> This makes me think that some optimization being done by the GWT compiler
>> is generating a stack too deep for Chrome (works fine on IE, FF, and
>> Safari, as well as Chrome pre 47).
>>
>> My understanding of one of the promises of GWT is that it compiles
>> separate version for different browsers.  I wouldn't think that code that
>> otherwise works could be broken in the compilation process.
>>
>> On Sunday, January 17, 2016 at 11:58:52 AM UTC-5, Gilberto Torrezan Filho
>> wrote:
>>>
>>> Hi, I have a large GWT app deployed too, and didn't notice any problem
>>> with the new Chrome. Do you use any large GWT framework, such as Vaadin or
>>> GXT? Or any framework/lib outside GWT on the client side? Or maybe any
>>> native component?
>>>
>>> On Wednesday, December 16, 2015 at 3:11:10 PM UTC-2, Joshb wrote:

 Hi all.

 We have a fairly large GWT application (~20MB OBF).  Recently (last
 week I believe) we started to encounter a RangeError: Maximum call stack
 size exceed in Chrome in our deployed application.  The error does not
 occur in FF or IE.  I downloaded older versions of Chromium and confirmed
 that the application still works, so I'm guessing there was a recent update
 to Chrome (47) that caused the issue.

 There is no problem in SDM, and after playing around with the
 optimization level, found that at level '0', the app loads.  At 1-9, the
 exception is thrown, and from what I can tell by setting a breakpoint on
 exception, it does not appear to be too deep in a call stack.

 I realize that this is not a bug per-se of GWT, but I would think
 (hope) that the GWT compiler could account for browser limitations when
 performing optimizations, to not optimize otherwise working code into code
 that won't run.

 Would love to supply more information if needed.  I'm hoping others
 have discovered the same issue, and that there is an easy solution that can
 squeeze into the 2.8 release.

 Thanks in advance,

 Josh

>>> --
> 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/b996f740-4b03-4e65-ab54-b1182154256a%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/CADcXZMxA5VJex5XLC8FpGNzb3bpFoT71yKEW%2Ba6LJALnDJHhqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Trying to use JsInterop to work with React

[Colin Alworth]

Yikes, that's rather opinionated. I don't personally work with React, but I
guess I'm surprised that it can't handle actual inheritance (or even
defining a prototype and attaching it to a constructor).

Based on what you have there and the details described at
https://facebook.github.io/react/docs/top-level-api.html, I'd suspect that
they actually want the equivalent of the class object itself, not an
instance of it (the line between them is blury in JS already).

> One thing that makes components different than standard prototypal
classes is that you don't need to call new on them. They are convenience
wrappers that construct backing instances (via new) for you.

This seems to imply that you can't be guaranteed that your constructors
will actually be called, but also reinforces the idea that they don't want
you to pass in a class instance, just the methods that should be called on
the eventually-created instances. More details from
https://facebook.github.io/react/docs/component-specs.html seem to say that
you are actually expected to pass in just a bag of properties, one of which
will be that `render` function, which can trust that a `this` will be
specified to provide `props` and `state`.

If there is a hook that lets you define your own constructor or factory
method, that would be good to have to correctly do the GWT object wiring
(perhaps some jsinterop expert can pipe up here as to what will be lost
without that being called). Otherwise, some jsni or JsObject-building code
that copies references to functions over to the a map-like object would be
ideal. A JsProperty-annotated field may be enough to convince the compiler
to generate correct code inside your function to access those properties,
but I would be less sure about non-static helper methods still being around
in the generated component.

On Sun, Mar 13, 2016 at 3:35 PM Paul Stockley  wrote:

> We have started using React (using ES6 and FlowTypes) which is quite nice.
> However, we have a large GWT application that we want to start embedding
> React within. This makes perfect sense for migrating away from Widgets to a
> more modern approach. So I decided I would try and define a Java Api for
> React. After a couple of hours I got a really hacky prototype basically
> working. The code looks like
>
> private ClassicComponentClass customComponent;
>
>
> public void onModuleLoad() {
>
> customComponent = React.createClass(new CustomComponent());
>
> HTMLProps props = Props.newHTML();
> props.setDefaultValue("Test");
>
> DOMElement div =
> React.createElement("div", props,
> React.createElement("div", null),
> React.createElement(customComponent, null),
> React.createElement("div", null, "An example")
> );
>
> ReactDOM.render(div, Document.get().getElementById("mainCont"));
> }
>
>
> @JsType(namespace = JsPackage.GLOBAL, name="CustomComponent")
> public class CustomComponent {
>
> @JsMethod
> public ReactElement render() {
> return React.createElement("div", null, "It works");
> }
> }
>
>
>
> This works fine for intrinsic React components. The problem is defining 
> custom components. The React.createClass function needs to take a plain 
> javascript object with certain methods defined (render, lifecyle methods 
> etc). If I pass a Java object marked as JsType, this doesn't work because the 
> render method needs to be defined on the top level object. The code puts it 
> on a different prototype which doesn't work because React does the following:
>
>
>
>   for (var name in spec) {
> if (!spec.hasOwnProperty(name)) {  --Isn't true for render
>   continue;
> }
>
>
> Is there some way to achieve what I want with JsInterop?  I tried extending 
> another base class marked with isNative=true. However, this results in a 
> runtime error when trying to construct an object of that type.
>
>
> I am going to try a real hack with a JSNI method that constructs an object 
> given the various
>
> methods as parameters.
>
>
>
> --
> 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/1dfb2508-9f88-4ecc-a30f-51814c496082%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 

[gwt-contrib] AutoBean wrapping on List method return types

[Colin Alworth]

In preparation for submitting a patch with Java8 Streams to GWT, I've been 
using streams in more situations, and have found a case with AutoBeans 
where they don't behave correctly. Specifically, AutoBeanFactoryGenerator 
builds a "shim" type for each object that it will interact with, starting 
with the bean types declared on the factory, and recursively handling each 
type it encounters as return types from declared methods.

ABFGenerator doesn't have any special wiring for List/Map/Set, which 
surprised me, since there is a specific class to wrap Splittable instances 
rather than getting an autobean wrapper/shim type - 
the SplittableList, SplittableSet and SplittableComplex/SimpleMap types 
serve this purpose - at least I thought it did. Upon reading more deeply, 
it seems that the generated type emul.java.util.ListAutoBean is used if 

   1. a wrapped (not-splittable) autobean
   2. has a method that returns List, and
   3. the returned value from that method/getter is not itself an autobean.
   

In that case, the 'normal' list type gets wrapped, and the shim delegates 
all of its calls to the non-autobean list. Not what I had thought happened, 
but hey, great to learn. I had assumed that the generics issue would get in 
the way of this - no autobean type can actually be generic, since when we 
turn the JS into actual Java types, we can't just cast at will - the 
interfaces are not backed by JSOs after all (until you look at Splittable, 
but that's a different story). The generator will give you nice errors if 
you attempt to register a generic type *other* than by wrapping an existing 
type.



The first problem I've run into is in adding a method like Java8's 
Collection.stream() or Collection.spliterator(). For Spliterator, for 
example, it attempts to generate a type emul.java.util.SpliteratorAutoBean, 
which means the method getComparator():
public class SpliteratorAutoBean extends com.google.web.bindery.autobean.
shared.impl.AbstractAutoBean {
  private final java.util.Spliterator shim = new java.util.Spliterator() {
public java.util.Comparator getComparator()  {
  java.util.Comparator toReturn = SpliteratorAutoBean.this.getWrapped().
getComparator();
  if (toReturn != null) {
if (SpliteratorAutoBean.this.isWrapped(toReturn)) {
  toReturn = SpliteratorAutoBean.this.getFromWrapper(toReturn);
} else {
  toReturn = new emul.java.util.ComparatorAutoBean(getFactory(), 
toReturn).as();
}
  }
  return toReturn;
}


So then a ComparatorAutoBean is generated, and in turn, it must have all of 
its method emulated. Unfortunately, it gets a few of these wrong 
(ABFGenerator doesn't think to avoid wrapping static methods):
public java.util.Comparator naturalOrder()  {
  java.util.Comparator toReturn = ComparatorAutoBean.this.getWrapped().
naturalOrder();
  if (toReturn != null) {
if (ComparatorAutoBean.this.isWrapped(toReturn)) {
  toReturn = ComparatorAutoBean.this.getFromWrapper(toReturn);
} else {
  toReturn = new emul.java.util.ComparatorAutoBean(getFactory(), 
toReturn).as();
}
  }
  ComparatorAutoBean.this.call("naturalOrder", toReturn );
  return toReturn;
}

This is solved easily enough by checking to see if a method is static as we 
iterate through and build up shims. However, this isn't sufficient to make 
the SpliteratorAutoBean sane. 



Quick reminder: methods in autobeans are in four varieties - GET, SET, 
SET_BUILDER, and CALL. SET_BUILDER is a SET that returns 'this' so you can 
have a nice builder api, and anything that doesn't look like a getter or a 
setter is made into a CALL. Here's a funny thing - 
Splitterator.getComparator() looks like a GET, not a CALL. 
Spliterator.getExactSizeIfKnown() also is a GET, but on the other hand, 
Spliterator.hasCharacteristics(int) is a CALL, since it has a parameter. 
This means that we a) descend and generate a ComparatorAutoBean type as 
above, but also that the AutoBeanVisitor wiring must be able to also 
descend into this. This introduces our second problem (in bold):
  @Override protected void traverseProperties(com.google.web.bindery.
autobean.shared.AutoBeanVisitor visitor, com.google.web.bindery.autobean.
shared.impl.AbstractAutoBean.OneShotContext ctx) {
com.google.web.bindery.autobean.shared.impl.AbstractAutoBean bean;
Object value;
com.google.web.bindery.autobean.gwt.client.impl.ClientPropertyContext 
propertyContext;
java.util.Spliterator as = as();
bean = (com.google.web.bindery.autobean.shared.impl.AbstractAutoBean) 
com.google.web.bindery.autobean.shared.AutoBeanUtils.getAutoBean(as.
getComparator());
propertyContext = new com.google.web.bindery.autobean.gwt.client.impl.
ClientPropertyContext(
  as,
  com.google.web.bindery.autobean.gwt.client.impl.ClientPropertyContext.
Setter.beanSetter(SpliteratorAutoBean.this, "comparator"),
  new Class[] 

[gwt-contrib] Re: Compiler failing with java 7

[Colin Alworth]

Switching to gwt-contrib, we're losing voices who are involved in this
discussion.

Maybe I am missing something, but I had that that the discussion moved
toward the fact that the compiler and dev mode will require Java8, but that
gwt-servlet could still be compiled to Java7, allowing deployment on Java7.

The supersource classes do require Java8 language level in the GWT compiler
(in order to have "default" mean anything), but these emulation classes are
not compiled to bytecode, and not required to compile the rest of GWT.

We already have cases where GWT will not work without Java8 (specifically
Dev Mode and anything that leans on it), so this isn't a change from the
beta. I agree with Daniel that effort will be required to compile to Java7
bytecode (as previously discussed), and while I would be interested in
helping to achieve this, we've also clearly stated that Java8 support is a
more important goal (both in terms of keeping GWT modern and up to date in
the Java world, but also in terms of staying relevant for web development
with lambdas and JSInterop).

Even if we manage to compile to Java7 bytecode from a Java8 JDK, it has
been encouraged that we extensively test to ensure that all of the code
does as we expect, as regressions have been seen in the past. RetroLambda
was another suggestion that also may have merit.

On Fri, Feb 12, 2016 at 10:28 AM Daniel Kurka <danku...@google.com> wrote:

> GWT 2.8 needs to contain Java8 APIs so taht guava will start working
> again. All the outstanding Java8 patches need to go in before 2.8. So 2.8
> will not work with Java7.
>
>
> On Fri, Feb 12, 2016 at 5:25 PM Jens Nehlmeier <jens.nehlme...@gmail.com>
> wrote:
>
>> Its not just about adding new classes but we also add APIs to existing
>> classes that require Java8 classes in their signature. So you would
>> need to ignore these changes on method level.
>>
>> AFAICT it was said that as soon as Java 8 APIs are committed GWT will
>> require Java8. If someone needs Java7 support they need to replace the
>> emulation code of GWT 2.8 with the one of GWT 2.7. Because of this
>> possibility we don't use Java8 APIs in gwt-user code. gwt-servlet.jar
>> is something to think about as soon as we want to add GWT-RPC
>> serializer for Java 8 classes. If we really want to give users the
>> possibility to compile GWT 2.8 with Java 7 after replacing the
>> emulation code we probably need a build target that builds
>> gwt-servlet-jdk8.jar when running Java8 only.
>>
>> Generally I thought Java8 stuff will be committed after GWT 2.8 has
>> been released so that GWT 2.8 stays Java7 compatible. I don't know
>> about the Guava issue that requires GWT 2.8 to already have Java8 APIs
>> available. I thought Guava will just release Guava 20 when 2.8 is
>> released because Gauva 19 did use some private APIs of GWT that do not
>> exist anymore.
>>
>>
>>
>> 2016-02-12 16:06 GMT+01:00 Daniel Kurka <danku...@google.com>:
>> > +Colin Alworth  +Jens
>> >
>> > Colin and Jens have been doing a lot of the Java8 API work, I believe
>> this
>> > will touch many classes within the JRE and thus will not be as easy as
>> > ignoring a few classes.
>> >
>> > To be clear:
>> > We won't be putting any resources into addressing this since its not an
>> > issue for us, if someone feels strongly (s)he can step up and tackle
>> this,
>> > but the whole case does not seem to be convincing for me, why would
>> agencies
>> > that are slow to adopt things adopt the latest GWT version?
>> >
>> > -Daniel
>> >
>> > On Fri, Feb 12, 2016 at 3:52 PM Manuel Carrasco Moñino <
>> man...@apache.org>
>> > wrote:
>> >>
>> >> Well the situation I know, is that there are many big companies and
>> >> government agencies moving very slow, their standard server
>> configuration is
>> >> java7, as well as their code standards.
>> >>
>> >> Their GWT projects are compiled in one phase (not client and server
>> >> sides). It could be very difficult for them to compile their byte code
>> for
>> >> 1.7.
>> >> It's true that if they don't use java 8 many features in 2.8 are
>> useless
>> >> for them, but we have to facilitate and encourage users to be in latest
>> >> version.
>> >>
>> >> I don't know how complex it could be, but if for example, ignoring
>> java8
>> >> /emul/ classes could fix the problem I think it's worth to consider.
>> >>
>> >> On Fri, Feb 12, 2016 at 3:42 PM, 'Daniel Kurka' via gwt-

Re: [gwt-contrib] Re: CSS Resources are not set in Panels in an iframe

[Colin Alworth]

As long as both $wnd and $doc exist in the frame where you plan on
creating/rendering widgets, it shouldn't matter how you create or find the
iframe. This should only mean that your frame must be created when that
line of bootstrap code executes, either because you created it there, or
because you found it.

On Fri, Jan 8, 2016 at 11:44 AM confile 
wrote:

> I could extend the CrossSiteIframeLinker and change:
>
> L413:   out.print("var $wnd = $wnd || window.parent;");
>
> to
>
>  out.print("var $wnd = $wnd ||  document.getElementById("myiframe");");
>
>
> But what do you mean by "an iframe created during "bootstrap"? Where do I
> create the iframe?
>
>
>
>
> Am Dienstag, 5. Januar 2016 18:40:28 UTC+1 schrieb Thomas Broyer:
>
>> Ideally, probably use a custom linker that makes it so that $wnd and $doc
>> point to an iframe created during "bootstrap" of the app.
>> Or as I said before, don't use widgets.
>
> --
> 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/2bf5cdc5-9108-45ac-911b-44995474f518%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/CADcXZMyKHytCTrSe4_30crX%2BkMvGNCRczDV9winitokb0OVKWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Remove unused code of external JavaScript file?

[Colin Alworth]

The short answer is yes, it can all go into one method, or several methods,
etc. The important part is "what does that JS expect to do", and how might
we accidentally break it by letting a compiler at it.

With that big of a file, I'm afraid I don't have time right now to take it
apart piece by piece and see what might break. Also, this is really the
wrong venue for a question not about contributing to GWT - I suggest
continuing on the regular GWT mailing list, a stackoverflow post, or in
gitter.im/project/gwt or in the ##gwt channel in freenode.

On Thu, Dec 31, 2015 at 4:38 AM confile <michael.gorsk...@googlemail.com>
wrote:

> Okay, When I put the code of the external JS file in a JSNI method. Do I
> have to put all the code I one method? To have a concrete example here is
> the code I use:
>
>
> https://github.com/Atmosphere/atmosphere-javascript/blob/master/modules/javascript/src/main/webapp/javascript/atmosphere.js
>
> Could you please give an example of how you would do it in this case?
>
>
> Am Donnerstag, 31. Dezember 2015 01:17:44 UTC+1 schrieb Colin Alworth:
>
>> It depends on how you are including the JavaScript source.
>>
>> If it is a 

Re: [gwt-contrib] Remove unused code of external JavaScript file?

[Colin Alworth]

It depends on how you are including the JavaScript source.

If it is a 

Re: [gwt-contrib] Re: GWT 2.8.0-beta1 available for testing

[Colin Alworth]

If I could be permitted to slight restate what Julien just said: We will
make a note of it, as we have done in the past, such as when the default
moved from java6 to java7:
http://www.gwtproject.org/release-notes.html#Release_Notes_2_6_0_RC1. That
being said, we of course welcome any community assistance in maintaining
GWT, and documentation is an excellent place to get started and make
significant contributions without going through the code review process
that GWT requires.

Java6 has been EOL'd for almost three years, though technically Java7 has
also reached that stage (last April). As long as we hang on to support for
Java6, we would be unable to use new classes/methods/features of Java7 (and
Java8), excepting the use of something like retrolambda like Thomas
suggested. We would likewise welcome any testing in that area after
performing an automated change to the gwt-servlet.jar. If you find problems
or discover that it works perfectly, and if you share the build scripts you
used to achieve it, that would make it easier to include these changes into
the official release.

On Mon, Dec 7, 2015 at 8:47 AM Julien Dramaix 
wrote:

> Feel free to fill a patch for that :)
>
> On Mon, Dec 7, 2015 at 2:28 PM István Horváth  wrote:
>
>> it would nice to have if you update the release notes page with exact
>> dates on all of the version on both the links and the linked details too.
>>
>> http://www.gwtproject.org/release-notes.html
>>
>>
>> 2015. december 4., péntek 10:51:13 UTC+1 időpontban Daniel Kurka a
>> következőt írta:
>>>
>>> Hi all,
>>>
>>> we just finished testing for GWT 2.8.0-beta1. You can either download it
>>> from goo.gl/62SeR5 or from maven central.
>>>
>>> Release notes can be found here
>>> 
>>> .
>>>
>>> Please start testing and let us know about any issues you encounter by
>>> either discussion here or filing bugs on github
>>> .
>>>
>>> -Daniel
>>>
>> --
>> 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/06401611-3eeb-4647-9fca-69459939aa8d%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/CABb_3%3D5%3DYLe_WNJbvc48mmfRO8Ds1WqqtDwNvhhPD3C66DJHpQ%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/CADcXZMxguUkafyvfEG%3DwtuMOoCEfchvenxyfDWxi07D39nvs%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.8.0-beta1 available for testing

[Colin Alworth]

Sorry, I hadn't understood that your primary interest was in release dates,
but though it was more for compatibility with upstream or related tools on
release. That said, I think that the list of downloads at
https://code.google.com/p/google-web-toolkit/downloads/list may prove
useful for historical release dates.

On Mon, Dec 7, 2015 at 9:42 AM István Horváth  wrote:

> i not sure about this link has the correct dates:
> https://en.wikipedia.org/wiki/Google_Web_Toolkit
> also it lacks of 2.5.0 and 2.5.1
>
> 2015. december 7., hétfő 16:40:22 UTC+1 időpontban István Horváth a
> következőt írta:
>>
>> good, where can i find exact dates about release dates (full date, like
>> year month and day) from the beginning?
>>
>
>>
>> 2015. december 7., hétfő 15:47:50 UTC+1 időpontban Julien Dramaix a
>> következőt írta:
>>
> Feel free to fill a patch for that :)
>>>
>>> On Mon, Dec 7, 2015 at 2:28 PM István Horváth  wrote:
>>>
 it would nice to have if you update the release notes page with exact
 dates on all of the version on both the links and the linked details too.

 http://www.gwtproject.org/release-notes.html

>>> --
> 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/b1cddc19-926a-4304-a583-6b0312cc82a4%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/CADcXZMzpwm1O-H9bFWrHn1gmrBhX8mpB1zujr8e7SH4KGv%3DrmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] I think the 2.7.0 GWT release was compiled on Daniel Kurka's machine !

[Colin Alworth]

This was also specific to .gwtar files, which will no longer be shipped
with the release. This also means the total size will drop, from around 30
mb to 16 mb.

On Mon, Nov 23, 2015 at 2:11 AM Arnaud TOURNIER  wrote:

> I confirm this is absolutely not a bug, and does not have any impact on
> production code...
> It was more a "fun fact"...
>
> Thanks
> Arnaud
>
> Le dim. 22 nov. 2015 17:48, Thomas Broyer  a écrit :
>
>>
>>
>> On Sunday, November 22, 2015 at 4:37:17 PM UTC+1, Niels Soeffers wrote:
>>>
>>> Hi Daniel, Arnaud,
>>>
>>> Did you managed to workaround or solve the above issue?
>>>
>>
>> Which issue? Arnaud said “There's no bug, nor problem on GWT side”
>>
>>
>>> I am having the exact same issue. Does this mean that the gwt-user 2.7
>>> jar in maven is useless?
>>>
>>
>> I hope almost everyone's using 2.7 by now. I've been using or toying with
>> those 2.7 artifacts for months and had no such problem.
>>
>>
>>> Kind Regards,
>>>
>>> Niels
>>>
>>> On Monday, July 6, 2015 at 9:34:59 AM UTC+2, Daniel Kurka wrote:

 It's not my desktop machine, but you are right I did the final
 compilation of the release. I thought we had already killed of gwttars
 anyway.

 On Thu, Jul 2, 2015, 11:21 AM Arnaud TOURNIER  wrote:

> Hi Daniel,
>
> I had a closer look to the thing. The paths mentionning your home
> account in google are stored in all the gwtar files in the gwt-user-2.7.0
> artifact
>
> Does that really mean that the offical gwt releases are built on your
> desktop machine ?
>
> Thanks
> Arnaud
>
> Le mer. 1 juil. 2015 à 18:42, Arnaud TOURNIER  a
> écrit :
>
>> It's a project of one of my customers which is on gwt 2.6 and needs
>> to migrate to 2.7.
>>
>> In the cours of doing that, i got this errors...
>>
>> If you need, i can investigate a bit more, but seems to be coming
>> from those [ERROR] java.lang.String cannot be resolved to a class...
>>
>> Thanks
>> ARnaud
>>
>> Le mer. 1 juil. 2015 à 18:20, 'Daniel Kurka' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> a écrit :
>>
>>> Hi Arnaud,
>>>
>>> how are you producing these?
>>>
>>> -Daniel
>>>
>>> On Wed, Jul 1, 2015 at 9:06 AM Arnaud TOURNIER 
>>> wrote:
>>>
 Just dumping a bit of errors i get for a project :

 Tracing compile failure path for type 'java.lang.Object'
 [INFO]   [ERROR] Errors in 'file:
 */usr/local/google/home/dankurka/gwt/user/super/co*
 m/google/gwt/emul/java/lang/Object.java'
 [INFO]  [ERROR] java.lang.String cannot be resolved to a
 type
 [INFO]   [ERROR] Errors in 'file:/usr/local/google/home/
 *dankurka*
 /gwt/user/src/com/google/gwt/core/client/JavaScriptObject.java'
 [INFO]  [ERROR] java.lang.String cannot be resolved to a
 type
 [INFO]   [ERROR] Errors in 'file:/usr/local/google/home/
 *dankurka*
 /gwt/user/super/com/google/gwt/emul/java/lang/Throwable.java'
 [INFO]  [ERROR] java.lang.String cannot be resolved to a
 type
 [INFO]   [ERROR] Errors in 'file:/usr/local/google/home/
 *dankurka*/gwt/user/super/com/google/gwt/emul/java/lang/Class.java'

 There's no bug, nor problem on GWT side. I just found funny to get
 those kind of paths in a release artifact !!

 Thanks

 Arnaud

 --

>>> 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/4a744841-48ca-4a75-a5e4-91ba966aea80%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
>>> 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/SyRZzSQeDWg/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
>>> 

Re: [gwt-contrib] GWT 2.8 RC1

[Colin Alworth]

Paul, do keep in mind that the latest in git (and the 2.8.0-SNAPSHOT in
maven) is fairly stable. Some projects (for example, everything that Google
makes) live off of trunk, and many projects upgrade to a snapshot, test
that things are sane, and then 'pin' that build internally to keep running
with it until they decide to update again.

On Wed, Oct 28, 2015 at 8:57 AM Seamus McMorrow 
wrote:

> To try to speed up the fix, maybe if people voted for the issue, it may
> help.
> I just cast my vote to get it fixed.
>
>
> On Wednesday, 28 October 2015 12:53:17 UTC, Paul Robinson wrote:
>>
>> Speaking for myself, a GWT 2.8.0 release that works, but uses too much
>> memory compiling code, to be followed by GWT 2.8.1 with the memory fix, is
>> better than waiting for an unknown amount of time until JDT is fixed.
>>
>> On Wed, Oct 28, 2015 at 8:46 AM, 'Goktug Gokdogan' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>
>>> Hey guys.
>>>
>>> We are planning to make the release cut by next Monday to start testing
>>> sooner. Hopefully by the time we will complete most of the critical pieces
>>> for JsInterop.
>>>
>>> Also FYI, JDT has a huge memory problem with Java8
>>>  so doing a final
>>> release without a fix may make the release less useful for a lot of people.
>>> Let's hope that gets fixed soon.
>>>
>>> --
>>> 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%3DyUA1Se5eNCNjwS5F8c-wzc7BYqd0rWY%2Bq--Yg9cP7353UnA%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/0856-c756-4493-936d-41be54f8d33d%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/CADcXZMyM%3DZut%3DHky4hcWunWZL0WWmH%2B0xNDY5KrshM8k4F48wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Bug in 2.8.0-Snapshot

[Colin Alworth]

As this isn't a NPE (or a type error, which I think is the JS equivalent),
the we're missing a step here. You are seeing an UmbrellaException thrown,
which means not that the handlermanager or event wiring broke, but that
your own handler threw the exception (i.e. the 'TypeError' described in the
wrapper).

That trace is kept in the umbrella exception, and will likely be necessary
to figure out what the real issue is.

Also, the stack below the anon function won't be useful, that's very likely
the wiring that calls into the widget event handling from the dom.

On Thu, Jul 9, 2015 at 10:08 PM Ali Akhtar ali.rac...@gmail.com wrote:

 In 2.8.0-SNAPSHOT, when the ValueChangeEvent is triggered for a dropdown,
 I'm encountering the following stack trace:

 Uncaught com.google.gwt.event.shared.UmbrellaException: Exception caught:
 Exception caught: (TypeError) : Cannot read property
 'java_util_LinkedList_size' of undefined


 com_google_gwt_event_shared_HandlerManager_$fireEvent__Lcom_google_gwt_event_shared_HandlerManager_2Lcom_google_gwt_event_shared_GwtEvent_2V


 com_google_gwt_user_client_ui_Widget_$onBrowserEvent__Lcom_google_gwt_user_client_ui_Widget_2Lcom_google_gwt_user_client_Event_2V

 _.onBrowserEvent__Lcom_google_gwt_user_client_Event_2V

 _.onBrowserEvent__Lcom_google_gwt_user_client_Event_2V


 com_google_gwt_user_client_impl_DOMImplStandard_dispatchEvent__Lcom_google_gwt_user_client_Event_2V

 (anonymous function)


 This only happens in production, in SDM it works without any issues.

 I'm not sure which line specifically causes this, because the stacktrace
 stops at the anonymous function. But, it seems to be around where I'm
 creating an autobean object. The first line of my event handler which shows
 a loading message, seems to get executed fine.

 Would appreciate a speedy resolution to this, as this is in production.
 Thanks.

 --
 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/f4b201e1-5a00-4681-a4ac-3505d7bbc291%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/f4b201e1-5a00-4681-a4ac-3505d7bbc291%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 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/CADcXZMxS%3D7pNHH%3DqHBsY3grOA3jUdq6P%2BPn2asgLGJmGJ-87Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Java to WebAssembly Compiler

[Colin Alworth]

Without GC, I think its going to be a bit of a non-starter - the same
issues that apply to compiling to asm.js apply here too. I've heard a few
ideas floated around to just compile specific methods to asm.js, and those
same ideas seem that they could work, but the really hard part is isolating
these pieces of code, and at least for asm.js, you can actually take a
significant performance hit from moving data into (or even just allocating)
typed arrays. If you can tune the feature to how you'll need it (i.e. only
ask the compiler to turn it on if you'll keep them around for a long time
and have very hot code running through there) it seems worth it, but at
that point JSNI or JsInterop might almost be easier to talk to raw JS (or
WebAssembly) to guarantee that you get it right.

That said, GC is an eventual design goal in WebAssembly, so I think GWT or
something like GWT could make it an eventual target.

/2cents

On Mon, Jun 22, 2015 at 2:03 PM Joel Handwell joelhandw...@gmail.com
wrote:

 - Luke Wagner wrote a post on his blog to report that his team at Mozilla
 have started working with Chromium, Edge and WebKit engineers on creating a
 new standard, WebAssembly, that defines a portable, size- and
 load-time-efficient format and execution model specifically designed to
 serve as a compilation target for the Web.

 - Google's JF Bastien mentions
 https://github.com/WebAssembly/design/commit/34318807a17cb43d79e8cf5939319e5b4909dc6d
 GWT in the design document of WebAssembly as a better execution for
 languages and toolkits that are currently cross-compiled to the Web.

 Given this context, how do you think about considing building Java to
 WebAssembly compiler?

 --
 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/f9c423c0-bda2-4018-b7e1-9f56f3a34d73%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/f9c423c0-bda2-4018-b7e1-9f56f3a34d73%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 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/CADcXZMx%3D6Rr-rBdt%3Dym2uf9t-ouP9v-KvJxdErm94XNudbwbyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GWT2.8 JsInterop Java-JS

[Colin Alworth]

I'm sorry you haven't gotten this working, but posting incomplete examples
makes it hard to help. This is still considered an experimental feature,
though it is used in production both inside of Google and outside.

Js.js is a proposed new JSNI, and is not required to do anything - the goal
is to replace jsni/jsos entirely, and after JsInterop is complete and
finalized, jsni may follow jsos out the door with something like Js.js. If
memory serves, Js.js was implemented with a generator that simply created
JSNI methods, but again, you don't need it.

Did you try my example? As I said, it does seem to work, and while your
incomplete example may not be working yet, without knowing what you are
trying, that doesn't mean GWT is the problem.

With regard to analogs for array, etc, there are a lot of basic objects
that have to be implemented. Once the annotations and code generation is
finalized, a so-called 'elemental 2.0' is planned, where interfaces will be
generated based on JS and browser specs.

in the interim, in the same way that JSNI can still let JS code live in a
GWT/Java project, JSOs can still be used - JsArray is a legit way to
reference js collections. Even with JsInterop, from what I understand
between JS and Java, the upcoming JsInterop+elemental types won't be able
implement java.util collection interfaces anyway, at least not without
language level support for them directly. Not to say that this isn't
planned, but that without it, any existing analogs will be as weak as
JsArray itself, a existing, perfectly capable class.

On Tue, May 19, 2015 at 8:31 PM Alex W alexwhite3...@gmail.com wrote:

 It uses @JsType @JSExport and also implements Serializable. I already
 mentioned I was using those so I didn't put that in when I sanitized the
 code since we are not allowed to pastie actual work code. As a user in js,
 I would expect that all those types would have js analogs in js under their
 respective java.lang namespace. There are various Big Integer js libraries
 on github for example.

 Looking at Ray Cromwell's slides I noticed there is a (vapour) reference
 to a Js.js(...) class that might do what I want. Apparently, it doesn't
 exist. Oops. At the risk of sounding snarky, GWT is a poorly run project,
 consistently overpromising and underdelivering.

 On Wednesday, May 20, 2015 at 12:18:41 AM UTC+10, Colin Alworth wrote:

 JSON.stringify will try to serialize the js objects to a json string as
 best it can (ignoring cycles, and non-json data like methods).

 At the risk of sounding snarky, you know that class won't work in
 JsInterop, right? For a start, its missing its @JsType! ;)

 Next, some of these fields can't cleanly be passed between Java and JS -
 for example JS has no long type (will truncate to double precision, GWT
 emulates long), and a Java List? needs to be a type that exists in JS
 (either JsArray, or some jsinterop-annotated type that maps to what JS
 understands). This I'm less sure about, but at least historically boxed
 types like Boolean were never supported - the primitive type boolean has to
 be used instead.

 Here's a very quick sanity check that I wrote to verify that this is
 working more or less as expected:
 public class SampleEntryPoint implements EntryPoint {
   public void onModuleLoad() {
 MyData data = new MyData(Colin, 123);
 Window.alert(stringify(data));
   }

   public static native String stringify(Object obj) /*-{
 return $wnd.JSON.stringify(obj);
   }-*/;

   @JsType
   public static class MyData {
 public String name;
 public int age;
 public MyData(String name, int age) {
   this.name = name;
   this.age = age;
 }
   }
 }

 On startup this does indeed output {name:Colin,age:123}, though if
 you remove the @JsType annotation, it just outputs {} since GWT doesnt see
 any code using the fields, so it optimizes them out.

 Live code:

 https://viola.colinalworth.com/proj/1975c89afc330c0bb55d8fd7d4001fd1/project/client/SampleEntryPoint.java

 This is however using a version of GWT 2.8 that is a few weeks old, I'll
 update later today and reverify.

 On Tue, May 19, 2015 at 12:11 AM Alex W alexwh...@gmail.com wrote:

 The '_1_g$' indicates you are in super dev mode - does it work correctly
 when fully compiled to JS (draft or no)? I saw a problem in this area a few
 weeks ago.


 No it doesn't work when it's fully compiled to JS either.

 Also, can you post the full definition for MyObject?



 class MyObject {
 private String str1;
 private String str2;
 private boolean b1;
 private boolean b2;
 private boolean b3;
 private boolean b4;
 private boolean b5;
 private boolean b6;
 private int size;
 private String str3;
 private Boolean b7;
 private String str4;
 private int numb1;
 private long uid;
 private Boolean b7;
 private ListMyOtherObject objs;

 }

 I agree with Alberto though, your printObj doesn't make any sense as is
 - it is calling the java

Re: GWT2.8 JsInterop Java-JS

[Colin Alworth]

JSON.stringify will try to serialize the js objects to a json string as
best it can (ignoring cycles, and non-json data like methods).

At the risk of sounding snarky, you know that class won't work in
JsInterop, right? For a start, its missing its @JsType! ;)

Next, some of these fields can't cleanly be passed between Java and JS -
for example JS has no long type (will truncate to double precision, GWT
emulates long), and a Java List? needs to be a type that exists in JS
(either JsArray, or some jsinterop-annotated type that maps to what JS
understands). This I'm less sure about, but at least historically boxed
types like Boolean were never supported - the primitive type boolean has to
be used instead.

Here's a very quick sanity check that I wrote to verify that this is
working more or less as expected:
public class SampleEntryPoint implements EntryPoint {
  public void onModuleLoad() {
MyData data = new MyData(Colin, 123);
Window.alert(stringify(data));
  }

  public static native String stringify(Object obj) /*-{
return $wnd.JSON.stringify(obj);
  }-*/;

  @JsType
  public static class MyData {
public String name;
public int age;
public MyData(String name, int age) {
  this.name = name;
  this.age = age;
}
  }
}

On startup this does indeed output {name:Colin,age:123}, though if
you remove the @JsType annotation, it just outputs {} since GWT doesnt see
any code using the fields, so it optimizes them out.

Live code:
https://viola.colinalworth.com/proj/1975c89afc330c0bb55d8fd7d4001fd1/project/client/SampleEntryPoint.java

This is however using a version of GWT 2.8 that is a few weeks old, I'll
update later today and reverify.

On Tue, May 19, 2015 at 12:11 AM Alex W alexwhite3...@gmail.com wrote:

 The '_1_g$' indicates you are in super dev mode - does it work correctly
 when fully compiled to JS (draft or no)? I saw a problem in this area a few
 weeks ago.


 No it doesn't work when it's fully compiled to JS either.

 Also, can you post the full definition for MyObject?



 class MyObject {
 private String str1;
 private String str2;
 private boolean b1;
 private boolean b2;
 private boolean b3;
 private boolean b4;
 private boolean b5;
 private boolean b6;
 private int size;
 private String str3;
 private Boolean b7;
 private String str4;
 private int numb1;
 private long uid;
 private Boolean b7;
 private ListMyOtherObject objs;

 }

 I agree with Alberto though, your printObj doesn't make any sense as is -
 it is calling the java toString() method on the object rather than
 serializing to JSON, or do you expect MyObject.toString() to return a json
 string?


 I thought JSON.stringify(...) would stringify the (assumed) JSON object.
 I'm not really sure what's going on under the hood, but I don't really
 understand why/how it doesn't.

 --
 You received this message because you are subscribed to a topic in the
 Google Groups Google Web Toolkit group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/google-web-toolkit/ZCayeP1c5c0/unsubscribe
 .
 To unsubscribe from this group and all its topics, 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 http://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 
Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT2.8 JsInterop Java-JS

[Colin Alworth]

The '_1_g$' indicates you are in super dev mode - does it work correctly 
when fully compiled to JS (draft or no)? I saw a problem in this area a few 
weeks ago.

Also, can you post the full definition for MyObject?

I agree with Alberto though, your printObj doesn't make any sense as is - 
it is calling the java toString() method on the object rather than 
serializing to JSON, or do you expect MyObject.toString() to return a json 
string?

On Friday, May 15, 2015 at 2:54:32 AM UTC-5, Alex W wrote:

 I tried that, it gave me the same result, but your post gave me an idea. I 
 set printObj up to assign a variable with it's data, so the last element in 
 the list would get it.

 Inside 
 ns.printObj = function(data) {
ns.foo = data;
 }

 Then I typed ns.foo into chrome's dev console so I could introspect the 
 object that way. It turns out that the data is there, but it's all mangled 
 with funny symbols like
 kRg_g$ {  mySymbol_1_g$  } etc. Can anyone on the GWT team weigh in and 
 tell me how to unmangle it, such that I can write my views in JS and my 
 model/controller in java? 

 On a side note, it would be really nice if there was a nice no-brainer way 
 of serializing/deserializing between JSON and Java Objects exposed to gwt 
 users. This has always been a huge feature hole in gwt imo.

 Thanks
 Alex


 On Friday, May 15, 2015 at 5:09:50 PM UTC+10, Alberto Mancini wrote:

 the object has properties but when you concatenate a string with your 
 object in the line
 We can't see the obj's properties, only: + obj  
 you are essentially converting obj to a string through obj.toString() so 
 your 
 native method does not receives the object obj but a string.

 try this passing just obj to printObj.

 A.
  

 On Fri, May 15, 2015 at 8:57 AM Alex W alexwh...@gmail.com wrote:

 Wouldn't the object have a bunch of JSON properties then?


 On Friday, May 15, 2015 at 4:47:39 PM UTC+10, Alberto Mancini wrote:

 Hi,
 you are converting obj to a string before calling printObj:  We can't 
 see the obj's properties, only: + obj 

 Hope this helps.
Alberto. 


 On Fri, May 15, 2015 at 7:52 AM Alex W alexwh...@gmail.com wrote:

 We are usingJSInterop in GWT2.8. In one of our RPCs we have some code 
 like this that passes our java object to JS:
 onSuccess(ListMyObject objs) {  
for (MyObject obj: objs) {
  jsCode.printObj(We can't see the obj's properties, only: + obj);
   }
 }
 The definition of jsCode looks like this:
 ns.printObj = function(obj) {
console.log(JSON.stringify(obj));
 }
 In the console we get back: 
 We can't see the obj's properties, only:our.ns.type.MyObject@16 

 The value object has been annotated as @JsType. Anything else we need 
 to do?



-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Open reviews

[Colin Alworth]

There is a document outlining which maintainers exist for various parts of
GWT, designed to suggest an initial reviewer or reviewers for a new
patch/bugfix/feature.

https://docs.google.com/document/d/1vyncxfuujIJ3L-PBLNM68tfeXRFZ4qDdnWEodblmvRg/edit

This list is in the top (stickied) post in gwt-contrib, and should be
consulted to see who should be assigned to check out a patch.

On Fri, May 15, 2015 at 2:23 PM Juan Pablo Gardella 
gardellajuanpa...@gmail.com wrote:

 Any thoughts? Who are able to take reviews?

 On 12 May 2015 at 18:35, Richard Wallis rdwal...@gmail.com wrote:

 Anyone want to review my patch to the scheduler?
 https://gwt-review.googlesource.com/#/c/11510/

 Also it would be good if patches automatically had someone assigned to
 review them.  If the patch falls outside a reviewer's domain then they can
 transfer it to someone else.


 On Tue, May 12, 2015 at 11:16 PM, Juan Pablo Gardella 
 gardellajuanpa...@gmail.com wrote:

 Hi contributors,

 I would like to thanks for your great work and for the passion that you
 put on GWT. I know you are very busy but it's frustrating to spend time in
 some patch and then nothing happen. There are a lot of open reviews
 https://gwt-review.googlesource.com/#/q/status:open. That kind of
 things prevent developers to spend time in patches in the future.

 I say that because I want more contributions for GWT.

 Regards,
 Juan

 --
 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/CA%2BkiFse4iTAoZUKzyaq-4iVFznXXkPM9k1nEfd6-tsQutuk7zg%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2BkiFse4iTAoZUKzyaq-4iVFznXXkPM9k1nEfd6-tsQutuk7zg%40mail.gmail.com?utm_medium=emailutm_source=footer
 .
 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/CAEqaEVhfxgWe450NCqDxEh2ENZLksSxMY5nwj%3D8-9hR3e85zEQ%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEqaEVhfxgWe450NCqDxEh2ENZLksSxMY5nwj%3D8-9hR3e85zEQ%40mail.gmail.com?utm_medium=emailutm_source=footer
 .
 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/CA%2BkiFsff3efEF6KSGD%2BdvwSY0mQnwvHG%3Djx8xR%2BmT6tAr0%3DY9A%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2BkiFsff3efEF6KSGD%2BdvwSY0mQnwvHG%3Djx8xR%2BmT6tAr0%3DY9A%40mail.gmail.com?utm_medium=emailutm_source=footer
 .
 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/CADcXZMyybkBrELFL7%2BOcQ1kffQukSZC_RD6x%2Bc5wPGXtjR%2BzsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Jsni on String methods in GWT 2.7

[Colin Alworth]

Getting offtopic, but there is absolutely no requirement that JSO methods
are public. See dom.client.Element for several examples of private methods.

On Mon, Mar 30, 2015 at 10:27 PM James Nelson ja...@wetheinter.net wrote:

 Ok, great.  Thanks for the heads up.  I was pretty sure that Strings had
 become native first-class objects.

 Since JSOs will all have public methods, I will be safe with the same fix
 for String (not using JSNI if not necessary).
 Given that java arrays only have one field, and that field does not work
 in JVM reflection, nor do any of the Object methods, I'll leave them alone
 (that's what java.lang.reflect.Array is for)...

 Added issue
 https://code.google.com/p/google-web-toolkit/issues/detail?id=9166 to
 track this.

 For posterity and search indexing, if anyone tries to use hashCode, equals
 or compareTo on String or Array in JSNI and are getting undefined reference
 errors, use a static method instead.

 --
 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/9bbd9127-65c9-4fa1-9743-a94fcd4f3bf4%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/9bbd9127-65c9-4fa1-9743-a94fcd4f3bf4%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 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/CADcXZMyfTkw5Kfm0DXeMLH8%3DXBwFzb1W3qO1xKmGQ%3DjT-w-YGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Java8 emulation

[Colin Alworth]

The trick seems to be that it is not going to be possible to add Java8 emul
code without actually using Java8 - while lambdas can be avoided, defender
methods cannot. If you need to provide a new interface like Consumer, the
supersource *must* have the `default` method(s), or it won't actually be
Consumer.

If it were just those types, it would be possible to move them into their
own module so developers would need to inherit's the Java8 module to get
access to them, but the Collection interface itself needs to be changed to
add `default StreamE stream()`, plus the implementation, or else all
implementors of Collection (and Set and List) need to have an
implementation added. Even then, Stream would need to be emulated, which
references Consumer, so we can't have it be a separate module...

...or am I over-complicating matters?

On Wed, Mar 25, 2015 at 10:20 AM John A. Tamplin j...@jaet.org wrote:

 On Wed, Mar 25, 2015 at 11:16 AM, Jens jens.nehlme...@gmail.com wrote:

 whats the current situation of adding Java8 emulations to GWT?

 I would like to fix the current emulation of @FunctionalInterface (wrong
 package and missing imports), add java.util.Optional[Int|Long|Double]
 emulation and like to see java.util.function interfaces in trunk committed.
 That would allow us to further work on stream API emulation which would be
 nice to have in GWT 2.8, right? Just having Java8 syntax support seems a
 little weak to me for a new release.


 Adding new classes should be pretty straightforward.


 Currently my patch for java.util.function can not be verified by Jenkins
 because it runs the presubmit task with sourceLevel 1.7 (and Java7 I
 think). So I assume that the next GWT release should be compatible to
 Java7.

 Does this mean that any emulation of Java8 APIs should be done using
 Java7 syntax ( = no lambdas in emulation code) ? What about default methods
 in emulated code when people use JDK 7 with GWT?


 That would be my vote - we don't want to force people to use Java8 just
 yet.

 --
 John A. Tamplin

 --
 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/CAM5k6X-xtnTX_xXPPr4M9AsFP_qNQHZU_9k_VJP5o4ZjLYknWw%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X-xtnTX_xXPPr4M9AsFP_qNQHZU_9k_VJP5o4ZjLYknWw%40mail.gmail.com?utm_medium=emailutm_source=footer
 .
 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/CADcXZMxJV4ES0SiMeDsMSaw9zrPCZhYq2sTkJoZVgcpxF59%2BHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: What constitutes an acceptable emulated String.format implementation?

[Colin Alworth]

I'd be strongly in favor of a StringFormat class - this could be
library-ized easily, letting someone opt in to even having it in their
project, or call it.

Since we're changing the API (though I assume keeping the 'format string'
language), you could take other steps to ensure small complied size and
best runtime performance. Consider SafeHtmlTemplates or Messages, with
their abilities to interpolate strings, but knowing the format string to
use at compile-time, not runtime.

This probably won't work in all cases (or be especially nice to use in the
other cases), but will be faster and smaller when compiled to JS.

On Tue Feb 10 2015 at 8:07:22 AM Benjamin DeLillo bpd9...@gmail.com wrote:

 If trying to provide a fairly complete duplicate of the JRE functionality
 is too much of a point of contention, would it be more acceptable to
 provide a simpler/lighter-weight string interpolation implementation behind
 e.g. GWT.format() or to follow the NumberFormat convention a StringFormat
 class?


 On Friday, February 6, 2015 at 11:31:32 PM UTC-5, Benjamin DeLillo wrote:

 For an implementation to be accepted would it have to conform to the entire 
 Java Formater spec? 
 http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html

 Would an implementation lacking the Date/Time conversions be acceptable?

 Would an implementation that wraps sprintf.js be acceptable (if the 
 licensing is compatible)? https://github.com/alexei/sprintf.js


 What about a minimal positional substitution implementation and nothing more?

  --
 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/9d1583ef-ae7b-41e2-9eca-207e8ef33062%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/9d1583ef-ae7b-41e2-9eca-207e8ef33062%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 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/CADcXZMw1W_q866X0R2h8eJGWzU2Wx%2B_u62i_MAVuthEGEbnWNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?

[Colin Alworth]

Its not that 3k is huge, its that it would be (to a developer, accustomed
to GWT's policies) massively larger than normally expected for built-in
methods. Just ran SOYC on a project (OBF but not closure), and the largest
java.lang.String method is 466 bytes, greater than twice the size of the
next biggest method. The entire class is only 1,749 bytes, and the entire
java.lang (for this project) is 10,535 bytes.

Adding String.format, once, using only %s to substitute in strings easily,
would add 30%.

On Mon Feb 09 2015 at 8:26:49 AM Benjamin DeLillo bpd9...@gmail.com wrote:

 Dan,

 Thanks for the response.

 sprintf.js is 3kB minified and 7.5kB uncompressed weighing in at just
 under 200 LoC, you mention this would be too big. Just how small would an
 implementation have to be to be acceptable? How large are other JRE
 emulation implementations by comparison? I spoke with Ray at GWT.Create
 2013 and his take on this was that although String.format was originally
 excluded from GWT for codesize reasons, that in today's browser/internet
 ecosystem the hit would be acceptable.

 I do agree that any less than complete implementation needs to have as
 obvious a failure mode as possible for when it diverges from String.format
 canon, and must be well documented and easy to find. How do other JRE
 emulation implementations handle this kind of divergence? Or do they avoid
 such divergence at all costs?



 On Monday, February 9, 2015 at 5:13:38 AM UTC-5, Daniel Kurka wrote:

 Hi Benjamin,

 thanks for reaching out to us. Answers are inline.


 On Sat, Feb 7, 2015 at 5:31 AM, Benjamin DeLillo bpd...@gmail.com
 wrote:

 For an implementation to be accepted would it have to conform to the entire 
 Java Formater spec? 
 http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html

 I think supporting the entire java spec is impossible since we do not
 have Locale working (for codesize reasons). So we would need to discuss
 what a good subset would be


 Would an implementation lacking the Date/Time conversions be acceptable?

 Would an implementation that wraps sprintf.js be acceptable (if the 
 licensing is compatible)? https://github.com/alexei/sprintf.js

 I briefly skimmed the lib and it seems huge, so I am inclined to say no.
 In general you have to think about that any application will have the hit
 of that method in their app as soon as they call String.format one time in
 their code base.



 What about a minimal positional substitution implementation and nothing 
 more?


 Right now any code that relies on String.format will not compile in GWT
 and thus give the author a clear indication of having a problem. Once we
 support a subset this compile error might be gone, but we will be
 introducing runtime errors for not supported features rather than compile
 time errors.

 One could try to deal with these (and this is bad from the compiler
 perspective), by looking at the parameters of String.format and only allow
 statically resolvable arguments for the format String that are supported by
 the emulation, but this is a very tight coupling of compiler and lib that
 we do not want in the compiler.

 So if we want to do a minimal support of String.format these are the
 kinds of problems we need to discuss.



  --
 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/bc6afdc0-eb87-
 4815-b076-6db912f8f94c%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/bc6afdc0-eb87-4815-b076-6db912f8f94c%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




 --
 Google Germany GmbH
 *Dienerstr. 12*
 *80331 München*

 Registergericht und -nummer: Hamburg, HRB 86891
 Sitz der Gesellschaft: Hamburg
 Geschäftsführer: Graham Law, Katherine Stephens

  --
 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/fa54c87b-c54b-4c8d-87f9-ff234c04cc35%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/fa54c87b-c54b-4c8d-87f9-ff234c04cc35%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 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 

Re: [gwt-contrib] Possible compiler bug in 2.7 ignoring a set-property

[Colin Alworth]

I don't recall if inherited modules are loaded more than once - in other
words, if one of the higher up modules (like BaseGWT) already inherited
BaseBrowsers, then a later module added ie10 via extend-property, it might
not be possible to re-inherit BaseBrowsers and have it re-set user.agent
down to just those two.

I don't know if this is actually the case or not, but it might make sense,
since otherwise you could run in circles inheriting modules that inherit
each other. Instead, I always encourage developers to list their inherits
first, then their own specific overrides. Don't think of a module file like
a function call, since that could lead to recursion and other fun issues,
think of them more as dependencies.



On Wed Feb 04 2015 at 10:06:19 AM Jan Thewes janthe...@gmail.com wrote:

 Hey guys,

 I've found what I think is a bug in GWT2.7.
 We're trying to compile the attached file 'MyMegaModule.gwt.xml'
 The last inherit in this file is BaseBrowsers.gwt.xml - I've attached that
 too.
 In the BaseBrowsers.gwt.xml you can see that we only want gecko and safari
 compilations but when compiling we get an ie10 permutation too.
 There might be other inherits that are setting the user.agent property to
 something including the ie10 but because of our BaseBrowsers.gwt.xml being
 inherited as the last module we should only get gecko and safari, am I
 right?

 I've no idea how to fix this.

 Thx for any ideas!

 Cheers,
 Jan

 --
 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/ac5c7e23-fd85-46d6-883b-8f8600c496cb%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/ac5c7e23-fd85-46d6-883b-8f8600c496cb%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 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/CADcXZMw_tXtEtOBOuU2t_v2bf%3DAARYkOj%3DcTY78Mu2jWRaUL2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] support for JSR 310 / java.time created

[Colin Alworth]

Are you planning on being at either GWT.create event? I know several people
(including myself) who will be there and would be happy to help.

Otherwise, there are several contributors in ##gwt on irc.freenode.net who
would be able to help with this process.
On Mon Jan 19 2015 at 4:44:01 AM Salvador Diaz diaz.salva...@gmail.com
wrote:

 For those looking for the code, I found it was moved to an independent
 project, which I'm hoping should make it easier to integrate in the patch
 submission process:
 https://github.com/m-m-m/gwt-time

 I'm willing to take some time to move this forward, either working with
 Jörg or alone, could anyone walk me through the steps needed to make it
 happen ?


 On Wednesday, March 5, 2014 at 11:41:59 PM UTC+1, Daniel Kurka wrote:

 @Joerg could you start setting up a patch for review in gerrit?



 On Monday, December 9, 2013 10:20:54 PM UTC+1, Jörg Hohwiller wrote:

 http://code.google.com/p/google-web-toolkit/issues/detail?id=8486

  --
 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/42c41c35-0d05-4448-91f3-e2e0cc685f44%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/42c41c35-0d05-4448-91f3-e2e0cc685f44%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 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/CADcXZMzc_OHHNxLQSQ%3D6HJq6c%3DuQrjGzsD8BCb7P9OZxrko-SQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GWT compile fails with default Maven directory structure

[Colin Alworth]

It sounds like you have non-gwt-capable classes in packages meant for GWT - 
is that deliberate? For example, test classes to make sure the various 
server components in your project work, but they are in your .client or 
.shared package?

If they are not, then GWT will totally ignore them, as no .gwt.xml as 
indicated that those packages are able to be compiled at all.

On Thursday, November 20, 2014 11:05:27 AM UTC-6, Phineas Gage wrote:

 I'm in the process of Maven-izing my GWT 2.6.1 project (an intermediate 
 step to start using GWT 2.7.0), and as a first step want to switch to maven 
 style directory structure (as suggested by the Maven GWT Plugin 
 documentation 
 http://mojo.codehaus.org/gwt-maven-plugin/user-guide/project.html), so 
 I make two simple moves:

 [project]/src = [project]/src/main/java

 [project]/test = [project]/src/test/java

 But what happens when I do this is that the regular GWT Compile from the 
 Google Plugin for Eclipse fails with the -strict option, because it tries 
 to compile my test classes as GWT source code, and of course can't find the 
 classes they reference, for example (source files names obfuscated with 
 extra ...'s):

   [ERROR] Errors in 'file:/.../src/test/java/.../...Test.java'
  [ERROR] Line 20: No source code is available for type 
 org.junit.Assert; did you forget to inherit a required module?
   (... repeated with many other files)

 I'm confused because this doesn't happen with my old directory structure, 
 and I don't know why the GWT compiler would go back up into my test 
 directory to compile classes there. Strangely, it also doesn't happen with 
 this structure, which I accidentally moved to once:

 [project]/src = [project]/src/java/main

 [project]/test = [project]/src/java/test

 It almost seems like the GWT compiler is doing something special with the 
 default Maven directory structure. And any of the solutions I can think of 
 are not very clean:

 - Not use the Google Plugin for Eclipse, but only use the Maven GWT 
 Plugin, but then I lose some features from the Google Plugin for Eclipse 
 that I want
 - Not compile with -strict, but then I don't catch other warnings as easily
 - Use an exclude in my *.gwt.xml source paths to exclude **/*Test.java, 
 but then I might still catch some unintended utility classes in my test 
 package
 - Not use a parallel package structure for my tests, but then it's not 
 possible to test package protected classes and methods
 - Not make [project]/src/test/java a source directory in Eclipse, but I 
 don't know what the side effects of that are

 How are people handling this, or am I missing something?


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upgrade 2.7 beta1 to rc1 - browser refresh and change detection not working

[Colin Alworth]

It is also possible that there is a stale copy of .java resources on your
classpath, such as in target/classes/ for a maven project - we've seen that
get in the way as well. Make sure that either target/classes/ isn't on your
classpath, or that it doesn't have another (stale) copy of whatever you are
trying to compile.
On Thu Oct 30 2014 at 10:40:52 AM Jens jens.nehlme...@gmail.com wrote:

 I assume you have deployed an old module.nocache.js file. Try a clean
 start by deleting your /war/modulename folder and restart DevMode. A new
 module.nocache.js file should be generated (could take a bit as the
 CodeServer needs to start before this file gets generated) which
 automatically recompiles your app each time you refresh the browser.

 -- 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/0254ed3a-fbff-4b8f-b7f3-31997d32c2d4%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/0254ed3a-fbff-4b8f-b7f3-31997d32c2d4%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 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/CADcXZMwR3WUSpEvVoGfW%2BYo%2B2LW_vMinRKJyxUsu4bW_hHROjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSA: starting unbundling dependencies from gwt-dev published to Maven Central, could break your build

[Colin Alworth]

Looks like codehaus's snapshot repo is down, so I'm unable to get the 
latest gwt-maven-plugin. This url gives a 504 gateway timeout from ngnix 
for me:
https://nexus.codehaus.org/content/groups/snapshots-group/org/codehaus/mojo/gwt-maven-plugin/2.7.0-SNAPSHOT/maven-metadata.xml

If I set gwt-user and gwt-servlet to 2.7.0-SNAPSHOT and gwt-maven-plugin to 
2.6.1, I get the NoClassDefFoundError:

[INFO] Caused by: java.lang.ClassNotFoundException: org.objectweb.asm.
MethodVisitor
[INFO] at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
[INFO] at java.security.AccessController.doPrivileged(Native Method)
[INFO] at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
[INFO] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
[INFO] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
[INFO] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
[INFO] ... 62 more
[INFO] 

[INFO] BUILD FAILURE
[INFO] 

[INFO] Total time: 4.640s
[INFO] Finished at: Thu Oct 16 17:28:18 CDT 2014
[INFO] Final Memory: 15M/81M
[INFO] 

[ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:2.6.1:compile 
(default) on project rpq-samples: Command [[
[ERROR] /bin/sh -c /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/
Contents/Home/bin/java -Xmx512m -classpath /Users/colin/Documents/idea/gwt-
rpq/rpq-samples/target/classes:/Users/colin/Documents/idea/gwt-rpq/rpq-
samples/src/main/java:/Users/colin/.m2/repository/com/google/gwt/gwt-user/
2.7.0-SNAPSHOT/gwt-user-2.7.0-SNAPSHOT.jar:/Users/colin/.m2/repository/javax
/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA.jar:/Users/colin
/.m2/repository/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.
0.GA-sources.jar:/Users/colin/.m2/repository/org/json/json/20090211/json-
20090211.jar:/Users/colin/.m2/repository/com/google/gwt/gwt-servlet/2.7.0-
SNAPSHOT/gwt-servlet-2.7.0-SNAPSHOT.jar:/Users/colin/.m2/repository/com/
colinalworth/rpq/0.0.1-SNAPSHOT/rpq-0.0.1-SNAPSHOT.jar:/Users/colin/.m2/
repository/com/google/gwt/gwt-user/2.7.0-SNAPSHOT/gwt-user-2.7.0-SNAPSHOT.
jar:/Users/colin/.m2/repository/com/google/gwt/gwt-dev/2.7.0-SNAPSHOT/gwt-
dev-2.7.0-SNAPSHOT.jar com.google.gwt.dev.Compiler -logLevel INFO -style 
OBF -war /Users/colin/Documents/idea/gwt-rpq/rpq-samples/target/rpq-samples-
0.0.1-SNAPSHOT -localWorkers 2 -XfragmentCount -1 -sourceLevel auto -gen /
Users/colin/Documents/idea/gwt-rpq/rpq-samples/target/.generated com.
colinalworth.rpqsample.demo.HelloWorld com.colinalworth.rpqsample.defer.
SimpleAutoBatching



All GWT copies on the classpath are 2.7.0-SNAPSHOT, its just building under 
gwt-m-p 2.6.1. 

Is this really expected? I'm probably misunderstanding how scope=import 
works and its importance (ha) to the build, but the strong implication 
seems to be that gwt-m-p is pulling in gwt-dev, but not transitive 
dependencies.

Pre-send edit: codehaus is back, pulling down results now. As with others, 
I am getting that org.ow2.asm:asm-parent:pom:5.0.3 is inexplicably missing, 
even if I delete it from my .m2/repository and the build *downloads* it, it 
claims it can't find it. Full gist from debug log: 
https://gist.github.com/niloc132/da63de6d8e8da90f49d7

Selected bits:

[DEBUG] Verifying availability of /Users/colin/.m2/repository/org/ow2/asm/
asm-parent/5.0.3/asm-parent-5.0.3.pom from [sonatype-nexus-snapshots 
(https://oss.sonatype.org/content/repositories/snapshots, 
snapshots)]
[INFO] 

[INFO] BUILD FAILURE
[INFO] 

[INFO] Total time: 8.792s
[INFO] Finished at: Thu Oct 16 17:38:45 CDT 2014
[INFO] Final Memory: 19M/81M
[INFO] 

[ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:2.7.0-
SNAPSHOT:compile (default) on project rpq-samples: Failed to resolve 
artifact: Some problems were encountered while processing the POMs:
[ERROR] [ERROR] Non-resolvable import POM: Could not find artifact org.ow2.
asm:asm-parent:pom:5.0.3 @ com.google.gwt:gwt:2.7.0-SNAPSHOT, /Users/colin/.
m2/repository/com/google/gwt/gwt/2.7.0-SNAPSHOT/gwt-2.7.0-SNAPSHOT.pom, 
line 74, column 25



Is there any chance that this is a 'feature' of scope=import, that you have 
to pull content from the same repos that the import'd pom came from, and 
that you can't get it from even the other defaults?

For reference sake, the project I'm building is 
https://github.com/niloc132/gwt-rpq on the 2.7.0 branch - first build rpq 
itself (gwt vers doesnt matter), then build gwt-rpq. Maven version included 
in the gist above.
On Thursday, October 16, 2014 4:56:53 PM UTC-5, Brandon Donnelson

Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

[Colin Alworth]

 of this, JSNI dispatch changes, and
AutoDirectionHandler.Target losing HasText. So far.). But GWT 2.6 added new
*final* methods to Element, ImageResourcePrototype shimmered back and
forth, repackaged apache commons in the compiler, util classes vanishing in
favor of repackaged guava. Not to mentioned

API Changes are inevitable. Google does the lion's share of improvements to
GWT, and so guides the majority of what API changes are acceptable and
which ones are too much to handle. But stuff disappears when Google is
ready to pull it (EXPERIMENTAL comments or no), as long as Google isn't
using them and they are deemed unmaintainable. But mechanically processable
documented API changes made *over a year ago*? Too much, too soon, put it
back.

We can have it both ways, but we need to recognize that having it both ways
is inconsistent.


 On Thu, Oct 9, 2014 at 2:48 PM, 'Matthew Dempsky' via GWT Contributors 
 google-web-toolkit-contributors@googlegroups.com wrote:

 On Wed, Oct 8, 2014 at 3:15 PM, Thomas Broyer t.bro...@gmail.com wrote:

 On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth niloc...@gmail.com
 wrote:

 Not quite. Anything that continues to return user.client.Element can
 only be overridden to return user.client.Element or a subclass.


 Ha, didn't thought about subclassing w/ overriding.


 Yeah, that was the main issue I remember being concerned about.
 Thankfully covariant return types make it more manageable: as long as user
 code limits itself to:

   1. Only use com.google.gwt.user.client.Element as a return type when
 needed for overloading a GWT-provided method, and
   2. In those methods, only writes return statements in the form return
 DOM.asOld(...);

 then they'll be forwards compatible with the future GWT release that
 changes the return types everywhere to com.google.gwt.dom.client.Element
 (but keeps the user.client.Element subclass).

 Then finally once everyone's moved to that GWT release, user code can
 change user.client.Element - dom.client.Element and return
 DOM.asOld(...) - return ... to be forward compatible with the *next*
 future GWT release that removes those APIs completely.

 (Unfortunately like Goktug mentioned, updating Google's internal code
 base to meet those first two constraints is a major endeavor.)

 --
 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/CAF52%2BS7uEwwKV-im7XbUxLkNnXkZFHcgWHjMyJH3EcCBA5GM%3DA%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAF52%2BS7uEwwKV-im7XbUxLkNnXkZFHcgWHjMyJH3EcCBA5GM%3DA%40mail.gmail.com?utm_medium=emailutm_source=footer
 .

 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%3DyUA18B6PddxH8G3R%2B9-9YQwHmhUyrVifDx5tLAXciKABXGw%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA18B6PddxH8G3R%2B9-9YQwHmhUyrVifDx5tLAXciKABXGw%40mail.gmail.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
218.248.6165
niloc...@gmail.com

-- 
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/CADcXZMx%2BqdsB99wAVK0J1cb%2BdbaJSLL4MvQ%2BwpDu6M_qoT_HnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

[Colin Alworth]

Not quite. Anything that continues to return user.client.Element can only 
be overridden to return user.client.Element or a subclass.

To pick a case at random (ahem, GXT), say you want to override 
UiObject.getElement for whatever reason. GWT 2.6-2.7 means that we can't 
change that return type, since you can't override methods and return a 
superclass (or a subclass of the superclass).

If we assume that no downstream code ever subclasses and overrides any 
method that returns user.client.Element, yes, we can cut over cleanly in 
the future, you are right. But GXT notwithstanding, the SimplePanel class 
is meant to be subclassed and have getContainerElement() return a different 
container for the child - I'd be very surprised if there is no downstream 
code that does this somewhere.

Example: 
FooLib v1 is compatible with GWT 2.5, when user.client.Element was not 
deprecated. It has a SimplePanel subclass called HeaderPanel, which 
overrides getContainerElement() to return a specific child element.
GWT 2.6 deprecates user.client.Element, so FooLib v1 is compatible with 
both GWT 2.5 and 2.6. As it should be.
To catch up, FooLib v2 would like to remove usages of user.client.Element, 
but since SimplePanel.getContainerElement() still requires that return 
type, it can't. The best they can do is find all cases of 
user.client.Element and cast up to dom.client.Element from the return value 
of methods like getElement() and getContainerElement().
Lets say GWT 2.7 cuts all user.client.Element. Now FooLib v1 and v2 are 
*incompatible* with GWT 2.7, even though they compatible with 2.6, and v2 
was writing the cleanest possible code (returning a deprecated type). Not 
ideal.
Or, with the patch I'm offering, GWT 2.7 keeps user.client.Element, but now 
has SimplePanel.getContainerElement return a supertype of 
user.client.Element, so subclasses are free to *further restrict* the 
return type (like v1/v2 is doing), or use the dom.client.Element. The v1 
version will probably have issues if it uses the returned value from 
getContainerElement() as a user.client.Element, but v2 corrected that, so 
v2 now is compatible with GWT 2.6 and GWT 2.7. Win.
Next, GWT 2.8 or 3.0 drops all remaining traces of user.client.Element, and 
since v2 didn't use it any more, in this regard v2 is also compatible with 
GWT 2.8/3.0. Of course, this won't happen, some other API detail will 
break, I promise (Splittable.removeReified, removed logger classes breaking 
.gwt.xml, required resource tags causing warnings, etc).

On Wednesday, October 8, 2014 4:15:10 AM UTC-5, Thomas Broyer wrote:


 On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote:

 Sorry for the thread necromancy, but aside from 
 https://groups.google.com/d/topic/google-web-toolkit-contributors/90PSQ7wKHtI/discussion
  
 this was the only relevant existing conversation I could find on the topic. 

 In GWT 2.6 user.client.Element was finally deprecated, though done in a 
 way to avoid any backward compatibility breakage. For example, UiObject now 
 has two setElement methods, one for user.client.Element and another for 
 dom.client.Element. 

 However, UiObject.getElement still returns user.client.Element, as do a 
 few other methods, as of master when I write these words. I'm submitting a 
 patch that first amends UiObject.getElement and 
 SimplePanel.getContainerElement to return dom.client.Element. My thinking 
 is that we need an API-breaking release which still holds 
 user.client.Element, but doesn't actually use them, allowing downstream 
 libraries or projects to be compatible with more than one release.

 The alternatives as I'm currently seeing them, after deprecating in an 
 initial release
 a) force a big jump, removing all traces of user.client.Element at once, 
 meaning a library that is compatible with 2.x may not be compatible with 
 2.x+1. Not ideal (as a downstream library author, who doesn't want to force 
 users to only support a single version of GWT at a time, as bugs do happen, 
 even in GWT), but certainly easier to maintain.
 b) do this two-step dance, making API breakage twice, but with the goal 
 of shifting to the new API within GWT itself (and encouraging it 
 downstream), then a version later removing the old one. Any library/project 
 compatible with N is then compatible with N+1 in as many cases as possible.

 If we like b), I'd leave any static DOM methods, but dig in further and 
 hit any overridable methods. If a) is preferred, we can just cut to the 
 chase and remove user.client.Element entirely today.


 If we did things right in 2.6 (and I have no reason to think otherwise), 
 user code (anything not from GWT proper, including applications and 
 downstream libraries) can be written without any reference to 
 user.client.Element, using dom.client.Element exclusively and never calling 
 any deprecated method (related to Element).
 So after a grace period where downstream libraries use the same 
 technique that GWT used

Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

[Colin Alworth]

On Wednesday, October 8, 2014 5:16:18 PM UTC-5, Thomas Broyer wrote:



 On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth nilo...@gmail.com 
 javascript: wrote:

 Not quite. Anything that continues to return user.client.Element can only 
 be overridden to return user.client.Element or a subclass.


 Ha, didn't thought about subclassing w/ overriding.

 To pick a case at random (ahem, GXT), say you want to override 
 UiObject.getElement for whatever reason. GWT 2.6-2.7 means that we can't 
 change that return type, since you can't override methods and return a 
 superclass (or a subclass of the superclass).

 If we assume that no downstream code ever subclasses and overrides any 
 method that returns user.client.Element, yes, we can cut over cleanly in 
 the future, you are right. But GXT notwithstanding, the SimplePanel class 
 is meant to be subclassed and have getContainerElement() return a different 
 container for the child - I'd be very surprised if there is no downstream 
 code that does this somewhere.

 Example: 
 FooLib v1 is compatible with GWT 2.5, when user.client.Element was not 
 deprecated. It has a SimplePanel subclass called HeaderPanel, which 
 overrides getContainerElement() to return a specific child element.
 GWT 2.6 deprecates user.client.Element, so FooLib v1 is compatible with 
 both GWT 2.5 and 2.6. As it should be.
 To catch up, FooLib v2 would like to remove usages of 
 user.client.Element, but since SimplePanel.getContainerElement() still 
 requires that return type, it can't. The best they can do is find all cases 
 of user.client.Element and cast up to dom.client.Element from the return 
 value of methods like getElement() and getContainerElement().
 Lets say GWT 2.7 cuts all user.client.Element. Now FooLib v1 and v2 are 
 *incompatible* with GWT 2.7, even though they compatible with 2.6, and v2 
 was writing the cleanest possible code (returning a deprecated type). Not 
 ideal.
 Or, with the patch I'm offering, GWT 2.7 keeps user.client.Element, but 
 now has SimplePanel.getContainerElement return a supertype of 
 user.client.Element, so subclasses are free to *further restrict* the 
 return type (like v1/v2 is doing), or use the dom.client.Element. The v1 
 version will probably have issues if it uses the returned value from 
 getContainerElement() as a user.client.Element, but v2 corrected that, so 
 v2 now is compatible with GWT 2.6 and GWT 2.7. Win.
 Next, GWT 2.8 or 3.0 drops all remaining traces of user.client.Element, 
 and since v2 didn't use it any more, in this regard v2 is also compatible 
 with GWT 2.8/3.0. Of course, this won't happen, some other API detail will 
 break, I promise (Splittable.removeReified, removed logger classes breaking 
 .gwt.xml, required resource tags causing warnings, etc).


 That's basically what I said too, right? Remove all uses of 
 user.client.Element but keep the class around (or –better IMO– move it to a 
 gwt-user-compat.jar) for downstream libraries.


Okay, call it mixed messages then. I'll update the patch to go further in 
this direction, so that user.client.Element exists, but is unused in 2.7, 
and we can kill it in the next version.

Do we have a plan for a gwt-user-compat v2.7.0? Seems a bit silly to make 
one for a single class...

  



 On Wednesday, October 8, 2014 4:15:10 AM UTC-5, Thomas Broyer wrote:


 On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote:

 Sorry for the thread necromancy, but aside from 
 https://groups.google.com/d/topic/google-web-toolkit-
 contributors/90PSQ7wKHtI/discussion this was the only relevant 
 existing conversation I could find on the topic. 

 In GWT 2.6 user.client.Element was finally deprecated, though done in a 
 way to avoid any backward compatibility breakage. For example, UiObject 
 now 
 has two setElement methods, one for user.client.Element and another for 
 dom.client.Element. 

 However, UiObject.getElement still returns user.client.Element, as do a 
 few other methods, as of master when I write these words. I'm submitting a 
 patch that first amends UiObject.getElement and 
 SimplePanel.getContainerElement 
 to return dom.client.Element. My thinking is that we need an API-breaking 
 release which still holds user.client.Element, but doesn't actually use 
 them, allowing downstream libraries or projects to be compatible with more 
 than one release.

 The alternatives as I'm currently seeing them, after deprecating in an 
 initial release
 a) force a big jump, removing all traces of user.client.Element at 
 once, meaning a library that is compatible with 2.x may not be compatible 
 with 2.x+1. Not ideal (as a downstream library author, who doesn't want to 
 force users to only support a single version of GWT at a time, as bugs do 
 happen, even in GWT), but certainly easier to maintain.
 b) do this two-step dance, making API breakage twice, but with the goal 
 of shifting to the new API within GWT itself (and encouraging it 
 downstream), then a version later

Re: [gwt-contrib] Removal of IE6/7 specific code from the code base

[Colin Alworth]

I've just submitted a shallow removal of IE6 specific code in 
https://gwt-review.googlesource.com/#/c/9513/ - this patch starts with all 
.gwt.xml files that mention the user.agent value ie6 and removes those 
property checks, along with any classes *only* referenced from those rebind 
rules. Far from a complete job of what remains, but takes another swipe at 
removing old dead junk.

-- 
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/9c02912b-fd7f-4594-9287-061d166ead8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

[Colin Alworth]

Sorry for the thread necromancy, but aside from 
https://groups.google.com/d/topic/google-web-toolkit-contributors/90PSQ7wKHtI/discussion
 
this was the only relevant existing conversation I could find on the topic. 

In GWT 2.6 user.client.Element was finally deprecated, though done in a way 
to avoid any backward compatibility breakage. For example, UiObject now has 
two setElement methods, one for user.client.Element and another for 
dom.client.Element. 

However, UiObject.getElement still returns user.client.Element, as do a few 
other methods, as of master when I write these words. I'm submitting a 
patch that first amends UiObject.getElement and 
SimplePanel.getContainerElement to return dom.client.Element. My thinking 
is that we need an API-breaking release which still holds 
user.client.Element, but doesn't actually use them, allowing downstream 
libraries or projects to be compatible with more than one release.

The alternatives as I'm currently seeing them, after deprecating in an 
initial release
a) force a big jump, removing all traces of user.client.Element at once, 
meaning a library that is compatible with 2.x may not be compatible with 
2.x+1. Not ideal (as a downstream library author, who doesn't want to force 
users to only support a single version of GWT at a time, as bugs do happen, 
even in GWT), but certainly easier to maintain.
b) do this two-step dance, making API breakage twice, but with the goal of 
shifting to the new API within GWT itself (and encouraging it downstream), 
then a version later removing the old one. Any library/project compatible 
with N is then compatible with N+1 in as many cases as possible.

If we like b), I'd leave any static DOM methods, but dig in further and hit 
any overridable methods. If a) is preferred, we can just cut to the chase 
and remove user.client.Element entirely today.

Initial patch (subject to later discussion) is at 
https://gwt-review.googlesource.com/9514.

On Monday, December 21, 2009 5:10:47 PM UTC-6, Thomas Broyer wrote:

 Hi Googlers,

 How about deprecating c.g.g.user.client.Element and
 c.g.g.user.client.DOM altogether and port all existing widgets to
 c.g.g.dom.client.*?
 A first pass, say in 2.1, wouldn't break public APIs, still using
 c.g.g.user.client.Element as public and protected methods' return type
 and fields; only the second pass (in 2.2 or even 2.3) would completely
 get rid of c.g.g.user.client.Element.

 As for c.g.g.user.client.DOM, there are a few methods that have no
 equivalent in c.g.g.dom.client.* (getChild/insertChild/etc. for
 instance, which deal with child elements, not child nodes). Those
 would have to either be moved to c.g.g.dom.client.Element or removed
 altogether in the end (which means deprecated with replacement API
 vs. just deprecated in the mean time).
 Most widgets have complete control over their DOM, so changing from
 child element to child node shouldn't break them.

 I volunteer to providing patches (probably one widget at a time), but
 I'd like to know upfront if I'd waste my time or if it'd have a chance
 of being accepted.



-- 
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/04e16fb1-6fd5-456f-b421-771c6761da86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.7 release plan

[Colin Alworth]

https://code.google.com/p/google-web-toolkit/issues/detail?id=8716 is still 
open (and is a regression over GWT 2.6 and previous). Is this a reasonable 
item to get fixed?

On Wednesday, October 1, 2014 2:23:43 PM UTC-5, Brian Slesinsky wrote:

 - Make sure sample apps work with DevMode -superdevmode
 - I think we're waiting on a patch to CLDR 25 


 On Wed, Oct 1, 2014 at 12:15 PM, 'Daniel Kurka' via GWT Contributors  
 wrote:

 Hi all,

 we just settled on a GWT 2.7 release plan:

  - We *code freeze* on *October 7th* and branch for GWT 2.7.
  - As soon as we have the *remaining patches submitted*, we put out a 
 beta1 build, this should be no later than *October 7th.*
  - Putting out a *beta1 externally* allows us to collect feedback on the 
 new super dev mode integration externally as well.
  - We are going to *flip incremental to default* tomorrow and *wait for 
 1-2 weeks* for google internal feedback, if there is no serious issues 
 we are going to *put out RC1*
  - GWT 2.7 will still be compatible with Java 6.

 Patches / Fixes that need to go in:
  - Recompile on reload: https://gwt-review.googlesource.com/#/c/9323/
  (dankurka)
  - Sending the wrong permutation to the client in SDM, if no files have 
 changed (dankurka).
  - Investigate why some people are seeing errors with incremental  not 
 restricting to one permutation (dankurka).
  - Public directories are not copied o the war directory when using SDM 
 (skybrian).
  - Restore Java 6 compatibility (skybrian).
  - Document limitations of JsonUtils.safeEval and discourage usage 
 (goktug) (promote Json.parse)

 Patches that are nice to have:
  - Improve exception logging in SDM (goktug).

 *If you have any outstanding patches that you thing need to go into GWT 
 2.7, please bring them to our attention, by replying to this thread or 
 adding me as a reviewer on Gerrit and setting the topic to GWT2.7.*

 -Daniel

  


-- 
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/0b3edc35-cf55-4096-837c-fb4bcbbc4d32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Spam logs: Could not find an exact match rule. Using 'closest' rule

[Colin Alworth]

Sorry Goktug, I don't follow - what should the comment indicate? In the old
code, IE9 was expressly bound to the IE6 imp, in the new (to be reverted)
code, it was expressly *not* bound to the IE6 impl, but it was the closest
fallback anyway.

Are you suggesting that the comment should point out that IE9 probably
shouldn't be bound in that way (though it works, and may not work if
differently bound)?

Thanks for any clarification,
Colin

On Thu, Oct 2, 2014 at 11:05 AM, 'Goktug Gokdogan' via GWT Contributors 
google-web-toolkit-contributors@googlegroups.com wrote:

 Reverting the binding sounds good to me. Please add a comment to the
 binding; it might probably be bound to something else but not tested.

 On Wed, Oct 1, 2014 at 9:39 PM, Colin Alworth niloc...@gmail.com wrote:

 It looks like changes to a few rebind rules are generating some new
 logspam when any GWT app compiles. Specifically, I'm seeing FocusImpl and
 LayoutImpl, though its possible there are others I haven't seen yet. From
 the dynatable example we can see the FocusImpl spam:
 gwtc:
  [java] Compiling module com.google.gwt.sample.dynatable.DynaTable
  [java]Computing all possible rebind results for
 'com.google.gwt.user.client.ui.impl.FocusImpl'
  [java]   Rebinding com.google.gwt.user.client.ui.impl.FocusImpl
 * [java]  Could not find an exact match rule. Using 'closest'
 rule replace-with
 class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/ based on fall
 back values. You may need to implement a specific binding in case the fall
 back behavior does not replace the missing binding*
  [java]Compiling 5 permutations
  [java]   Compiling permutation 0...
  [java]   Process output
  [java]  Compiling
  [java] Compiling permutation 1...
  [java]   Compiling permutation 2...
  [java]   Compiling permutation 3...


 First, the rules themselves:
   !-- Firefox uses a hidden input to set accesskeys --
   replace-with
 class=com.google.gwt.user.client.ui.impl.FocusImplStandard
 when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
 when-property-is name=user.agent value=gecko1_8/
   /replace-with

   !-- Safari uses a hidden input to set accesskeys and --
   !-- fires focus/blur after a timeout --
   replace-with
 class=com.google.gwt.user.client.ui.impl.FocusImplSafari
 when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
 when-property-is name=user.agent value=safari/
   /replace-with

   !-- IE's implementation traps exceptions on invalid setFocus() --
   replace-with class=com.google.gwt.user.client.ui.impl.FocusImplIE6
 when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
 all
   any
 when-property-is name=user.agent value=ie6/
 when-property-is name=user.agent value=ie8/
   /any
   none
 when-property-is name=user.agent value=ie9/
   /none
 /all
   /replace-with

 No express binding of FocusImpl to itself, or to Standard (interestingly
 Standard really seems to mean Gecko, at least according to that comment,
 calling out a FF specific issue). I can't comment much on that just yet,
 though I might make a suggestion later.

 This code is as a result of https://gwt-review.googlesource.com/#/c/5055/
 (or
 https://gwt.googlesource.com/gwt/+/040b3e4392186e48689a6fc1f19cdf294f2b5651
 if you like), ostensibly to make IE9+ use FocusImpl instead of FocusImplIE6
 (or Standard, for example).

 [java]Computing all possible rebind results for
 'com.google.gwt.user.client.ui.impl.FocusImpl'

 ...

 [java]  Found better fallback match for replace-with
 class='com.google.gwt.user.client.ui.impl.FormPanelImpl'/
 [java]  Checking rule replace-with
 class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/
 [java] Checking if all subconditions are true (all)
 [java]when-type-is
 class='com.google.gwt.user.client.ui.impl.FocusImpl'/
 [java]   Yes, the requested type was an exact match
 [java]Checking if all subconditions are true (all)
 [java]   Checking if any subcondition is true (any)
 [java]  when-property-is name='user.agent'
 value='ie8'/
 [java] Property value is '*ie9*'
 [java] Property value 'ie8' is the fallback of
 '[[ie9]]'
 [java] No, the value did not match
 [java]  No: All subconditions were false
 [java]   No: One or more subconditions was false
 [java]No: One or more subconditions was false
 [java]  Rule did not match
 [java]  Found better fallback match for replace-with
 class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/
 [java]  Checking rule replace-with
 class='com.google.gwt.user.client.ui.impl.FocusImplSafari'/
 [java] Checking if all

Re: [gwt-contrib] Re: [2.7.0-SNAPSHOT] Bug in compilation with pretty mode

[Colin Alworth]

I also can reproduce this - when style is set to PRETTY, 4 of the 17
permutations starts off with the PRETTY setup code (from the linker?), then
moves on to have all obfuscated (and sorted, etc) JS from the compilation
process:

var $wnd = $wnd || window.parent;
var __gwtModuleFunction = $wnd.explorer;
var $sendStats = __gwtModuleFunction.__sendStats;
$sendStats('moduleStartup', 'moduleEvalStart');
var $gwt_version = 2.7.0-SNAPSHOT;
var $strongName = '1C1FC666B8D8D4A5634A1EDA3B51C36D';
var $gwt = {};
var $doc = $wnd.document;
var $moduleName, $moduleBase;
function __gwtStartLoadingFragment(frag) {
var fragFile = 'deferredjs/' + $strongName + '/' + frag + '.cache.js';
return __gwtModuleFunction.__startLoadingFragment(fragFile);
}
function __gwtInstallCode(code) {return
__gwtModuleFunction.__installRunAsyncCode(code);}
function __gwt_isKnownPropertyValue(propName, propValue) {
return __gwtModuleFunction.__gwt_isKnownPropertyValue(propName, propValue);
}
function __gwt_getMetaProperty(name) {
return __gwtModuleFunction.__gwt_getMetaProperty(name);
}
var $stats = $wnd.__gwtStatsEvent ? function(a) {return
$wnd.__gwtStatsEvent(a);} : null;
var $sessionId = $wnd.__gwtStatsSessionId ? $wnd.__gwtStatsSessionId : null;
function Qg(){}
function lr(){}
function fu(){}
function nu(){}
function Cu(){}...

file names, sizes:
23908346   0D4B0A8AEFAF8328F37ABFBECEB765AC.cache.js
23900780   102B4372CC1E48D4E25EF20E66AD58DC.cache.js
23900946   10F8674F5E5DA2F77E606EDC3EF15643.cache.js
23900106   19BE3EA887194EC666A99E7BF57466C9.cache.js
3179517   1C1FC666B8D8D4A5634A1EDA3B51C36D.cache.js
23900433   467DE13BCB709965841DEF1F6BFD4785.cache.js
23917825   52AE506F1022BBF96CD25D74BD321C21.cache.js
23907954   6D952B9399698247258186190F8E0C38.cache.js
23900411   BB376480C0E3F616DF9CC28CCF948D0B.cache.js
23900195   C603EC38E0BF3A20A865927C32E7F122.cache.js
3143293   C868922D674E3536B6E83AF9DC005B4C.cache.js
23900252   CFB5CC0D39830766B7CCC22F07FBDD98.cache.js
3129165   D60063CBD8120FF39347C97C3C38B770.cache.js
3225082   DDCA4900448CB91C57415D5B87D0F4A8.cache.js
2397   E11B2F6059BED303323AE4942F78E157.cache.js
23910979   F8003A30DB63AC175E0F7C5D0DF1EEA5.cache.js
23900163   FD1978D213B1B1592E0DC19E4F7FC46B.cache.js

A quick read of the compilation-mappings doesn't show a lot in common as to
why this might be happening - D60063 is theme=neptune, user.agent=ie9 while
DDCA49 is theme=gray, user.agent=safari, 1C1FC is theme=gray,
user.agent=gecko1_8, and C86892 is theme=gray, user.agent=ie8.

Compiled from gwt-maven-plugin 2.7.0-SNAPSHOT as well.

On Wed, Oct 1, 2014 at 4:49 PM, Manuel Carrasco Moñino man...@apache.org
wrote:

 Roberto, in my case this is the command line:

 /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/bin/java
 -Xmx512m -classpath . . .  -Dgwt.persistentunitcachedir= target
 com.google.gwt.dev.Compiler -logLevel INFO -style PRETTY -war
 target/v-demo-1.0-SNAPSHOT -localWorkers 8 -draftCompile -XnocheckCasts
 -compileReport -XfragmentCount -1 -sourceLevel 1.7 -XjsInteropMode NONE
 -extra target/extra -gen v-demo/target/.generated
 com.vaadin.prototype.wc.gwt.Demo

 I'm compiling with maven using gwt-maven-2.7-SNAPSHOT and trunk GWT.





 On Wed, Oct 1, 2014 at 11:44 PM, Manuel Carrasco Moñino man...@apache.org
  wrote:

 I could verify the issue.
 A clue, It seems that the last emitted permutation is the only one
 un-obfuscated.

 As a workaround you can collapse-all-properties, and the result is PRETTY

 - Manolo

 On Wed, Oct 1, 2014 at 11:27 PM, Julien Dramaix julien.dram...@gmail.com
  wrote:

 Am I the only one to have this problem ?

 On Fri, Sep 26, 2014 at 11:46 PM, Julien Dramaix 
 julien.dram...@gmail.com wrote:

 Dear GWT lovers,

 I've just tried to compile several projects with the last snapshot of
 GWT 2.7.0 using the PRETTY mode flag and several permutations. I noticed
 that only one js file (corresponding to one permutation) is emitted with
 non obfuscated javascript. The other files for each other permutation
 contains obfuscated javascript.

 I've tested with GWT 2.6.1 and everything works as expected: all the
 files contain only non-obfuscated javascript.

 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/CABb_3%3D4hPmdnqisA62R387c%3D77bVNboxB%3DW9R3%3DBgTFYTtvhNw%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4hPmdnqisA62R387c%3D77bVNboxB%3DW9R3%3DBgTFYTtvhNw%40mail.gmail.com?utm_medium=emailutm_source=footer
 .

 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 

[gwt-contrib] Spam logs: Could not find an exact match rule. Using 'closest' rule

[Colin Alworth]

It looks like changes to a few rebind rules are generating some new logspam 
when any GWT app compiles. Specifically, I'm seeing FocusImpl and 
LayoutImpl, though its possible there are others I haven't seen yet. From 
the dynatable example we can see the FocusImpl spam:
gwtc:
 [java] Compiling module com.google.gwt.sample.dynatable.DynaTable
 [java]Computing all possible rebind results for 
'com.google.gwt.user.client.ui.impl.FocusImpl'
 [java]   Rebinding com.google.gwt.user.client.ui.impl.FocusImpl
* [java]  Could not find an exact match rule. Using 'closest' 
rule replace-with 
class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/ based on fall 
back values. You may need to implement a specific binding in case the fall 
back behavior does not replace the missing binding*
 [java]Compiling 5 permutations
 [java]   Compiling permutation 0...
 [java]   Process output
 [java]  Compiling
 [java] Compiling permutation 1...
 [java]   Compiling permutation 2...
 [java]   Compiling permutation 3...


First, the rules themselves:
  !-- Firefox uses a hidden input to set accesskeys --
  replace-with 
class=com.google.gwt.user.client.ui.impl.FocusImplStandard
when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
when-property-is name=user.agent value=gecko1_8/
  /replace-with

  !-- Safari uses a hidden input to set accesskeys and --
  !-- fires focus/blur after a timeout --
  replace-with class=com.google.gwt.user.client.ui.impl.FocusImplSafari
when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
when-property-is name=user.agent value=safari/
  /replace-with

  !-- IE's implementation traps exceptions on invalid setFocus() --
  replace-with class=com.google.gwt.user.client.ui.impl.FocusImplIE6
when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
all
  any
when-property-is name=user.agent value=ie6/
when-property-is name=user.agent value=ie8/
  /any
  none
when-property-is name=user.agent value=ie9/
  /none
/all
  /replace-with

No express binding of FocusImpl to itself, or to Standard (interestingly 
Standard really seems to mean Gecko, at least according to that comment, 
calling out a FF specific issue). I can't comment much on that just yet, 
though I might make a suggestion later. 

This code is as a result of https://gwt-review.googlesource.com/#/c/5055/ 
(or 
https://gwt.googlesource.com/gwt/+/040b3e4392186e48689a6fc1f19cdf294f2b5651 
if you like), ostensibly to make IE9+ use FocusImpl instead of FocusImplIE6 
(or Standard, for example).

[java]Computing all possible rebind results for 
'com.google.gwt.user.client.ui.impl.FocusImpl'

...

[java]  Found better fallback match for replace-with 
class='com.google.gwt.user.client.ui.impl.FormPanelImpl'/
[java]  Checking rule replace-with 
class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/
[java] Checking if all subconditions are true (all)
[java]when-type-is 
class='com.google.gwt.user.client.ui.impl.FocusImpl'/
[java]   Yes, the requested type was an exact match
[java]Checking if all subconditions are true (all)
[java]   Checking if any subcondition is true (any)
[java]  when-property-is name='user.agent' 
value='ie8'/
[java] Property value is '*ie9*'
[java] Property value 'ie8' is the fallback of 
'[[ie9]]'
[java] No, the value did not match
[java]  No: All subconditions were false
[java]   No: One or more subconditions was false
[java]No: One or more subconditions was false
[java]  Rule did not match
[java]  Found better fallback match for replace-with 
class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/
[java]  Checking rule replace-with 
class='com.google.gwt.user.client.ui.impl.FocusImplSafari'/
[java] Checking if all subconditions are true (all)
[java]when-type-is 
class='com.google.gwt.user.client.ui.impl.FocusImpl'/
[java]   Yes, the requested type was an exact match
[java]when-property-is name='user.agent' value='safari'/
[java]   Property value is 'ie9'
[java]   No, the value did not match
[java]No: One or more subconditions was false
[java]  Rule did not match
[java]  Checking rule replace-with 
class='com.google.gwt.user.client.ui.impl.FocusImplStandard'/
[java] Checking if all subconditions are true (all)
[java]when-type-is 
class='com.google.gwt.user.client.ui.impl.FocusImpl'/
[java]   Yes, the requested type was an exact match
[java]when-property-is name='user.agent' 

Re: [gwt-contrib] Recompile issue coming up on sdm start, gwt 2.7.0-snapshot

[Colin Alworth]

The 'test runner' in this case is just the name of a regular module file, 
which happens to be used for running lots of tests, most of which look like 
EntryPoints. Nothing too magic going on here, and I've gotten this error by 
running modules for more 'normal' gwt apps as well, typically when I stop 
SDM, restart it, and then refresh the browser or click Compile without 
first using the SDM off bookmarklet.


 I'm not completely aware of your configuration but... it appears that 
 you're using incremental compiles from a test runner, and this test runner 
 isn't restricting the permutations to just 1. And that is being caught by 
 an assertion.

 You can fix this by adding some set-property tags to your test .gwt.xml 
 files.

 I hadn't thought of this use case, so I'm not sure if it's fair to tell 
 people to restrict their permutation or if we need to find a better way. 
 Thoughts?


Does this mean that we expect all projects to already be confined to one 
permutation, either via set-property or collapse-all-permutations? Is there 
no way to achieve that synthetically?

Further, does this mean that one cannot test in multiple browsers 
simultaneously, for example re-compiling in FF until some behavior is 
satisfactory, then moving to Chrome (at least without stopping and 
restarting SDM)? 

-- 
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/cdf99604-44c9-41b5-9cca-4f45227a3c89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: -src in DevMode EntryPoint

[Colin Alworth]

Its possible that we can get away without an explicit way to add this (like 
classic Dev Mode has done so far), but -src makes multi-project development 
so much saner. No longer do you need to depend on your IDE to do the Right 
Thing (i.e. use *that* project as a jar from local maven repo, but *that* 
one over there should be raw sources, since the one former has generated 
content but the latter is being edited constantly). Leaving this out puts 
the onus on the IDE tooling to get it right every time, or provide an 
alternate mechanism - you can get pretty close with the (often wrong but at 
least easy to customize) Eclipse Run Configuration wiring, but on the other 
hand the (totally un-customizable, but at least right 80% of the time) IDEA 
Run Configurations that are shipped with Ultimate have to be right out of 
the box, or you are just stuck (as is true for 12, 13, and the 14 EAP). I 
can't speak for Netbeans (though I've seen a recent resurgence of GWT users 
making use of it!).

Is there a reason that CodeServer has this feature but DevMode doesn't? 
Should DevMode have had it all along, or was this just a hack in CodeServer 
that should be phased out?

-- 
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/fc562a17-0f4c-4573-9f18-9b5ea13ad723%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] IE11 property, if not permutation

[Colin Alworth]

As I'm sure everyone is aware, IE11 is making the navigator.useragent 
property significantly more useless than it already was, by having IE11 
identify as 'Trident' rather than 'MSIE', and adding 'iPhone', 'Webkit', 
'Android' and a few other obviously garbage strings. 

Check out 
http://msdn.microsoft.com/en-us/library/ie/hh869301%28v=vs.85%29.aspx - its 
hard to believe, but its all spelled out easily, so that you can identify 
which device you might be running on by deciphering this simple table. /s.

By following a link at the bottom of the page to a document entitled 
Detecting Internet Explorer More Effectively at 
http://msdn.microsoft.com/en-us/library/ie/ms537509%28v=vs.85%29.aspx, 
anything newer IE8 considered 'recent'. This document is also marked as no 
longer being maintained, so I'm curious as to why it was linked from the 
above article. Other links are broken too (try clicking on 
'navigator.userAgent'), so I'm not sure if this is actually meant to be 
satire, or some kind of meta-joke about how hard it is to correctly develop 
for IE. In any case...

IE 11 is worlds better than earlier browsers (8, 9 still is at 27% 
worldwide, 34% in North America according to theie8countdown.com and 
theie9countdown.com), but it is still all kinds of crazy. Examples we've 
run into recently:

Scrollwheel events in gecko are wired up to use event.detail to find out 
how far the user scrolled. Since IE11 looks like Gecko (on the desktop...), 
you incorrectly get that instead of the code in DOMImplTrident or 
DOMImplStandardBase which uses (Math.round(-evt.wheelDelta / 40) || 0) 
instead. This is filed in GWT as 
https://code.google.com/p/google-web-toolkit/issues/detail?id=8476

Focus. So many focus issues, but for the most part we limp along by making 
everything else play IE's game. In one particular case, an element was 
focused, hidden, and shown again, and for IE (which is to say user.agent = 
ie8, ie9, ie10), we could make it work by rebinding to avoid letting 
anything else be focused, since other browsers were behaving as expected. 
Alas, IE11 thinks it's other browsers, so the only way to make it work is 
to do a silly runtime check...

...Or, add a permutation for IE11.

In the past we've explored extend-property'ing the user.agent values, but 
this either makes it impossible to cleanup get along with newer GWT 
versions, or breaks CssResource code that misses a rule or two here and 
there, or causes excessive logspam from the fallback property. Instead, in 
GXT we ended up adding our own user.agent-like property, and then using 
conditional properties and soft permutations to map back to user.agent 
without causing extra permutations unless the developer wants them (see 
http://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties and 
http://code.google.com/p/google-web-toolkit/wiki/SoftPermutations if you 
haven't already). In the past, this worked great for us to split out ie6/7 
for our own rules, and continues to work beautifully for telling the 
difference between Safari and Chrome and Opera, which all show up as 
'safari' in GWT.

This won't work for IE11, for a few reasons:
a) IE11 sometimes shows up as 'safari', and sometimes as 'gecko1_8', so 
conditional properties will get a bit hairy(er) than usual.
b) At some point, we've been expecting that the level of frustration with 
IE11 in the general community would be high enough to warrant a new value 
or slapping it on to an existing one, adding either 'ie10' or 'ie11' to the 
list above.

So, while this has gotten much longer than I had planned, I hope I've made 
a case for this. I'd like to propose in GWT 2.7 (and will write up the 
patch) that we add a 'ie11' value to user.agent, and detect it by checking 
for the presence of rv:11 and trident in the useragent string. I would be 
okay with forcing this to map to gecko1_8 in any IE-specific rebind rule 
and revisit at a later date (since that is what we are effectively doing 
today). Except of course for DOMImplMozilla, which is clearly broken with 
IE11.

Thoughts? Additional snark? Other IE11 bugs that will magically be fixed 
when this is complete?

-- 
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/232f5fbb-0134-4ea9-9844-13dad666f41e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Snapshot and maven

[Colin Alworth]

For what its worth, we use a slightly different snapshot url:
https://oss.sonatype.org/content/repositories/google-snapshots/. This
appears to only contain snapshots instead of releases and snapshots.

The /google/ url for whatever reason has a newer md5 and sha1 for the
maven-metadata.xml file, but the dates/sizes on everything else seem to be
consistent.


On Thu, Aug 21, 2014 at 9:33 AM, Julien Dramaix julien.dram...@gmail.com
wrote:

 indeed mvn clean install -U does the trick...

 Thanks Manolo


 On Thu, Aug 21, 2014 at 4:24 PM, Manuel Carrasco Moñino man...@apache.org
  wrote:

 The repo structure is ok, your maven should download the metadata file
 [1] which has a reference to the last snapshot index then it should
 continue downloading the pom [2] and jar [3] files.

 Maybe something wrong in your local repo cache, try to force updating
 snapshots running:
  mvn -U clean package
 or removing
  ~/.m2/repository/com/google/gwt/gwt-user/2.7.0-SNAPSHOT

 - Manolo

 [1]
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-user/2.7.0-SNAPSHOT/maven-metadata.xml
 [2]
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-user/2.7.0-SNAPSHOT/gwt-user-2.7.0-20140820.063656-32.pom
 [3]
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-user/2.7.0-SNAPSHOT/gwt-user-2.7.0-20140820.063656-32.jar


 On Thu, Aug 21, 2014 at 3:24 PM, Julien Dramaix julien.dram...@gmail.com
  wrote:

 Dear GWT lovers,

 I'm trying to test the last GWT snapshot but I cannot configure maven to
 use it.

 I've added the following repo:

 repositories
 repository
 idgwt-sonatype-snapshots/id
 urlhttps://oss.sonatype.org/content/repositories/google/url
 snapshotsenabledtrue/enabled/snapshots
 releasesenabledfalse/enabled/releases
 /repository
 /repositories

 and use the following version: 2.7.0-SNAPSHOT

 But Maven is not able to resolve dependencies:

 Downloading:
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-user/2.7.0-SNAPSHOT/gwt-user-2.7.0-SNAPSHOT.pom
 [WARNING] The POM for com.google.gwt:gwt-user:jar:2.7.0-SNAPSHOT is
 missing, no dependency information available
 Downloading:
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-dev/2.7.0-SNAPSHOT/gwt-dev-2.7.0-SNAPSHOT.pom
 [WARNING] The POM for com.google.gwt:gwt-dev:jar:2.7.0-SNAPSHOT is
 missing, no dependency information available
 Downloading:
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-servlet/2.7.0-SNAPSHOT/gwt-servlet-2.7.0-SNAPSHOT.pom
 [WARNING] The POM for com.google.gwt:gwt-servlet:jar:2.7.0-SNAPSHOT is
 missing, no dependency information available

 I've looked into the directories

 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-user/2.7.0-SNAPSHOT/

 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-dev/2.7.0-SNAPSHOT/

 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-servlet/2.7.0-SNAPSHOT/

 and indeed the pom files are missing.

 Am I missing something ?

 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/CABb_3%3D4eduxbj5Z6FiVtw1H%2Bj%2BHhbzT6h1274Pq9VSJXF4wW0Q%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4eduxbj5Z6FiVtw1H%2Bj%2BHhbzT6h1274Pq9VSJXF4wW0Q%40mail.gmail.com?utm_medium=emailutm_source=footer
 .
 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/CAM28XAveCmt9UnaQYESVOd9FYhKD-0tHYq%3D8fxxny_4sk3gm1Q%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAveCmt9UnaQYESVOd9FYhKD-0tHYq%3D8fxxny_4sk3gm1Q%40mail.gmail.com?utm_medium=emailutm_source=footer
 .
 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/CABb_3%3D58%2BaAWf3C3A9XLt3%3DzxXDzzDkpooUYXEnR4DO7yqJ%2B%2Bg%40mail.gmail.com
 

Re: GWT-client math vs. java-math

[Colin Alworth]

Thanks for posting about this Oskar. The radian/degree code can likely be 
changed (is that behavior specified as part of the Java spec?), though 
changing RPC serialization sounds like it would come with performance 
penalties - any comments there?

What is your preferred method of resolving the trig function issues - do 
you have a gwt-able java lib that you can suggest?

On Thursday, August 14, 2014 7:36:29 AM UTC-5, Oskar Stangenberg wrote:

 Well, not every one of these things is easy to fix. Especially the 
 trig-functions - GWT is probably using the js-internal ones - which are 
 most likely pretty fast and good enough for client-only code. 
 The server-impl of the trig-functions isn't even java-code - they are 
 native functions. So their exact impl might even depend on the JRE used

 Am Dienstag, 12. August 2014 19:45:08 UTC+2 schrieb Juan Pablo Gardella:

 Thanks for sharing. It will very useful track each problem to GWT issue 
 tracker.


 2014-08-12 13:09 GMT-03:00 Oskar Stangenberg crok...@gmail.com:

 Hi guys, we are developing a GWT-project with a lot of shared files. We 
 discovered a few discrepancies in the gwt-math and server-math and wanted 
 to share them for anybody else having those issues:

- First and foremost: all native double calculations are identical 
(+ - * / %)
- All trig-functions (sin,cos,tan,asin,acos,atan,atan2) seem to 
produces slightly different results. We recommend doing your own impl 
 using 
lookup-maps 
- sqrt,log and pow seem to be identical although we only tested sqrt 
thoroughly
- As far as we know all functions like max,min,abs etc are identical 
- toDegrees and toRadian are actually different because GWT uses a 
constant for 180./PI and PI/180. which changes the order of operation 
compared to java
- For serialization of doubles we strongly suggest using 
Double.doubleToLongbits and Double.longBitsToDouble. You can 
 additionally 
use Long.toString(long,32) and Long.parseString(string,32) to compress 
 the 
String-representation

 I hope we can help some people with this info. Especially the 
 toDegrees/toRadians was very surprising to find. This issue was reported 
 though and might be fixed in a future GWT-version (we tested 2.6.1).
 In case you are interested how we solved the issues here is the 
 open-source-part 
 of our project 
 https://xp-dev.com/sc/182005/HEAD/%2FGWTCommon%2Fsrc%2Fcom%2Funiverseprojects%2Fcommon%2Fshared%2Fmath
  so 
 you can check it out
 Regards
 Oskar Stangenberg

 -- 
 You received this message because you are subscribed to the Google 
 Groups Google Web Toolkit 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-we...@googlegroups.com.
 Visit this group at http://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 
Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Generation of permutations

[Colin Alworth]

You actually have three properties, not two - the 'extend-property' 
declaration means 'add these to the existing list of values'. Running the 
SOYC report will give you the full story on your properties and 
permutations (and lots more besides).

Try a set-property line to specify not only 'add these to the existing 
list' but additionally 'and restrict to just these settings'. Notice that 
you already use set-property for the user.agent, the same should be done 
for locales.

This existing local is 'default', and is what is using your 
AppResources.properties - without 'default' being in the list, that file 
may not be required (I don't remember one way or the other).

On Wednesday, August 13, 2014 8:47:13 AM UTC-5, Developer wrote:

 Hi,

 in our GWT app we are using two locales which are defined in the 
 App.gwt.xml like this

 extend-property name=locale values=de_DE,en_US /

 We have an interface AppResources which extends the interfaces Constants 
 and ContantsWithLookup. Moreover we have three resource-property files 
 named AppResources.properties, AppResources_de_DE.properties and 
 AppResources_en_US.properties.

 When we set the user agent to one browser by

 set-property name=user.agent value=ie9 /

 GWT compiler is comiling three permutations even though we have just two 
 locales.

 If we remove the AppResources.properties file we get an compile error:

 Invoking generator com.google.gwt.i18n.rebind.LocalizableGenerator
 [INFO] Processing interface de.app.AppResources
 [INFO]Generating method body for someLabel()
 [INFO]   [ERROR] No resource found for key 'someLabel'

 What are we doing wrong?


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit 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 http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.