[gwt-contrib] Re: Seeking Advice on Legacy Application Migration Strategy

[Jens]

Then the very first thing to do is stop using the embedded Jetty of GWT 
DevMode as application server. The embedded Jetty in GWT DevMode does some 
ClassLoader hacks and it often causes issues for people using the embedded 
Jetty as application server. That is the reason why GWT 2.11 has deprecated 
the use of embedded Jetty except for demo purposes. If you search for 
"jetty-web.xml" or "jetty-env.xml" on Github GWT issues then you will 
already find some issues with the above stack trace.

So you should find a solution to run a dedicated servlet container (jetty, 
tomcat, etc) that fits your workflow. 

GWT has updated its Getting Started instructions 
(https://www.gwtproject.org/gettingstarted-v2.html) to use the recommended 
project layout and a dedicated servlet container via Maven plugin. The core 
essence is to split the legacy project layout into three projects (client, 
shared, server) with dedicated classpaths and use a build tool to build a 
*.war file (or an exploded war folder) and then deploy this file/folder to 
a dedicated servlet container of your choice. The dedicated servlet 
container can then be configured as you like, usually as closely to your 
production server as possible.

Personally I don't like launching a servlet container via a build tool so I 
use a jetty docker container and a shell script to deploy the webapp.

-- J.

Wejden Mrabti schrieb am Mittwoch, 1. Mai 2024 um 17:09:57 UTC+2:

>
> thank  you @jens for your answer 
>
> I started by  upgrading gwt Only  from version 2.8.2 To 2.10.0 and I kept 
> java 8 .
> I my jetty-env.xml file  i had  org.eclipse.jetty.webapp.WebAppContext as 
> a configurationClass, so It cause fd ollowing error when launching 
> java.lang.ClassNotFoundException: 
> org.eclipse.jetty.webapp.WebAppContext
> at java.lang.ClassLoader.findClass(ClassLoader.java:523)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at 
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:487)
> at 
> com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload$WebAppClassLoaderExtension.loadClass(JettyLauncher.java:458)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at org.eclipse.jetty.util.Loader.loadClass(Loader.java:64)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.nodeClass(XmlConfiguration.java:477)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:417)
> at 
> org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:364)
> at 
> org.eclipse.jetty.plus.webapp.EnvConfiguration.lambda$configure$0(EnvConfiguration.java:120)
> at 
> org.eclipse.jetty.webapp.WebAppClassLoader.runWithServerClassAccess(WebAppClassLoader.java:138)
> at 
> org.eclipse.jetty.plus.webapp.EnvConfiguration.configure(EnvConfiguration.java:118)
> at org.eclipse.jetty.webapp.WebAppContext.configure(WebAppContext.java:498)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:910)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:288)
> at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
> at 
> com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:568)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:423)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
> at org.eclipse.jetty.server.Server.doStart(Server.java:387)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
> at 
> com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:776)
> at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:636)
> at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:898)
> at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:705)
> at com.google.gwt.dev.DevMode.main(DevMode.java:432)
> Suppressed: java.l

[gwt-contrib] Re: Seeking Advice on Legacy Application Migration Strategy

[Jens]

I would first focus on upgrading Java, GWT and possibly GXT if it is 
incompatible with newest GWT. The DataSource error will go away once you 
upgrade GWT because newer GWT versions use a newer Jetty. Keep in mind that 
in newest GWT the use of embedded Jetty as appliction server during 
development has been deprecated. It is preferred to use a local jetty 
installation, a docker container or launching jetty via a build tool plugin 
(maven / gradle).

Once you have upgraded to latest GWT you have the possibility to use GWT 
2.11-jakarta if you need to switch to Jakarta.

GWT itself only supports Hibernate 4 validation. So if the application uses 
Hibernate validation in GWT as well, then you likely need to 
use https://gitlab.com/ManfredTremmel/gwt-bean-validators

-- J.

Wejden Mrabti schrieb am Donnerstag, 25. April 2024 um 15:59:45 UTC+2:

> Hello GWT Community,
>
> I'm currently working on a large legacy application stack, using Java 8, 
> Hibernate version 5.3.20.Final, and Hibernate Search 5.11.5.Final. Our 
> frontend technology stack includes GWT version 2.8.2 and GXT version 
> 2.3.1a-gwt22. Fontend and backend arent well de-coupled.
>
> In my initial approach to modernize the application, I began by migrating 
> Hibernate to version 6.2, assuming it would be the easiest step. However, I 
> encountered an issue where Hibernate 6.2 requires transitioning to Jakarta 
> Persistence. When attempting to compile parts of my codebase, I received 
> the following error:
>
> java.lang.UnsupportedClassVersionError: jakarta/persistence/Transient has 
> been compiled by a more recent version of the Java Runtime (class file 
> version 55.0), this version of the Java Runtime only recognizes class file 
> versions up to 52.0
>
> This suggests that I need to execute my code with JDK 11. However, when 
> attempting to do so, I encountered the following issue:
>
> [ERROR] Found resouce but unrecognized URL format: 
> 'jrt:/java.sql/javax/sql/DataSource.class' java.lang.NoClassDefFoundError: 
> javax/sql/DataSource
>
> After reviewing your discussions in the GWT contributors group, I'm 
> questioning whether starting with the Hibernate migration is the right 
> approach. Should I instead prioritize migrating Java or perhaps GWT? I 
> would greatly appreciate your insights and advice based on your experiences.
>
> Thank you,
>
> WM
>

-- 
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/d52d9aa6-5cc0-4f5b-be14-907bf758d2ecn%40googlegroups.com.

[gwt-contrib] Re: Compiling gwt on Mac ?

[Jens]

Doctool hasn't been updated yet, 
see: https://github.com/gwtproject/gwt/pull/9780

You can install Java 8 for Mac x86 
using https://adoptium.net/de/temurin/releases/?version=8 

If you use a Mac with Apple Silicon and don't want to install Rosetta 2 you 
would need to install Java 8 from a different vendor, e.g. Azul Zulu or 
Amazon Corretto 8 (also available via brew.sh). Or you make/use a Docker 
image with Java 8 + ANT (+ Maven if you want to push the build to a 
corporate repository), mount the GWT SDK + Tools repositories and compile 
inside the container.

-- J.

stuckagain schrieb am Mittwoch, 22. März 2023 um 09:21:42 UTC+1:

> Is it possible to compile GWT on a Mac ? Is it mandatory to use Java 8, 
> that version is no longer available.
>
> I have Java 11 installed, but I get the following error:
>
>
>
> compile:
>
> [mkdir] Created dir: 
> /Users/me/Projects/gwt/build/out/build_tools/doctool/bin
>
> [javac] Compiling 10 source files to 
> /Users/me/Projects/gwt/build/out/build_tools/doctool/bin
>
> [javac] -Xbootclasspath/p is no longer a supported option.
>
> [javac] Error: Could not create the Java Virtual Machine.
>
> [javac] Error: A fatal exception has occurred. Program will exit.
>
>
>
>

-- 
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/970b7bd7-a88f-41a4-8295-373a4118f083n%40googlegroups.com.

[gwt-contrib] Re: New home for GWT Eclipse Plugin

[Jens]

Seems fine to use the gwtproject.org domain for it. I slightly tend towards 
plugins.gwtproject.org/eclipse because it is slightly more descriptive and 
then we could also provide plugins.gwtproject.org/browser-extensions to 
publish the last working classic dev mode browser extensions for people 
having such an old setup. Currently they are all hosted on google.com 
domain (see: https://www.gwtproject.org/missing-plugin/) and might 
disappear at any time.

As there was some trouble getting access to the marketplace maybe in the 
long run some mechanisms should be put into place to avoid that situation 
in the future. For example some online password manager with password 
sharing between trustworthy community members. I appreciate the commitment 
of Vertispan but there should be a backup plan in case something unexpected 
happens.

-- J.

Colin Alworth schrieb am Samstag, 28. Januar 2023 um 03:45:13 UTC+1:

> The GWT Eclipse Plugin has become unmaintained, and over the last several 
> months several community members have stepped up to update it to run on 
> recent Eclipse versions, and support the new GWT groupId.
>
> As part of that process, we've created a new marketplace entry, and while 
> it is still pointed at the old 3.0 release, we're preparing a new release, 
> and hope to have it out within a week.
>
> https://marketplace.eclipse.org/content/gwt-plugin/
>
> In order to deploy a new version, we need to deploy the unpacked 
> repository somewhere - which rules out a maven repository. The footprint of 
> the unpacked workspace is fairly large, around 350mb, which would be too 
> big for github pages after three releases. We could still deploy releases 
> zips, but need somewhere else to put the unpacked content.
>
> There is probably another clever solution, but the straightforward 
> solution seems to be to add a subdomain on gwtproject.org and unpack the 
> content there - I propose eclipse.gwtproject.org. As we did for 
> www.gwtproject.org and samples.gwtproject.org, I've put an example of 
> this at eclipse.gwtproject.org.vertispan.com, and deployed a single 
> snapshot of the 4.0 plugin (note that as with many eclipse plugin repos, 
> this doesn't load correctly in a browser):
> https://eclipse.gwtproject.org.vertispan.com/2023-01-18/
>
> If there are no objections, once we've finished the 4.0 plugin and are 
> ready for a release, I'll formally set up *eclipse.gwtproject.org 
> *. For the moment I anticipate only a 
> plugins/ directory, with each versioned release (and maybe a nightly build 
> setup too), to allow for additional content later.
>
> Using the gwtproject.org domain name seems natural as a large number of 
> GWT developers use Eclipse and this plugin, and the documentation at 
> gwtproject.org has long since offered Eclipse instructions, with little 
> space given to IntelliJ or Maven/Gradle. I'd further propose we should 
> improve that situation, but that's a separate discussion. Vertispan intends 
> to host this new plugin content, and we are already hosting the 
> gwtproject.org domain content.
>
> If there are reservations about gwtproject.org also hosting the eclipse 
> plugin, we can set up an alternate domain name for this work, though at 
> least for the time being, Vertspan will be hosting these together.
>

-- 
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/47334766-5982-40de-8ee1-dcdd37286667n%40googlegroups.com.

[gwt-contrib] Re: GWT 2 Roadmap as it applies to future deprecations

[Jens]

I think first we should put a good Java version policy into place. 
Personally I would split this policy into two policies. One for client code 
(Compiler) and one for shared/server code.

For client code GWT has two main dependencies: Eclipse JDT and Jetty. So I 
would define the minimum required Java version of GWT Compiler / DevMode as 
the maximum of the requirements of latest Jetty and latest Eclipse JDT. 
That way GWT can always aim to support latest Java language features and 
can regularly upgrade Jetty for CodeServer / DevMode once the used Jetty 
version is EOL or something else requires upgrading Jetty. I think this 
should be fine for everyone because JDK on developer machines and within CI 
docker containers can be relatively new in case it needs to be relatively 
new. 
My gut feeling says with this policy we would usually end up with the 
previous LTS version of Java as a minimum requirement. Currently 11. 

For server side code we never know how it will be deployed. Some people aim 
to use newest Java on server, some don't. Jakarta EE 9 is the first release 
using the new jakarta namespace. As it requires Java 8 we could technically 
stay on 8 while supporting both namespaces for a long time. Jakarta EE 10 
will require Java 11. 


IMHO it is important to support latest java language features in 
client/shared code. If GWT client/shared code lags behind GWT feels even 
more dated just because of missing language feature support. Thus our Java 
version policy should help us to never be blocked by server side Java 
requirements. 


-- 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/23ea079e-8be3-4245-a6c4-3f4c4c5553e0n%40googlegroups.com.

[gwt-contrib] Re: License for gwt-site content

[Jens]

> As Google is winding down their direct involvement in the project, the CLA 
> bot will be turned off soon, and we'll want to be sure we have an 
> explicitly license in all projects that covers contributions, but so far 
> this was the only project deficient in this way - and the only project not 
> covered by gerrit.
>

I am wondering if Google should also hand over CLAs to someone else, given 
that they need to be accessible for non-Googlers somehow if Google is 
winding down their involvement further. Ideally some CLA Github bot should 
be fed with them (and any future CLAs of future contributors).

-- 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/cb92ce10-d030-4585-a6f2-cee90657a5fdn%40googlegroups.com.

[gwt-contrib] Re: License for gwt-site content

[Jens]

Haven't all changes been made through gerrit and did require a CLA? 

--J.

Colin Alworth schrieb am Donnerstag, 21. April 2022 um 17:34:49 UTC+2:

> See the question raised at 
> https://github.com/gwtproject/gwt-site/issues/328.
>
> While gwtproject explicitly licenses all "software and sample code" as 
> under the Apache License 2.0, it appears that we don't have a license 
> specified for the contents of the gwtproject website (
> https://gwtproject.org, https://github.com/gwtproject/gwt-site/). A case 
> could be made that the content is already licensed as under the same 
> license. It was my understanding that this is discouraged (though at the 
> moment I'm having a hard time seeing why that would be). I can find 
> concrete examples of the Apache Foundation licensing their documentation 
> under the Apache License
>  * https://github.com/apache/couchdb-documentation
>  * https://github.com/apache/cordova-docs
>
> On the other hand, if the Apache license that applies to all code and 
> samples does not apply to the contents, then each author owns their own 
> content directly.
>
> I am not a lawyer, but my understanding is that (at least in the country 
> in which I reside) content is copyrighted by default, and the author owns 
> that copyright. Additional rights must be granted by the author. If we want 
> to change the license, we need the approval of the authors so far - 
> https://github.com/gwtproject/gwt-site/graphs/contributors. Anyone who 
> doesn't approve would need to have their content removed, if we decide to 
> change.
>
> Are we sufficiently clear that all content is Apache licensed, including 
> the website documentation? Is there a good reason to consider a different 
> license instead? Should we seek confirmation from any authors of 
> substantial amounts of content that their content falls under the license 
> we choose?
>
> My suggestion is to clarify that all content is under the Apache License, 
> and see a confirmation from any author who wrote more than ~5 lines of 
> content. If we think we are already clear that all content is under that 
> license, then we should state that in an up front way, such as setting the 
> "license" metadata of the gwt-site repo, and adding a LICENSE file.
>
> Thoughts, suggestions, pointers to how other projects have handled this?
>

-- 
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/36d93c6d-09d6-46c4-bfc6-86df8d8cc5abn%40googlegroups.com.

Re: [gwt-contrib] Re: Goodbye IE 8–9 

[Jens]

I think the gecko permutation has very little to no special treatment of IE 
11 and there are some bugs reported because of that. So there isn't much to 
deprecated for IE 11. 

Personally I only use safari, gecko permutation and define safari as 
fallback permutation. In addition I use some code to check runtime vs 
compile time user agent and if they are different display a warning that 
some things might not work. That warning basically triggers for any exotic 
user-agent and any IE below 11.

Dropping all IE permutations (8-10) should be totally fine I guess. 
Especially because the new, smaller GWT modules only care about IE 11 (if 
at all). gwt-dom for example has only two checks for safari and everything 
else is treated the same.

-- J.

ManfredTremmel schrieb am Montag, 4. Oktober 2021 um 11:07:11 UTC+2:

> Am Donnerstag, 30. September 2021, 18:49:56 CEST schrieb Colin Alworth:
>
> > So, is there any objection at this time to dropping what remains of IE8,
> > IE9, and IE10 support from GWT? Then, we can reevaluate IE11 at some 
> later
> > date, for GWT itself? Various migrated GWT modules have focused their
> > efforts on well-supported browsers, and are likely to only support IE11 
> by
> > accident anyway.
>
> Let's drop the IE-Permutations. IE11 uses the gecko permutation, so no 
> need to 
> drop it. In my newer projects, I only use safari permutation for all 
> browsers, 
> so even dropping all browser specific permutations wouldn't affect me.
>
>
>

-- 
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/331ecf5c-ef4c-4862-86c9-12a47f8b991bn%40googlegroups.com.

[gwt-contrib] Re: Asking for decision on DevMode embedded Jetty support

[Jens]

For reference:

Jetty ASM issues:
https://github.com/gwtproject/gwt/issues/9606
https://github.com/gwtproject/gwt/issues/9693
https://github.com/gwtproject/gwt/issues/9720

Jakarta servlet support question:
https://github.com/gwtproject/gwt/issues/9727

Other embedded Jetty related issues:
jrt: URLs not recognised with Java 9+: 
https://github.com/gwtproject/gwt/issues/9582
Class loader leak protection code causes (ignorable, yet annoying) error 
logs in Java 9+: https://github.com/gwtproject/gwt/issues/9561




-- 
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/9fad99cf-9d54-4550-b740-210a6c9175d9n%40googlegroups.com.

[gwt-contrib] Asking for decision on DevMode embedded Jetty support

[Jens]

Hi,

we all know the issue: DevMode bundles Jetty and people are using it even 
though we do not recommend it. Consequently people are complaining that 
bundled Jetty is too old. So every once in a while we upgrade it.

Currently with GWT 2.9.0 the situation is:
- GWT SDK is compiled to Java 7 byte code
- GWT Compiler requires ASM 7.x to support Java 11
- DevMode bundles Jetty 9.2 which uses ASM 5.x
- gwt-dev.jar can only bundle a single Jetty, since we do not relocate it. 
However there is already a question asking for Jakarta Servlet support, 
e.g. Jetty 11 / Tomcat 10.

Currently the ASM version misalignment between Jetty 9.2 and GWT compiler 
causes classpath issues. This could be fixed by upgrading to Jetty 9.4 and 
consequently compiling GWT SDK to Java 8 byte code as that is a requirement 
for Jetty 9.4.

However given the new Jakarta namespace and first questions about 
supporting it, I am wondering if it wouldn't be wiser to remove embedded 
Jetty from DevMode now, invest some work to make GWT-RPC and RequestFactory 
useable with old javax.servlet and new jakarta.servlet namespaces and 
finally cut a 2.10 or 3.0 release given the removal of embedded Jetty.

Personally I would strongly vote for removal because GWT nowadays is in 
maintenance mode with only very few changes here and there to support J2CL 
better. Even reviews from contributors are rare these days I guess. Every 
action we take nowadays should take maintenance effort into account and a 
low maintenance effort is obviously preferred. If we upgrade Jetty to 9.4 
we still have that Jakarta issue coming up more often in the future for 
sure.

Generally this would be a decision made by GWT steering group but I have no 
idea if this group still exists. So I am asking here for a decision how to 
move on.

-- 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/622544a8-85d5-41c5-b8da-7a733667eb89n%40googlegroups.com.

[gwt-contrib] Re: Goodbye IE 8–9 

[Jens]

Dropping IE 8-10 shouldn't really hurt. Companies that require it are 
probably not upgrading GWT in a fast pace anyways.

However I wouldn't drop IE 11 anytime soon. IE 11 itself is tied to the 
lifecycle of Microsoft's operating systems, which means for Windows 10 it 
is supported until 2025 (for now). So just because MS and Google drop 
support for IE 11 in some/all of their products, the browser itself is 
still generally supported by MS. So we should think twice before removing 
IE 11 from a library such as GWT, even if it means to decline/revert 
certain commits if they break IE 11. From own experience I have usually 
seen something around 8% of IE 11 usage in GWT based apps.

However I am pretty sure more and more companies will announce dropping IE 
11 this year or next year. With MS and Google starting, this could easily 
have a domino effect. However GWT also also strongly used internally inside 
companies so it might not have that much of an effect in that area.

If we ditch IE 8-10 and only leaving gecko1_8 and safari, can't we kill 
them both as well and put them together? Are there so many differences in 
code between both? From my work migrating GWT code to elemental2/JsInterop 
I had the feeling that only some minor stuff is different between both. So 
there shouldn't be that much overhead in code size and performance doing 
(cached) runtime checks instead.

-- 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/031f1171-cce9-4c17-b717-80bb5730f7fdn%40googlegroups.com.

Re: [gwt-contrib] CI / Jenkins configuration issue

[Jens]

Any news here?

The Leeroy Jenkins spam is really annoying in code reviews.

-- 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/4d9695b1-bf52-4792-a0c5-c4cb413487abo%40googlegroups.com.

Re: [gwt-contrib] Re: HashCode H$ property should be not enumerable

[Jens]

> Fwiw: IE11 will be EOL for mainstream in October this year: 
> https://www.swyx.io/writing/ie11-eol/ (of course, for enterprise 
> customers this will be longer; my opinion is that those companies that have 
> enough money to pay for special Microsoft support contract could also pay a 
> company to fork and maintain GWT for those usecases; or they can just stay 
> on an old version of GWT like they're staying on an old version of IE; 
> those companies are not my customers though so my opinion probably doesn't 
> weight much)
>
> Also, jQuery dropped support for IE8 while back and is now IE9+ 
> https://jquery.com/browser-support/ 
> .
>  
> That supports the option for GWT to do the same, at a minimum.
>
> Finally, several "modularized gwt-user" modules already dropped support 
> for IE8 and IE9 AFAICT, possibly even IE10.
>

Yeah there wasn't a clear guideline I think. At least when I started 
gwt-dom and gwt-widgets I killed IE8-10 and used IE 11 as baseline for 
both. And since Edge is now based on Chrome, technically every OS that 
supports IE 11 also supports Edge now, so I would be fine dropping IE 11 as 
well in a not so distant future.

-- 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/0e56f35c-1c20-4ed9-a0b0-81ef586d3fe8o%40googlegroups.com.

[gwt-contrib] Re: Discussion on changing gwt release groupid

[Jens]

>
>
> I suspect this will not work except in gradle, which picks the highest 
> version in the case of a conflict. Maven picks the "nearest to your 
> project", so:
>
>- SomeLibrary depends on c.g.g:gwt-user:2.9.0 (or earlier, with or 
>without a BOM)
>- MyProject depends on SomeLibrary (so c.g.g:gwt-user is now 2 steps 
>away)
>- MyProject depends on o.g:gwt-user:2.10 without a BOM, which depends 
>on c.g.g:gwt-user:99.0 (which is also 2 steps away)
>
> Hmm, so MyProject would need to declare c.g.g:gwt-user:99.0 as a direct 
dependency as soon as it wants to use o.g:gwt-user:2.10 to make sure the 
"distance" is 1. A bit unfortunate but doable when clearly communicated in 
documentation. But maybe that relocation solution is more straight forward 
then for the end user.

-- 
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/380f610a-96e9-44e8-9171-412c0893b2bbo%40googlegroups.com.

[gwt-contrib] Re: Discussion on changing gwt release groupid

[Jens]

I know you can force Gradle to swap out dependencies on the fly, e.g. 
replace com.google.gwt with org.gwtproject releases. If that would also be 
possible with Maven/Ivy/Bazel then it is just a matter of documentation.

If that is not possible, or not desired, then Google could probably publish 
a single, empty com.google.gwt:..:99.0 release without any dependencies in 
its pom. Our new published org.gwtproject:...:2.10 release would depend on 
com.google.gwt:...:99.0 which means all old GWT libraries should be 
upgraded via Maven/etc to 99.0 automatically as soon as you add 
org.gwtproject:...:2.10 to your dependencies. Since the 99.0 release is 
empty and the classes are provided by our new release, there should not be 
any class path conflicts. New GWT libraries would directly depend on our 
new release which means as soon as you try to migrate your code to one of 
the new GWT libs, our new org.gwtproject release will be pulled in and 
provide the code for everything.


-- 
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/10ac1356-1146-4ff1-9732-f4983a7d9367o%40googlegroups.com.

Re: [gwt-contrib] First org.gwtproject.* modules published to Central

[Jens]

My understanding is that:

>
>- these projects/classes are builtin in GWT 2.9
>
> Their old, non J2CL compatible versions are buildin in GWT 2.9. No changes 
are made here.
 

 

> Is it possible to start preparing now with GWT 2.9 before GWT 3? Maybe if 
> we drop gwt-user from the dependencies and include these mini gwt-project* 
> ? Or it is not supposed to work like that?
>

gwt-user code is still in package com.google.gwt while the package for the 
various small gwt-* projects is org.gwtproject. So you would add the small 
projects to your class path and then update your imports in your project to 
point to the new classes / projects. 

You would continue to do that with all the other upcoming gwt-* projects 
until your projects does not use any com.google.gwt imports anymore. Then 
you can drop gwt-user.jar. 

The projects above should be relatively easy to integrate into your app. 
Maybe gwt-events needs a little more work since you generally want your own 
custom events to move away from GwtEvent / EventHandler as both are not 
required.


-- 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/b95a95fa-460d-482c-9374-b7b405309024%40googlegroups.com.

Re: [gwt-contrib] GWT Java7 support

[Jens]

> Could someone send a patch?
>

I guess the steering group first needs to make the decision to finally drop 
java 7. Maybe ping here 
again: 
https://groups.google.com/forum/#!topic/google-web-toolkit-contributors/tMR3Dv1YBBE
 

-- 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/1fa70489-132e-4554-99d7-ae46bb887fd2%40googlegroups.com.

[gwt-contrib] GWT Java7 support

[Jens]

It’s kept so long because of java 7 servers and the fact that gwt-servlet 
doesn’t have its own ant compile target.

But I guess it should be fine to drop java 7, it is also holding back upgrading 
embedded jetty to a decent version.

-- 
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/b5eb4fbe-0471-479b-9734-56d33d9d129e%40googlegroups.com.

Re: [gwt-contrib] CI / Jenkins configuration issue

[Jens]

> fixed
>
 
Hmm, build.gwtproject.org still isn't accessible for me and Jenkins still 
does an endless check as soon as +1 or +2 is given.

-- 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/fc58ea21-f502-4a85-9571-81b43f564630%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] CI / Jenkins configuration issue

[Jens]

Can anybody with the appropriate permissions 
mark https://gwt-review.googlesource.com/c/gwt/+/21680 as verified so it 
can be merged and possibly figure out why Jenkins does an endless fast 
style check?

Also http://build.gwtproject.org isn't reachable for me. Wondering if there 
is really an issue with the server or if some network route is broken.

-- 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/75d073bf-8b32-481b-9435-dd86ea29d2eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: What tool generates TimeZoneConstants.properties?

[Jens]

> Is bundling data before 1970 really worth the additional bloat? If you ask 
> me, I wouldn't even go down to 1970.
>

Well ideally the developer should decide how much data the application 
needs and not GWT SDK. So we should either include all or make it 
configurable.

If you look at moment-timezone js library the gzipped size of timezone data 
is about 40kb. Their format is different, but I would expect GWT's json to 
be in the same region if it would contain all data + future data.

I already thought if GWT could maybe use that moment-timezone js library 
internally (keeping GWTs property file for API compatibility but make it 
empty). Yes the JS it is not very well optimizable in GWT 2.x but the 
reason to use it is that once you have older historic data the current GWT 
Json format can not express certain situations. For example the standard 
offset for certain time zones changes multiple times over the past years, 
but GWT only knows a single standard offset (likely the most recent one at 
the time the file as generated). Also some DST changes are down to second 
granularity, however GWT only stores hours as transition points and offsets 
in minutes which would result in some dates being treated wrong for these 
timezones.

Of course we could also update the GWT Json format to cover these 
situations, but it also feels like reinventing the wheel.

-- 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/f2167b42-64a8-4e6f-8025-a0cceaa8c43f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: What tool generates TimeZoneConstants.properties?

[Jens]

> I looked at the file and the GWT code using it and the format seems pretty 
> clear to me. 
>

Totally forgot to write the format down for documentation:

europeBerlin = {

 // Time Zone Id
 "id": "Europe/Berlin", 

 // List of  pairs. The DST 
offset is added on top of std_offset if DST is active. Thus it is 0 when 
switching to normal time.
 "transitions": [89953, 60, 94153, 0, ... ], 

 // name of time as pair of . If transitions is 
empty, size must be 2, otherwise 4. The first pair is normal time, the 
second pair is DST.
 "names": ["CET", "Central European Time", "CEST", "Central European Summer 
Time"],

  // The offset during normal time.
 "std_offset": 60

}



The current file shipped with GWT has no negative transition points, so it 
does not contain any data before 1970 which is kind of sad. Using IANA db 
we would have a lot more historic data. GWT also has future transition 
points which can usually be calculated using the DST rule defined in tzdata 
(java.time has an API for that and JodaTime probably as well). So a new 
tool would need to do that as well.


-- 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/435edfd1-900c-4fcf-9ec3-8fcff6598fb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: What tool generates TimeZoneConstants.properties?

[Jens]

I looked at the file and the GWT code using it and the format seems pretty 
clear to me. Writing a new tool looks pretty simple, we just have to decide 
which implementation strategy to choose.


1.) use JDK java.time package to read the tzdata information packaged with 
Java.

Given that JDK is now released every 6 month, this might also be a nice 
minimum time frame for possibly automated GWT patch releases with new 
tzdata.

Otherwise if we want to update tzdata in GWT outside of JDK releases, the 
process is a little more complex because we first have to generate a 
tzdb.dat file to update a JDK installation. To generate that file, we would 
also need to use the source from the JDK version we use to execute the GWT 
tool that generates the GWT json files because the tzdb.dat file format 
might change between JDK versions.


2.) Use Joda Time and their api to read the tzdata information

You would need to checkout Joda Time sources, put the new tzdata files into 
a special package and then build Joda Time. A tool would then depend on 
that custom build Joda Time and use the Joda Time API to produces the GWT 
JSON files.



Personally I kind of like option 1.) because we could then align automated 
GWT releases to JDK releases, e.g. one month after JDK release, and the GWT 
tool could just use standard JDK API without any dependencies.



-- 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/7db2aeda-c4ef-4b20-97c2-506872c0de69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Time to require JDK 8?

[Jens]

I am totally fine with requiring JDK 8 when using GWT. 

Personally I would even like to see requiring at minimum the Java version 
we provide emulation for. That would free us from super sourcing emulation 
tests for newer Java APIs / syntax which is quite annoying. Also your ANT 
build could require at least Java 9 so we can use javac -release 6,7,8,.. 
parameter to more easily cross compile during build. If we would have that, 
we could refactor the ANT build to produce Java 7 or Java 8 jars used on 
server side (gwt-servlet, gwt-servlet-deps, requestfactory-server) while 
requiring a way newer Java version during development (gwt-user.jar, 
gwt-dev.jar, gwt-codeserver.jar).

-- 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/c0a9790b-e6c9-4757-a30b-623c78611d39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Java11 support

[Jens]

> Colin,
> My concern is that a lot of time is spent on re-writing RPC, XML 
> UI-binding. Given how short-handed the maintainers are, should we not focus 
> on just one thing - 2.9 with basic compiler support for Java 11 jdk? I 
> don't even advocate for porting any  new core Java 9+ JDK APIs.  
> ... Even worse: downstream projects, such as Errai won't move to Java 11 
> unless there is an official GWT release for it.
>

GWT depends on Eclipse JDT, and the current stable version used 
in https://gwt-review.googlesource.com/c/gwt/+/21540 is missing some 
valuable bugfixes that will be part of the next JDT 4.11 release (will be 
released when Eclipse 2019-03 will be released). One of the main features 
of Java 11 is using the var keyword in lambda parameters. However that 
fails for Function and Predicate with the current JDT release but has been 
fixed for the next release. There is also a compilation slowdown fixed.

So I think it is better to wait for JDT 4.11 in march and use the time to 
review Colins JRE emulation (which you can also help reviewing), making the 
GWT ant build Java 11 compatible and update the CI build of GWT to use Java 
11 (with -release 1.8 or course).


-- 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/08de0d95-1d2d-4064-ad84-673e6fa05f13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Java 9, 10 JRE emulation reviews

[Jens]

>  Likewise, has someone had the chance to look at Java 9+ support for our 
> ant build?
>
 
I tried building GWT a few days ago with Java 11. Seems like we first have 
to apply the patch of Andrei 
(https://gwt-review.googlesource.com/c/gwt/+/2) and then make javadoc 
API available 
to https://github.com/gwtproject/gwt/tree/master/build_tools/doctool as the 
build of that project does not find JavaDoc classes (Taglet and such). 
Finally one has to disable errorprone compiler by making sure that the ant 
variable "isJava8" is actually only true when using Java8 (currently it is 
true for anything Java 8+, see 
https://github.com/gwtproject/gwt/blob/master/common.ant.xml#L32). Maybe it 
would be better to add a variable "isJvmErrorproneCompatible" and use that 
in the ant script.

-- 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/338d1bb4-dca4-461e-8170-2f017fac5a2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: NoSuchMethodException in HEAD-SNAPSHOT has been removed, breaking knightsoft gwt-bean-validators

[Jens]

>  It has always had a private constructor to make that completely 
> impossible.
>

Private constructor? Looks like it always was public as it should.

https://github.com/gwtproject/gwt/blob/2.8.2/user/super/com/google/gwt/emul/java/lang/NoSuchMethodException.java
 

-- 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/86cb9f50-6679-4dc3-b441-c92808726bb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: NoSuchMethodException in HEAD-SNAPSHOT has been removed, breaking knightsoft gwt-bean-validators

[Jens]

> I agree this is mostly a misuse like you said. We don't have any internal 
> usage in all Google either so I would rather push users to not 
> declare/catch such exceptions. Keeping such classes opens the door for 
> more: https://gwt-review.googlesource.com/c/gwt/+/21320
>

Actually I am totally fine with Colins change, because:

1.) It is more correct emulation
2.) It is very simple code, so it is not a maintenance burden
3.) Single source of trust if its inside GWT emulation.
4.) Reflection based code can be emulated to some extend using 
Generators/APT so it is not super unlikely nobody uses these exceptions. If 
Google does not use it, fine, others might do and for them it is a real 
breaking change which stops them from upgrading GWT.
5.) It reduces the noise when using diff tools between GWT emulation and 
JDK to a.) discover newly added APIs in JDK and b.) verify existing 
emulated APIs still match JDK APIs.

 

> I think IDE warnings in couple of corner cases is just a minor 
> inconvenience for the end user.
>

I don't think 2 classes with each 3 lines of real code outweighs the 
happiness of end users.


-- 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/846bfc59-f3f5-4f0f-8642-a0ae3d02317a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: NoSuchMethodException in HEAD-SNAPSHOT has been removed, breaking knightsoft gwt-bean-validators

[Jens]

It is not a RuntimeException so even though you might be able to remove it 
from GWT emulation code, your IDE will still annoy you in calling code to 
either catch that exception or redeclare it because your IDE does not know 
that GWT emul is cheating. If that calling code is exclusively within other 
emulated code, then it kind of depends on how JDT behaves I guess.

But honestly, it is just an exception and I would simply add it to GWT 
emulation. Done. It is always preferable to have a single emulation within 
GWT proper instead of one emulation per project that needs it with various 
degrees of implementation quality.

-- 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/188c7862-b408-467c-a140-4383cd619ca7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: NoSuchMethodException in HEAD-SNAPSHOT has been removed, breaking knightsoft gwt-bean-validators

[Jens]

I would say this change should be reverted in GWT then. Personally I would 
never ever delete any already emulated class in GWT.

While this exception has been misused in some of the above code (e.g. 
URL.openStream() should not be emulated at all or throw 
UnsupportedOperationException), in the emulated apache commons classes they 
are part of the method signature.

-- 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/88c39adc-17f5-4bbd-a71b-f29998b40eb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: 2.9 progress

[Jens]

> Is it acceptable that an official GWT implementation of the time API would 
> be based on moment.js ? Or is it expected that it is all implemented with 
> standard browser API and pure Java code ?
>

Because GWT compiler can not see/optimize external JS files, an official 
GWT implementation will likely also be based on the threeten code, thus 
java. I think the major hurdle is the ZoneId API for time zones. You don't 
want whole tzdata in your app if you just need one or a couple time zones.

-- 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/e1b13023-e473-4d86-a23f-fa53c08d9799%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: 2.9 progress

[Jens]

> For the emulation changes I can live with what is available now and get 
> some more in a later release. But how does the gwt team decide which are 
> crucial and which ones can be done in a separate library ? The java.time 
> API should really be considered, the Date object has been deprecated for 
> ages. Right now I use moment.js with a JsInterop mapping to handle dates 
> and times.
>

It is generally preferred to have JRE emulation within GWT itself instead 
of having separate libraries. Basically a single source of trust, which is 
well reviewed, tested and optimized. Also J2CL uses the same emulation and 
it might be beneficial to have J2CL experts take a look at the emulation 
code as well.

There was someone who did java.time emulation but he never contributed it. 
It was based on the threeten repository on Github. Personally I think 
java.time should really be tackled by GWT because working with Date in 
Client code is a pain. Using momentjs works, however it is still a pain for 
code you want to share between client and server. (There is also a 
java.time emulation on Github somewhere which uses momentjs under the hood 
I believe)

-- 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/5fcf5659-b317-42bf-9ed9-61b3ca42b061%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: 2.9 progress

[Jens]

I think the JDT version GWT currently uses does not officially support Java 
11. However Java 11 has no notable syntax changes except the var keyword 
for lambda parameters. So it might work, but maybe it doesn't. Have you 
tried running GWT with Java 11 and using that new syntax?

Also no Java API emulation additions have been added since Java 8 (and even 
some Java 8 stuff is still missing). I am working on a detailed list of 
differences between GWT HEAD and Java 11 source whenever I find time for 
it. This is not really a blocker, but if we state GWT supports Java 11 we 
might want to have the most useful API additions available.

Automated releases that are tested like the SNAPSHOT builds, but with a 
fixed version number would be the solution to GWTs slow (fully tested) 
release cycle.

-- 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/4414c464-fd70-4229-9876-f700c28d4df6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Java 11 is there gwt 2.9 ?

[Jens]

Since there is no updated JDT in GWT, it might be that you can not use var 
keyword in lambda parameter definitions for now. Have you tried that? Other 
than that Java 10 and 11 are pretty much the same in terms of syntax.

I have said it on Gitter recently and I think also here in this group: IMHO 
GWT should provide monthly / quarterly SNAPSHOT builds with a fixed version 
number and release them on maven central. These automated releases are only 
code tested just like SNAPSHOT builds. I could imagine something like

2.8.2  - fully tested
2.9.0 - fully tested
2.9.0-14-g7940d679a - automated release which is based on commit 7940d679a 
and is 14 commits newer than 2.9.0
2.9.0-25-g8941d679b - automated release which is based on commit 8941d679b 
and is 25 commits newer than 2.9.0
2.9.1 - fully tested

Alternatively just a timestamp could be used for automated releases between 
fully tested releases, e.g. 2.9.0-20190103. Personally I like the first 
version more as I can see how many commits I am missing by comparing the 
version string.

Would your company be fine with such a solution?

-- 
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/807bf48f-2be3-4319-a36a-de2b285f059e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Wrong deobfuscated stack traces

[Jens]

> Looking at this traces it seems to me that the file/line is consistent but 
> the member is completely off. That suggests that the wrong symbol map is 
> being used.
>

It is stock GWT with just a single change wrt to Date serialization. We 
deploy what GWT gives us and the code chooses the symbol map using the 
permutation strong name transferred via the GWT-RPC as HTTP header (
AbstractRemoteServiceServlet#getPermutationStrongName()). 

So I would say it is the correct symbol map and from the full exceptions I 
have seen so far the members itself are correct, but file/line is off here 
and there. You can see this in the first example. The stack of just the 
members is correct when calling Panel.clear() on a SimplePanel. However 
file name went crazy at some point and switches to some Guava stuff.

-- 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/3c878c4b-96b8-42e6-9d2a-138fc3e3b8ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Wrong deobfuscated stack traces

[Jens]

In production we sometimes get exceptions and we log them using 
StackTraceDeobfuscator class on the server (either symbol maps or source 
maps, depending on browser). However these stack traces are often broken 
when comparing the member with the file it should live in.

Some examples:

at Unknown.removeChild(Unknown@-1)
at 
com.google.gwt.dom.client.Node.$removeChild(com/google/common/base/Joiner.java:198)
at 
com.google.gwt.user.client.ui.SimplePanel.$remove(com/google/common/collect/super/com/google/common/collect/ImmutableList.java:41)
at 
com.google.gwt.user.client.ui.SimplePanel.remove(com/google/common/collect/super/com/google/common/collect/ImmutableMap.java:239)
at com.google.gwt.user.client.ui.SimplePanel$1.remove(SimplePanel.java:93)
at 
com.google.gwt.user.client.ui.Panel.$clear(com/google/gwt/user/client/ui/Panel.java:75)


at 
java.lang.Throwable.Throwable(com/google/gwt/emul/java/util/AbstractCollection.java:68)
at 
java.lang.RuntimeException.RuntimeException(com/google/gwt/emul/java/util/AbstractList.java:208)
at 
com.google.web.bindery.event.shared.UmbrellaException.UmbrellaException(com/google/common/collect/super/com/google/common/collect/ForwardingImmutableMap.java:108)
at 
com.google.web.bindery.event.shared.SimpleEventBus.$doFire(com/google/common/collect/super/com/google/common/collect/ImmutableList.java:281)
at 
com.google.gwt.place.shared.PlaceController.$goTo(com/google/gwt/emul/java/util/AbstractMap.java:167)


at 
com.google.web.bindery.event.shared.UmbrellaException.UmbrellaException(UmbrellaException.java:656)
at 
com.google.gwt.event.shared.UmbrellaException.UmbrellaException(com/google/gwt/http/client/Request.java:247)
at 
com.google.gwt.event.shared.HandlerManager.$fireEvent(HandlerManager.java:638)


Any idea how this could happen and where to look at, or is this kind of 
expected with current compiler? 

-- 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/2303e9b2-bf7c-4f67-9bf4-7b3fe5b83145%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Java10 support

[Jens]

>
> But I need to figure out if this is a local problem due to our mirrors of 
> the maven repos or if the HEAD-SNAPSHOT is maybe not updated for some time.


Likely a local problem. You can see GWT builds at 
http://build.gwtproject.org/job/gwt/ and each successful build pushes 
HEAD-SNAPSHOT to Sonatype. 

-- 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/3d7bb891-376f-4dca-9411-d89507f02439%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Java10 support

[Jens]

> I guess I am bit overworked :) ignore the last statement!
>

:D :D and now you are sad? :) 

-- 
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/526591e7-bb40-4e09-a280-31206f705d86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: The elusive J2CL

[Jens]

>
>1. The backing company backed off but kept the crucial new piece 
>secret - J2CL.
>
> These days it is already available to a few people who take their spare 
time to make it useable by the general public. 



>1. The past and current stated direction devolves the product, does 
>not evolve it. Good, differentiating features aren't enhanced or even 
>replaced but just plain eliminated under the premise that select few NOW 
>(but not all) think they are bad but are really only hard to do, which is 
>what makes them useful (say GWT RPC, debugging, widgets). I could have 
>helped with that. No more, though.
>
> GWT 3 compatible UiBinder already exists, GWT 3 compatible GWT RPC is 
being worked on, Widgets will be GWT 3 compatible, other code is already 
GWT 3 compatible or is being worked on. There are quite some new people who 
never really contributed to GWT itself before who now step up and invest 
time in migrating existing GWT SDK code to JsInterop / APT. So you can 
still help if you want to.

See:
https://docs.google.com/spreadsheets/d/1b1D9fEqRh5lZ8cqMJtYoc_25rfTRvsuJkTtS2vjgi3o/edit#gid=0
https://ci.vertispan.com
   


>1. Inability to plan proper migration to 3.x - "just don't use 
>anything useful from previous versions" obviously doesn't cut it.
>
> People were a bit too scary I think. Obviously a migration plan must be 
planned and can only be planned if you have the tools like JsInterop, 
elemental2, J2CL to do so. As you see above it does not look that scary 
anymore. A bunch of people are working on migrating GWT code, even the 
tough ones like GWT-RPC / UiBinder (though they require some changes in 
apps because of APT).
 
Current plan is that you must get rid of any deprecated GWT APIs in your 
app as these will finally be deleted. Then you pull in the new libraries 
and update your imports. Finally you have to apply (hopefully small) code 
changes in your app to meet the "no GWT.create(), no JSNI" requirement.


 

> If and when it comes back, it will be a totally new contender (not 
> compatible with anything there ever was as is) to reevaluate, with a huge 
> stain in its history. 
>

A pretty appealing contender. 


-- 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/b3a3ecd2-832d-4bd0-95e4-cabbf1e3c5a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: IntelliJ IDEA project config

[Jens]

It is pretty annoying to setup GWT correctly in IntelliJ :( Quite some time 
ago I had one working, but in the mean time a bit has changed in terms of 
emulation packages and libraries.

You can use the old state as a starting 
point: https://gwt-review.googlesource.com/c/gwt/+/12380 (see Readme before 
opening the project)

One of the major annoyances in IntelliJ is figuring out a way to handle all 
these super source excludes in source folders correctly. 

-- 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/24ae5ed4-95ed-427c-963e-d52e5d8f681e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Naming convention for ported GWT modules

[Jens]

> Fwiw, I can see zero reason why examples would be published to a Maven 
> repo.


Well right, although quite a lot projects do so. But maybe just because 
examples are part of a multi module project and they just deploy everything 
to maven central. That would even be a stronger argument to move examples 
out of each project into a dedicated org.gwtproject.examples namespace. 
Otherwise, when following maven conventions you end up with multi module 
project coordinates but only   deploy a single artifact. Then you would end 
up again with the repetitive 
org.gwtproject.xx.:gwt- pattern.

-- 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/a7df857b-c439-497b-b931-8e2e36215880%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Java10 support

[Jens]

> The next step will be to support Java 10 APIs (we still have some Java 9 
> ones to add) and language features.
>

I have a partial JDiff report (some packages still missing) between current 
GWT HEAD emulation and JDK 10. It is a bit annoying to run javadoc/jdiff 
against GWT HEAD emulation as it does not have module-info files but with 
some preprocessing it is doable. So soon I could either publish the jdiff 
result or directly create github issues for everything I think should be 
emulated. Might also be a good thing to attract some new contributors.

 

> Overall, I think most importantly the work shouldn't really be about Java 
> 10 per se, but rather preparation for Java 11 (the next LTS release)  in 6 
> months and the EOL of Java 8 in 9 months or so. In other words, I, for one, 
> don't really care whether GWT supports Java 10 (it should at least "run" in 
> Java 10 runtime though), as long as it'll be ready for Java 11.
>

For now Java 11 only seem to have JEP 323  
which seem relevant for GWT. Depending on how JDT has implemented the "var" 
keyword, changes in GWT compiler might be minimal when adding Java 11 
support (assuming Java 10 support is already done).


-- 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/66bb315a-4662-48e3-b5a1-8317220771ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Java10 support

[Jens]

Is there a stable Eclipse JDT release supporting local variable type 
inference? Doesn't look like Eclipse itself already supports Java 10 
language features.

-- 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/1ed867c9-60cc-4f83-a49b-be9009943175%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Naming convention for ported GWT modules

[Jens]

What about

org.gwtproject.sdk:gwt-$module and org.gwtproject.sdk:gwt-$module-processor 
(keep the optionally APT module flat within org.gwtproject.sdk group Id)
org.gwtproject.examples:$lots-of-example-apps-using-any-gwt-module-combinations
org.gwtproject.site:...
org.gwtproject.tools:...
org.gwtproject.incubator:...

I can only hardly see GWT modules having more than three sub modules (main 
module, example module, APT processor module). Is there a reason why 
gwt-events has multiple modules? Haven't looked into the code yet. Given 
GWT modules are usually focused I would try to avoid multi module projects 
for them.

I always hesitate to create a multi module project just to bundle some 
example module because the main module name either becomes "core" / "lib" 
or something like that or repeats part of the group ID, e.g. 
org.gwtproject.sdk.*dom*:gwt-*dom* and org.gwtproject.sdk.dom:example (btw 
...:gwt-example would somehow sound silly here actually). So I usually 
prefer a single multi-module example project that contains multiple 
examples. I think this also resembles better what examples are: they use 
some product to show its capabilities, but it does not define the product 
itself. 

-- 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/d8c9f981-77c3-4106-9b6e-d5303a6a6edb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Gerrit Changes and Merging them into master

[Jens]

> It is possible to become a maintainer or what are the criterias to become 
> one?
>

The Steering Committee of GWT decides who becomes a maintainer for a 
specific component of GWT or a global maintainer. 

You can find a bit more information here: 
https://groups.google.com/d/msg/google-web-toolkit-contributors/eq0LsmH2blw/WgCuvRlKFRoJ

Basically you can nominate yourself to become a maintainer, but to get 
accepted you should probably already have contributed and reviewed patches, 
become more active by answering questions in gwt-user and join discussions 
in gwt-contrib so you generally proof you are familiar enough with GWT and 
can handle the responsibility.


 

> I like the project and it would be sad if the project will become inactive 
> due to fewer changes.
>

Fewer changes are actually good these days, because of the transition GWT 
is in. Currently contributors are choosing GWT modules and rewrite them to 
make them J2CL / GWT 3 compatible while maintaining compatibility to GWT 
2.x as much as possible. This work is done mostly on Github so you can't 
see it by looking at contributions in Gerrit. For example there is already 
a gwt-http project on Github which provides the HTTP GWT module and should 
be compatible to GWT 2.x and GWT 3 / 
J2CL: https://github.com/gwtproject/gwt-http

Because of this transition, adding new features to GWT 2.x is unlikely 
because it would further complicate such rewrites. Contributing bug fixes 
to GWT 2.x is fine of course. However GWT is relatively stable and urgent 
bug fixes are rare. So you might indeed get the impression GWT is inactive. 
However that is not really true.


 

> There are also Java9 depeding issue which will not be reviewed for example.
>

Yeah I agree, Java9 support, including new API emulations, should find its 
way into GWT sooner than later. GWT usually has to wait for a good Eclipse 
JDT release as GWT uses it to parse and compile GWT sources. There have 
been some updates recently, but I don't know if anyone at Google is 
actively working on updating the GWT compiler to support new Java 9 syntax 
(e.g. private methods in interfaces).

But if you have free time, you can always start working on API emulations 
even though you can not really test them using GWTTestCase. But you can 
still push them to Gerrit and mark them as "Work in progress" until GWT 
compiler and CI Server are ready for Java 9. But if you really want to work 
on API emulation then you MUST NOT look at source code of Oracle JDK or 
OpenJDK while implementing these APIs to make sure you are not coping them 
intentionally. Otherwise we can not accept such contributions.


-- 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/7564e31e-3abe-4afc-97e7-ef7900dee2ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Gerrit Changes and Merging them into master

[Jens]

Changes can be merged when they have a +2 code review. Currently there are 
only 
three 
https://gwt-review.googlesource.com/q/project:gwt+status:open+label:code-review%253D2

A +2 code review can be done by the Google GWT team and some additional 
people acting as maintainers for different parts of GWT or generally have 
enough trust to do so. A list of maintainers (maybe a bit outdated?) can be 
found 
here: 
https://docs.google.com/document/d/1vyncxfuujIJ3L-PBLNM68tfeXRFZ4qDdnWEodblmvRg/edit

Maintainers / Contributors usually do reviews in their free time, so it 
might take some time to get a +2 and a final commit.

Is there anything specific you want to see merged sooner than later?

-- 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/0f99faec-76e1-4231-b1e7-1654a12298d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

Oh and if its just about making these small projects more discoverable then 
one could also create a single project, e.g. gwtproject/gwt3-migration and 
use the wiki for documentation and/or git submodules to link in all these 
small projects as well.

-- 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/ee2066ec-2b18-4921-8476-6a2195cffecc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

You don't build a house starting with the windows, you need a solid 
foundation. 

IMHO you/we first need to figure out how these smaller projects should be 
handled in the future. Does the gwtproject organization enforce 
requirements on these projects or are they totally independent and just 
sharing a common groupId? Does gwtproject organization still forces CLAs? 
Who would store them? Still Google even though they will probably become 
less involved into gwtproject.org in the future once they are fully moved 
to J2CL? Is it allowed for maintainers to switch from CLA to DCO and use 
pull requests + Github review instead? Or should maintainers store CLAs on 
their own? Maybe it is easier to put everything under the gwtproject 
umbrella into the same repository so a future "Complete GWT SDK" is easier 
to manage/build. 

Maybe most questions have already been answered behind closed doors but for 
me personally there is just to much unanswered questions that I wouldn't 
push anything to org.gwtproject and instead leave things as they are: 
experiments of contributors using their own groupIds. First figure out and 
set in stone the way gwtproject organization, contribution and possibly 
centralized releases (like eclipse releases) should work in the future.

IMHO official libs must go through some official, defined process to ensure 
quality.

-- 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/dd643fda-f7ff-4d49-b9d8-78a34320029a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

> Alternatively, gitter.im/gwtproject/gwt is extremely active, and only 
> missing representation from google. LIkewise could schedule some time to 
> quickly discuss things.
>

There is also https://gitter.im/gwtproject itself which can only be joined 
by members of the Github GWT organization. So this room could be used as a 
gwt-contrib chat.

-- 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/dcb140db-cb06-4cca-8d29-51364f5a95a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Make GWT fun again - what's the status of faster GWT compilation from scratch?

[Jens]

>
>
> Will J2CL and GWT 3 make GWT compilation scale better (faster and/or less 
> memory-hungry for big projects)?
>

Yes, J2CL creates one JS file per Java file. No optimizations, nothing, 
just simply converting from Java syntax to JavaScript ES6 classes. I think 
it has been said that it is roughly as fast as javac compiling a single 
java file to a class file. For production you would then optimize all these 
JS files using closure compiler.
 

> Is any active progress being made on these technologies?
>
Are there any examples out there with a big codebase so we can see the 
> compilation performance difference in action?
> Can we experiment with it on ours?
>

 J2CL is in active development and I guess it will be open sourced this 
year. Once it is released you can play with it and once it is released we 
can see how GWT 3 will look like.

-- 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/7f1df24c-8cac-487f-b60a-aa0e66f9dd36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Question about contributing with java.util.concurrent emulation

[Jens]

AFAICT we want to merge Guava's emulation of JRE classes into GWT itself. I 
think it also includes CountDownLatch.

Maybe you want to check if you have emulated something in addition to 
Guava: https://github.com/google/guava/tree/master/guava-gwt/src-super/java

-- 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/c61703ff-15d2-4ee8-9952-7650e1c3425d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: $entry() wrapper and JsInterop

[Jens]

Take a look at https://gwt-review.googlesource.com/#/c/18540/ for a 
possible solution.

-- 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/72d40ca8-2dd1-41c4-9a94-15e3f29a9bb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: JsInterop & collections

[Jens]

> I believe it was in plans with @JsConvert – see slides 67 – 69. 
> https://docs.google.com/file/d/0ByS1wxINeBWjeGYxbkJpamxFZ28/edit
>

I think this is more meant to be used with non-native JsTypes. When you 
have a JsType implemented in Java and some JavaScript gives you JS through 
the Java object's public JS api. That way you can simply generate a 
delegate method that wraps the Js Array and provides the Java collection 
API on top of it.

However if you use native JsTypes together with JSON.parse() for convert 
JSON back to JavaScriptObjects you are only dealing with a naming 
convention and nothing more. Basically JSON.parse() sees your server 
generated JSON and will construct JS objects natively. Given that 
JSON.parse() only understands JS Objects, JsArrays and primitives the 
native JsType you will cast the result of JSON.parse() into, can also only 
have these types in order to access the underlying data. So if your server 
REST implementation serializes a Map as two JSON arrays (one for keys, one 
for values) then your native JsType also needs two JsArray fields in order 
to access them. The only thing you can do is define a @JsOverlay method 
that returns a Map implementation that wraps the two JsArrays and then use 
that @JsOverlay method in your code to get a Map view.

Given that you can only modify native JSON.parse() behavior to a limited 
extend I don't see any other way how a native JsType could transparently 
add an adapter around JsArrays in a configurable way (different REST server 
implementations might serialize maps in different ways) other then using 
@JsOverlay methods.


-- 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/8e4d0bdb-8dde-45dd-a166-e132efbb1750%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: JsInterop & collections

[Jens]

IMHO if you want a JavaScript array, set, map behave the same as a Java 
collection, so you can use it with other libraries, you should write an 
adapter class that implements the Java API and operates internally on the 
JavaScript data type. 

Basically do not rely on invisible magic. That could easily be implemented 
as a 3rd party project.

-- 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/4d08f88c-ec88-4818-b778-3e0e247f2e7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: CodeServer is using about 500 threads ?

[Jens]

Most likely these are file/directory watcher threads created by Java itself 
because SDM uses Java's WatchService to detect changes. You can 
use -Dgwt.watchFileChanges=false to turn it off. GWT will then do a full 
directory scan to detect changes.

-- 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/9b2155b3-38b9-4c08-8e20-d85c0e63a3e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] POC: Replace Speedtracer with Opentracing.io

[Jens]

I stumbled upon opentracing.io some time ago and while it is primarily 
designed to trace distributed services you can also use it to trace a 
single process obviously. 

GWT compiler can produce speedtracer logs but you can not easily visualize 
them because the Chrome plugin does not work anymore. So I thought I give 
it a try and as a POC I have changed the implementation of the current 
speedtracer event API inside GWT compiler to record timings using 
opentracing.io API (just wanted to avoid updating lots of call sites). As a 
result I can now start SuperDevMode using some JVM system parameters like

-Dgwt.opentracing.tracerImpl=com.example.tracing.zipkin.ZipkinOpenTracingTracer 
(without it a NoopTracer will be used)
-Dzipkin.url=http://localhost:9411/api/v1/spans
-Dzipkin.serviceName=SuperDevMode

and launch a Zipkin server

docker run -d -p 9411:9411 openzipkin/zipkin

(or any other opentracing.io compatible server that stores and visualizes 
the timing information. You would need to implement a different Tracer then)

Now every time SDM compiles, all speedtracer events are converted into 
opentracing.io spans and you get some visualization like:




There are some rough edges to be solved, like a single recompile results in 
multiple traces not yet connected to each other, but I though I'll just 
share this quick POC with you.

Given the future of GWT 2.x I am not sure if it is worth investing more 
time in it but at least it shows that a relatively easy migration would be 
possible to some newer (standard) tools to visualize compiler timings 
again. So if we want to make speedtracer logs useable again this might be 
an option.


-- 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/f60836a4-4fa9-4d4a-b2db-182f8c1e3e38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Time to remove GWT-RPC from WebAppCreator sample app?

[Jens]

I don't think so. There are more important questions to think about, like:

How will GWT 3 look like? Which features will carry over? Who ports what? 
When to start porting, given that JsInterop 1.0 and a beta of 
jsinterop.base is available? Do we create a new repository for GWT 3 to 
give it a clear start with a proper build system? Which one? Do we create a 
new repository for emulation that can be used together with J2CL as a bare 
minimum for people not using GWT? Would we back port emulation to GWT 2.x 
once we push new stuff to the dedicated emulation repository? Does 
gwtproject want to provide an official build tool plugin given that it 
might need one anyways to build itself? 

IMHO there are lots of things to be organized and discussed even with J2CL 
not being released. Does the steering group work on it? Why there are no 
meeting minutes for nearly a year now? I am pretty sure Google would give 
you more insight into J2CL as they are also interested in porting their 
apps to J2CL so you should be able to create a plan.

But to answer your question: I never really used WebAppCreator so 
personally I would just let it generate the project structure with a very 
simple Hello World label. If I want to know how to communicate with a 
server, the web site should tell me in form of a tutorial which describes 
which files and packages to create/modify starting with a nearly empty 
project created by WebAppCreator. For a more sophisticated quick demo, 
people could look at GWT 2.x SDK example projects. If we have any that uses 
GWT-RPC thats fine, it works and will exist for the next years. Maybe 
adding a warning on the GWT-RPC documentation with regard to GWT 3 might be 
useful.

-- 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/f3d05944-9efe-474c-ba53-e86a60435e1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.

[Jens]

>
> Is this still true for elemetal2? I use JsInterop to define DTOs, they 
> area easy and clean, but collections are still a small problem, if 
> elemental solve this will be awesome, but not sure if this is going to be 
> true. New union types can be influenced to be used easily in the JVM too if 
> this is true (I mean, that elemental2 should take care of collections in 
> the browser and the server).
>

So far elemental2 does not do any magic. It is just JsInterop for browser 
APIs. IMHO it is fine that elemental2 is small and focused. Anything else 
should be developed in separate projects.

-- 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/8b63f6fa-9aea-4f08-80e6-ee3f211b733e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Digest for google-web-tool...@googlegroups.com - 7 updates in 1 topic

[Jens]

> Do you plan to open source your Typescript to Java generator ? 
>

elemental2 is generated from closure extern files and not typescript 
definitions. However the generator should also support typescript 
definitions by the time it is open sourced, at least it has been said in 
this group.

-- 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/39f74eab-1fcb-43f4-bc03-08955fa21fff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.

[Jens]

Hmm, I have just built gwt head from source and used the above jars but SDM 
tells me:

 Errors in jsinterop/base/Js.java
 [ERROR] Line 56: JsProperty 'void Js.debugger()' should have a correct 
setter or getter signature.


Can anyone confirm?


-- 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/d460f0fb-6519-4eab-869b-4838e51077ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Experimental release of Elemental2

[Jens]

> What data sources does it consume? Does it take Typescript or Web IDL as 
> input or something else?
>

According to a GWTcon 2016 Video the generator uses Closure extern files as 
well as TypeScript definition files so you can use it to generate JsInterop 
wrappers for lots of JS libraries.

-- 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/eec8a65f-991d-4b88-9dcf-ad6956beb060%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: GWTCon 2015 keynote question

[Jens]

Wow that looks too weird for me to see any value in it :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/b0d5de8a-13e0-4792-b2fb-abcce3554bae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Thoughts on DevMode

[Jens]

> J2Cl itself will likely be built with Bazel (given that even Dagger et al. 
> are moving from Maven to Bazel, I don't think we want to invest in 
> maintaining a non-Bazel build –contributed by "the community"– in parallel 
> to Bazel –contributed by Google–), and our goal as a community will be to 
> help Google distribute it on Central.
> Calling J2Cl from Gradle should be a no-brainer. 
>

> As for GWT 3, if you ask me, it'd be a "rebuild", using either Bazel or 
> Gradle, rather than an evolution of the current repo.
> I'll probably leave it to someone else to build a Maven plugin for using 
> GWT 3, unless my existing plugin works out-of-the-box (depends what tooling 
> GWT 3 will provide), but would happily contribute to a Gradle plugin (the 
> hardest part actually is deciding on a "standard" project layout; this 
> should be done by a specific "working group", not unilaterally by an 
> individual).
>

Yeah I meant GWT 3 with Gradle, not so much J2CL. And yes I would 
definitely start with a new repository for GWT 3 and a separate repository 
for Java emulation that can be used with J2CL without GWT tooling on top of 
it. Given that 2.8 will live pretty long I think it's better to fork the 
emulation into a separate repository because GWT3 / J2CL should not be hold 
back from moving forward integrating new emulation which might require new 
syntax in the future. Yes that would possibly mean back porting emulation 
for 2.8.x if someone needs it but I think that is fine (if it ever happens)

Not sure how comfortable you can import a Bazel project into any IDE these 
days, I guess Gradle is still far ahead. Also conventions help you keep the 
repo clean and consistent.

-- 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/2d70ebf2-90e3-4b78-964a-01cb862af57e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Thoughts on DevMode

[Jens]

>
>
> But this is still handwaving for now, as nobody outside Google has seen 
> J2Cl yet (the Steering Committee, and probably select contributors, should 
> have an early access to it in the coming weeks/months, to have a better 
> sense of how GWT 3 could look like, and possibly help in the opensourcing 
> process –particularly about using it outside Google, e.g. with Maven/Gradle)
>

That would be great. Not only for GWT to finally start thinking about how 
GWT 3 tooling on top of J2CL could look like but also for J2CL to get some 
limited feedback from the outside world. And please, Gradle ;)

-- 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/03a35ba4-8ae1-4ae0-93fd-0a1e72f3ea48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Thoughts on DevMode

[Jens]

Sorry but this will very likely never happen unless you do it yourself 
together with other interested people and manage it on Github as a 
community project. Google (GWT's main committer) invests in J2CL + Closure 
Compiler in the future so they won't do it and current contributors will 
likely favor SDM and don't want to manage a custom chrome build (at least 
that is my impression).

I think you never really dived into SuperDevMode. Take GWT 2.8, start SDM 
with -style PRETTY and disable sourcemaps in Chrome to see the real JS. Now 
search for any method name and take a look how GWT sets up classes and 
methods in JS. Once you understand that (really easy to understand the 
basics) you can easily find what you are interested in, use watch 
expressions and set conditional break points. You can also hover variables 
to see their content if you do not use sourcemaps. Given that GWT doesn't 
really optimize the JS code all the Java methods in your project will look 
pretty similar in JS. If J2CL plays out nicely and GWT 3 will be build 
around it, then the generated JS will likely even more look like Java as it 
will use ES6 JavaScript classes. So the need for sourcemaps (and its 
disadvantages) during development will be questionable.

DevMode had its time, I never really missed it. It's slower than SDM, you 
can not use it do develop directly on mobile devices (granted with SDM and 
a certain app size its also not possible because the SDM JS is so large 
that it crashes the mobile browser), DevMode had executed Java code in JVM 
which sometimes had different behavior than the compiled JS which could 
lead to bugs in production you can't reproduce in development unless you 
compile your app. IMHO SuperDevMode is superior to DevMode once you make 
yourself comfortable with Chrome and its DevTools.

The only sad thing is that SDM still has some hard to reproduce bugs that 
every now and then show up during development which require you to cleanup 
the cache and start fresh.

-- 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/0df0b925-befe-4b5a-ba77-702169aa5d61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Utils

[Jens]

I like it. IMHO if utility methods depend on something other than pure JRE 
they should live in their own utility class for that 
package/library/purpose. So I would be fine with W3cDomUtils, 
SpeedTracerUtils, etc. 

-- 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/ef94e2e8-0ff1-4a7a-b4ce-b5363c8b7b90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Newbie - not able to add patch

[Jens]

GWT is hosted at https://gwt.googlesource.com/gwt and only mirrored 
(read-only) to Github.

If you want to contribute you must push your patch to 
https://gwt.googlesource.com/gwt . To do so you need to signup to Gerrit, 
sign a CLA, obtain and install a HTTP password and finally install Gerrit's 
commit hook.

http://www.gwtproject.org/makinggwtbetter.html#checkingout
http://www.gwtproject.org/makinggwtbetter.html#submittingpatches

-- 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/3d02dfc4-ab8c-4e99-b5e2-2c0e1935b245%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

IMHO it's a small enough addition that totally makes sense and it's nothing 
that would block any future direction of GWT. I don't see any real reason 
to not accept the contribution.

The points mentioned are either clunky (pull in a complete different 
library just to get a single small feature or use some workarounds), won't 
happen anytime soon (replacing GWT SafeHtml with safe-html-types or wrap it 
around) or are simply pointless (J2CL not released, no fully worked out / 
discussed future plan for GWT 3.0). 

The only valid point might be code size increase and runtime performance, 
but thats a valid point for every contribution and should simply be worked 
out until it's acceptable.

IMHO contributions shouldn't be handled too picky as long as there is no 
concrete plan for GWT 3.0. Nowadays we have GWT 2.8 and a contributor wants 
to improve it, that's it, very simple. I'll probably give +1 after 
rethinking the code size / performance point and a maintainer for SafeHtml 
should give +2 once the code is fine.

-- 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/8826b9ee-f889-4f9d-be8c-1cb13fe2576e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: PROPOSAL: a devserver to replace devmode

[Jens]

Well it is just what I would ask for in order to replace local apache / 
nginx on developer machines with GWT devserver. It's not a problem to 
simply continue using a dedicated proxy either with CodeServer or a "no-op" 
devserver. 

Basically our setup is more a less the result of two decisions: Not serving 
static content from servlet containers (instead it's severed by load 
balancer/proxy) and using GWT-RPC. We need to be in control of which app 
version a customer gets served, even before logging in, and that backend 
requests will be redirected to a matching server app version (because of 
GWT-RPC policy files and rolling updates). Thats why our production mapping 
is https://app.example.com// => /_/ for 
backend requests and the load balancer does the mapping using URL rewriting.

During development we just have a single app so the rewriting is a lot 
simpler but it still exists. Given that our server code sets cookies for 
the production domain only (I guess some paranoid security decision), the 
cookie domain needs to be rewritten during development to a local ip / 
localhost.

Given that static content is served by the load balancer / proxy itself, 
all caching headers (*.nocache.*, *.cache.*) are configured outside the 
servlet container. For consistency cache headers for dynamic host page are 
also configured outside the servlet container. So we don't have any 
ServletFilter doing it.



Hey, this is a currently just a prototype coded over the week-end ;-)
> I'd personally prefer not writing anything to the webapp, but as 
> acknowledged in the OP we could have a -launcherDir option for 
> serialization policies and possibly public resources
>
(but then why not just use CodeServer with -launcherDir directly? one 
> difference could be that devserver would never overwrite a file for 
> example…)
>

Well I could also ask: Why not just having a single solution that simply 
works? Personally I don't like having different "entry points" for 
development. IMHO its more straight forward (especially for beginners) to 
just have CodeServer or just have devserver, but not both (even with 
different behavior for stub.nocache.js !). 

Adding gwt.codeserver.host and renaming -launcherDir to -publicResourcesDir 
would be fine I guess.
 


Next there are people embedding the module.nocache.js file directly into 
>> their host page (like me ;-) basically our host page is a servlet) and that 
>> should work also during development.
>>
>
> I can't think of any other way to make it work (I did that too in one app) 
> than having a way to switch from inlined *.nocache.js to external 
> *.nocache.js on your server. There's absolutely no risk shipping that in 
> production (it's only a network optimisation to avoid one HTTP request) so 
> it looks like an acceptable compromise to me.
>

Well devserver could special case host page loading ("/" or a configurable 
host page url) and inspect the result of the backend server to decide 
wether or not some inline *.nocache.js file needs to be replaced. To keep 
it simply I would require special enclosing start / end comments in the 
dynamic host page to make it compatible with devserver. Then the content in 
between these comments will be replaced with the stub.nocache.js.


 

> …or you could just continue using CodeServer with -launcherDir.
>

Single solution preferred ;-)

-- 
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/361aafb5-d40d-433c-a6ba-6209069e5550%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: 2.8 (final) is released very silent!?

[Jens]

The release is 2 days old (yes it's already on maven central) and will 
likely be announced once release notes are merged and uploaded. 

Github just says it's 17 days ago because the commit that has been tagged 
is 17 days old.

-- 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/290d06b6-59de-47e6-8142-b25d72b5dbb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: GWT 2.8.0 RC3 is here!

[Jens]

> Sorry for bothering you, but what about notes ?
>

You can look at the commit log for now:

https://github.com/gwtproject/gwt/compare/2.8.0-rc2...2.8.0-rc3

-- 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/f99c4b2f-339c-46d4-995b-32d572878c91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Last call for 2.8.0-RC3

[Jens]

> Thank you I will try that -strict option.
>
> My suggestion is that exported @JsType (when the -generateJsExport option 
> is turned on) should be considered as entrypoints and generate compilation 
> errors, what do you think ?
>

I think that -strict should be the default everywhere. I don't really see 
any value at all in not using -strict. Maybe some people do but then they 
should disable -strict. I use it since I use GWT and never had a reason to 
not use it.

-- 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/d28e825a-c095-4812-a1c8-99527ba88f06%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

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

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

[Jens]

Ok just tried it myself.

Created a new, fresh project having world in my host 
page using

public void onModuleLoad() {
  Global.window.alert("Element found: " + (Global.document.getElementById(
"hello") != null));
}


GWT 2.8 RC2 returns true

_.onModuleLoad_4_g$ = function onModuleLoad_3_g$(){
  ($clinit_Global_0_g$() , $wnd.window.window).alert('Element found: ' + 
jsNotEquals_0_g$(($clinit_Global_0_g$() , $wnd.window.document).
getElementById('hello'), null));
}



GWT 2.8 SNAPSHOT (09.09.2016) returns false

_.onModuleLoad_4_g$ = function onModuleLoad_3_g$(){
  ($clinit_Global_0_g$() , window).alert('Element found: ' + 
jsNotEquals_0_g$(($clinit_Global_0_g$() , document).getElementById('hello'), 
null));
}



So I guess its a bug in GWT 2.8 SNAPSHOT as I think the JS output of GWT 
2.8 SNAPSHOT should be that way it is above if @JsType(isNative = true, 
namespace = "window") is used. However elemental2 uses JsPackage.GLOBAL as 
namespace.


-- 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/25c12ba5-120c-47e0-b52a-c386691b9618%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

> This scoping is all very confusing :-).
>
> Anyway, this is what I am seeing with Elemental2:
> - I have an application that generates HTML using a custom templating 
> system.
> - I then put the HTML string in an Element with setInnerSafeHtml.
> - After this I use Element2 to bind to the generated html. For that I was 
> using Global.document.getElementById(...).
>
> This used to work, but since a few weeks this stopped working.
>
> I now have to use Global.window.top.document.getElementById(...) to get 
> access to the ui dom nodes that I generated.
>
> Is this how it is supposed to be ? I was probably making the wrong 
> assumptions before ?
>

No. Elemental2's Global class uses @JsType(isNative = true, name = 
"window", namespace = JsPackage.GLOBAL) which translates to $wnd.window 
because JsInterop qualifies everything with $wnd (unless namespace="window" 
has been set as of the commit you have referenced before), JsPackage.GLOBAL 
is an empty namespace and window is the name.

Are you sure nothing has changed in your app ?! I don't think something has 
changed in GWT as such (breaking) changes would normally cause more posts 
on gwt-contrib / gwt-user.

-- 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/9b7a6321-c9ca-44a8-bd8d-01e6dc113f13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

Hm wondering how it ever worked for you as JsInterop usually qualifies JS 
code with $wnd but your D3.js has been injected into the GWT iframe. So 
AFAICT with JsInterop you would had to use TOP_WINDOW anyways. You can make 
it work within the GWT iframe but then you can't use JsPackage.GLOBAL but 
use a namespace that points to the iframe content window.

Also 
see: https://groups.google.com/d/msg/google-web-toolkit/GcsWUuzexvE/ApUg3sLZCQAJ

So it looks like this behavior has changed? But yes you would need to use 
"window" now to references the iframe's content window if you inject the 
code into the iframe.

-- 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/e8cbcef6-1bd8-43e3-b63b-89a1d659e12f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

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

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

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

-- J.



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

[gwt-contrib] Re: Eclipse Code Server Launcher Icon

[Jens]

I guess the future is CodeServer + optional external servlet container.

So IMHO it would be more straight forward to just have "GWT Web 
Application" which always launches CodeServer.main() directly and not 
through DevMode.main(). Within this run configuration you can optionally 
choose to automatically launch an external servlet container as well, e.g. 
through Eclipse WTP or by running a second run configuration like a maven 
goal / gradle task or a terminal command.

=> normal GWT icon


If you want to support the legacy guys there would be "GWT Web Application 
(legacy)" which would launch classic DevMode

=> GWT icon with some standard Eclipse server icon


-- 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/6e8f5a16-6d20-41b2-bb99-bb3964cbfda7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

[Jens]

> Jens is spot on. We want people to explicitly use 
> -generateJsInteropExports if they rely on exporting since it has a hit on 
> code size.
>

Maybe the mention of the parameter should be added to the JsType JavaDoc 
for a final 2.8 release.

-- 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/6ea6ad27-695d-4eec-8e0c-c2a49be9a422%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

[Jens]

Because all these non native JsTypes are considered entry points to your 
application when they are exported and thus all code referenced by them can not 
be pruned and maybe some other optimization a can't be applied to it as well.

Now consider GWT libraries that use non native JsTypes to export their API to 
JavaScript so they can be used by an Angular UI or similar. If it would be the 
default then lots of apps would miss optimization opportunities just because 
they use the libraries and might not use any pure js at all.

This is especially harmful as the flag is an all or nothing flag. So you have 
to explicitly decide to export to JS. in the future you should also be able to 
define a regex which tells the compiler which classes to export. This will be 
helpful if you depend on multiple such libraries but your app only needs to 
export one if them as well.

-- 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/e7654865-f07e-4b45-8b82-dd8ebbb0b113%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Hide GWT Development Mode window

[Jens]

You can also just launch CodeServer.main() unless you somehow need the 
embedded Jetty server launched by legacy DevMode class for your server side 
code (although IMHO its better to have CodeServer and Servlet container in 
two different processes so you can relaunch them separately). CodeServer 
does not have any Swing UI.

-- 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/4e717248-3f85-4c26-a724-5b5f0f699e0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

[Jens]

@JsType with isNative = false (the default) are probably treated as normal 
classes now if you do not use -generateJsInteropExports as compiler 
parameter. I guess it works again if you use the compiler parameter?

-- 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/3f124c9c-f38b-413b-91c9-ab1c0c741e24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

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

[gwt-contrib] Re: gwtproject.org site

[Jens]

Why don't we use Github pages with custom domain? Never looked into the 
code, does the servlet anything special?

-- 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/ba7d3311-fb22-4729-a704-251dd49e4702%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: GWT 2.8.0 RC1 is here!

[Jens]

You should file a bug on the maven plugin issue tracker 
https://github.com/gwt-maven-plugin/gwt-maven-plugin

-- 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/526d06dc-682b-4263-9cdb-16d5488acadc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

[Jens]

> It only works with the generateJsInteropExports flag set though.
>

Sounds like a bug to me.

-- 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/1267a22f-0496-4bb1-abb3-e0b66af18311%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Bean Validation

[Jens]

>
> I thought, removal would not be done before gwt 3.0...
>

Thats right. Validation will still be present in 2.8, its just marked 
deprecated. The change Thomas has made won't be committed before 2.8, but 
you can use it to determine what needs to be extracted into your external 
project. You can then also use it to build a custom GWT without validation 
and use it together with your external project to see if things work as 
expected.

-- 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/69eca171-19a2-4bbf-a2e5-f711e3b6bca0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

[Jens]

> > - often method signature defines Object as return type while I am pretty 
> sure something more concrete would be more appropriate.
>
> if a method "getFoo" can return different types "string or Foo", we create 
> different methods :
> public Object getFoo();
> public String getFooAsString();
> public Foo getFooAsFoo();
>
> In the future there will be javadoc above the methods mentioning these 
> links between a set of methods.
>

What about methods that do not return different types and sometimes even 
should return void? For example 

void Window.alert(String)
void Window.focus()
long Date.setDate(int)

They all return Object currently.

-- 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/fa7580d3-f355-44e1-a923-c588b3c6da45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

[Jens]

> I do think we should have another library that builds on Elemental2. While 
> browser compatibility is a lot better, it still isn't perfect and we need 
>  somewhere to collect workarounds for specific issues and add helper 
> functions to make working with the library easier.
>

But then you have the GWT overhead on top of it again. But I tend to agree 
that a purely generated API can never be that nice to use as a hand crafted 
one. I have only taken a very brief look at the generated code of the 
elemental2 snapshot build but I think my major points are:

- vendor prefixes. Sticking to standard API and asking devs to polyfill 
them if needed sounds better to me. Avoids potential API duplication.
- only doubles while int would make sense here and there
- no use of generics and enums
- no packages. Would be nice to have things like dom, crypto, promise, 
audio, webgl, etc.
- often method signature defines Object as return type while I am pretty 
sure something more concrete would be more appropriate.
- obviously no JavaDoc, but it would be nice to have. Especially for people 
working in a no-internet environment.
- edge cases like EventTarget.addEventListener(EventListener) and 
EventTarget.addEventListener(AddEventListenerListenerCallback) that should 
be cleaned up

Maybe it is worth thinking about providing some patch files in addition to 
the generator to fix some stuff that are hard to fix inside the elemental2 
generator. Given that existing non-prefixed API does not change these patch 
files should be pretty stable and always applicable.

-- 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/71f5352a-41dc-4f91-a22b-9a9bb21b8bbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Current snapshots failing with JDK 7

[Jens]

Hm maybe something like

https://github.com/gwtproject/gwt/commit/3586e7bc10777c7d479889a5f20927cbf2aceb97

is needed for SerializedLambda as well?

-- 
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/c954dc1d-7414-458e-b9e4-2491df782eba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Compile specific files only

[Jens]

> Without any background, the question is how can I add a compiler option so 
> that the source inside a module is compiled without resolving its 
> dependency? For example, a module as simple as below
>
> 
>   
>   
> 
>
> Only the .java files inside utils folder are translated into javascript.
>


Not sure if I understand you. If the code inside the utils folder 
references a GWT button then the code of the GWT button must be available 
somehow, otherwise your utils code simply won't work. Given that GWT 
requires whole world knowledge during compilation the GWT button code is 
pulled in from the inherited User module (or more specific the indirectly 
inherited UI module). If you are saying you want to link against some 
pre-existing GWT button code, then thats not possible and I would assume 
you would need to write a new compiler instead of just adding a compiler 
option.

>From what I understand you want some plugin system for AppInventor to 
circumvent the mentioned "whole world knowledge" requirement of GWT. The 
usual way to solve this is to have AppInventor publish a JavaScript API 
using GWT JSNI or JsInterop and then let 3rd party developers write their 
component mocks against this stable JavaScript API. In general this would 
also allows 3rd party developers to use something different than GWT to 
build their component mocks. If done correctly the AppInventor app can then 
import these 3rd party component mocks at runtime by adding an additional 

Re: [gwt-contrib] Re: Experimental release of Elemental2

[Jens]

> Thanks, now makes sense. I get confused with the JsFunction JsType(native) 
> because elemental2 has some callbacks as JsFunction and others as 
> JsType(native), now an actual elemental2 question; what criteria is used to 
> apply JsFunction (ex. elemental2.Node.AddEventListenerCallback) instead of 
> JsType (ex. elemental2.JsType)?
>

I think its the result of definition of EventTarget.addEventListener():

*listener - The object that receives a notification (an object that 
implements the Event 
 interface) when an 
event of the specified type occurs. This must be an object implementing the 
EventListener 
 interface, 
or simply a JavaScript function 
.*

The EventListener interface is a defined API and thus a @JsType(isNative = 
true) interface has been generated. But to conform to "or simply a 
JavaScript function" there is also an AddEventListenerCallback that is a 
@JsFunction. Not sure if this distinction has any real value, in a hand 
coded elemental2 I would have only created a @JsFunction interface 
EventListener

-- 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/73b36bdb-c496-4768-a221-21fe8b5a437c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: GWT 2.8 rc1 work items

[Jens]

I think we should go through Gerrit and create a Github issue for every CL 
that we definitely want in final 2.8 (so we can track it using Github 
milestone, or is there some sort of tagging feature in Gerrit that we can 
use to mark CLs for 2.8?) and then concentrate on reviewing these.

Personally I would say:

- Emulation of ArrayDeque, BitSet
- Java 8: Collections.unmodifiableNavigableMap, unsigned numbers
- Various emulation fixes for edge cases and better JDK compatibility
- Anything related to JsInterop

Personally I work on Java8 Base64 emulation but don't know when I will 
finish it. Andrei has a draft on Gerrit for Java8 CompletableFuture which 
will be based on Promises/Promise emulation. But that one will probably 
still take some time to complete. Also this CompletableFuture patch 
includes some emulation of java concurrent classes that are currently 
emulated by Guava. IMHO we should generally include Guava JDK emulations 
into GWT proper so non Guava users can benefit from it as well. Maybe thats 
something we want to do for 2.8? Given the Guava license its just a matter 
of coping/moving their classes to GWT.

-- 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/09c9e3bb-d200-4cc0-93a3-80d0d3c92852%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Future direction for common JS api's

[Jens]

Given that Elemental 2 is developed behind closed doors, I would guess it 
can take TypeScript definition files and/or some IDL input to generate JS 
APIs for GWT / J2CL. That should cover nearly all Web APIs. 
IMHO TypeScript definition files would be preferred because there are tons 
of them on https://github.com/DefinitelyTyped/DefinitelyTyped for all kinds 
of JS libraries and Web APIs. It also has a definition for the Fetch API: 
https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/whatwg-fetch 

It would be a shame if Elemental 2 would not understand them to generate 
APIs. These files are basically what JSweet uses to generate their Candies 
(http://www.jsweet.org/candies-releases/). But even if Elemental 2 only 
takes IDL input or html5index.org as input it should cover all standard web 
APIs.

-- 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/c72a2088-bc6a-4836-9312-518ec56507cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

> The issue is that @JsFunction implementors must "extend 
> java.lang.Object" as their parent. because standard library functions 
> are/canbe implemented on classes with complicated type hierarchies, 
> this would cause failures to compile. 
>
> This restriction comes about from the efficiency trick we use to 
> reparent a lambda to have the native JS Function object as it's 
> parent. We can't reparent objects whose immediate supertype isn't 
> java.lang.Object, but not doing this trick would make output more 
> bloated/slow, and wouldn't allow Java8 lambas to act like JS functions 
> (e.g. can call Function.bind/apply/etc on them) without some kind of 
> wrapping/unwrapping process, plus an additional level of hacks to make 
> sure referential integrity was preserved. 
>

Can you elaborate on it? I think its really annoying that every project 
must redefine callbacks, functions, consumers, whatever just because JRE 
has some default methods in their version and GWT can not handle it. IMHO 
convenience is the most important thing here.

For example wouldn't it be possible to redefine the way @JsFunction works 
so something like:

1.) @JsFunction marks a parameter to be a functional parameter
2.) The type of the parameter that is marked with @JsFunction must have 
exactly one @JsFunctionTarget in its class definition
3.) @JsFunctionTarget marks an abstract method in an interface or in an 
abstract class.


Then we would do something like

@JsType(native = true, ...)
class SomeAsyncClass {
  void onSuccess(@JsFunction Consumer onSuccess);
}


interface Consumer {
  @JsFunctionTarget
  void accept(T value);


  // other default methods
}



JavaScript:

var asyncClass = new SomeAsyncClass();
var someConsumer = // ...anything that has implemented Consumer
asyncClass.onSuccess(
  function(value) {  // @JsFunction tells GWT to generate a "bridge" method 
using the parameters of @JsFunctionTarget and delegates to the 
Consumer implementation
someConsumer.accept(value);
  }
);


The above is probably not fully correct JS and maybe has some "this" 
problems but I think you get the idea. Marking parameters as @JsFunction 
would allow you to choose wether or not you want GWT to handle a Consumer 
as callback or as ordinary object, e.g. if you do not annotate a parameter 
of type Consumer with @JsFunction then it will be passed as normal object 
without any bridge methods that delegate to a @JsFunctionTarget method.

Wouldn't this be possible?

-- 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/db6a7e36-b288-4107-90f2-6b66b696779c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Configurable checks for GWT

[Jens]

Hm ok, I think I got it. I would say my Arrays.sort() example should 
actually use a critical check then because array.slice() can do lots 
unexpected things (negative indexes for either argument works but results 
an unexpected subset of array items to be sorted, toIndex can be larger 
than fromIndex which basically results in no sorting at all) compared to 
Java. A critical check would make sure that follow up code can expect the 
array to be sorted they way its meant to be.

I guess in some cases its just tough to draw the line.

-- 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/28e222a3-9138-447c-aeaa-a2daca59ccdd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Configurable checks for GWT

[Jens]

Sometimes I am not sure if we should use a normal or a critical check.

Basically my understanding is that we should use a normal check if the code 
would also fail (but obviously with a JS error instead of a required Java 
Exception) with an error if the check was not present. If the code would 
fail pretty late and debugging will be difficult we better use a critical 
check instead to help debugging. However if the code will not fail if a 
check has been compiled out then we should always use a critical check, 
especially if JavaDoc requires the code to fail. Is that correct?

Here are some examples I struggle with:

1.) checkNotNull() if JavaDoc requires NPE to be thrown in all cases.

void forEach(Consumer c){
  checkNotNull(c);
  for (T item : items) {
c.accept(item);
  }
}

JavaDoc says NPE must be thrown if consumer is null. If checks are compiled 
out, for the special case that items is empty it would not fail with a 
normal check, so we should use a criticalCheckNotNull() right?

2.) checking position indexes during index operations on arrays/lists

public static void sort(byte[] array, int fromIndex, int toIndex) {
  checkPositionIndexes(fromIndex, toIndex, array.length);
  nativeNumberSort(array, fromIndex, toIndex);
}

private static native void nativeNumberSort(Object array, int fromIndex, int 
toIndex) /*-{
  var temp = array.slice(fromIndex, toIndex);
  temp.sort(function(a, b) {
return a - b;
  });
  var n = toIndex - fromIndex;
  
@com.google.gwt.lang.Array::nativeArraycopy(Ljava/lang/Object;ILjava/lang/Object;II)(temp,
 
0, array, fromIndex, n)
}-*/;


The above is some existing code in GWT. If checks are compiled out 
nativeNumberSort() could get indexes with fromIndex > toIndex. JavaScript 
slice() will then return an empty temp array that will be "sorted" and 
passed on to nativeArracopy() which in turn won't fail as well. So at the 
end the check should have been a critical check, shouldn't it?


-- 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/b3bc70c4-be2c-4fd1-a750-c5ada03caeed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

>
>
>
>- add new features to existing generators / linkers
>
>
I think to some extend some new features should also be fine if they are 
related to Java 8. For example I could see GWT-RPC being improved to better 
support lambda/method references in the future.

-- 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/1898a4b0-3eff-4e53-8aba-19e1851a646f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jens]

Of course generators and linkers should be maintained, especially if it 
allows user code to be made more Java 8 friendly. I am pretty sure quite 
some GWT users will have large applications that will stay on 2.8 as long 
as possible because its too costly to rewrite these apps. However they will 
likely use Java 8 sooner or later and Java 8 friendly APIs should be added 
to GWT 2.8.x over the time.

I think its an error to assume that the current GWT compiler / generators / 
linkers should never be touched again just because Google is working on 
J2CL behind closed doors. J2CL is a different product and honestly GWT 3 
will also be a different product if its based around J2CL.

So if Google engineers do not want to invest a huge amount of time in the 
GWT compiler anymore because they want to move all internal apps to J2CL in 
the long run then thats fine. However that should not prevent improvements 
to the current state of GWT. If I would be able to review the code of Colin 
I would do it but I do not have the knowledge of internal GWT compiler 
stuff. That actually brings me to my personal next point: It would be great 
to have an in-depth compiler documentation.


-- 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/94d40741-e31e-479e-9e16-e76879723560%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: How to unit test JsInterop code

[Jens]

Depending on what exactly you want to test I would try hard using plain 
JUnit with mocking / stubbing. Testing @JsType(native = true) annotated 
interfaces / classes probably does not make a lot of sense given that the 
underlying JS code should already be tested and given that GWT itself has 
tests to ensure that JsInterop works correctly. 

But in general GWTTestCase should just work with JsInterop because they 
should be executed in web-mode by default now.

-- 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/154e0a3f-5c8a-4f51-92db-4febf3b7fca2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.