Re: [gwt-contrib] gwtproject.org migration, https support

['Goktug Gokdogan' via GWT Contributors]



On Mon, Mar 28, 2022 at 8:44 AM Juan Pablo Gardella <
gardellajuanpa...@gmail.com> wrote:

> Thanks Colin! Great work
>
> On Mon, Mar 28, 2022 at 12:37 PM Colin Alworth  wrote:
>
>> We've successfully migrated the gwtproject.org website to a new domain
>> name server and new hosting, at Google's request. There are a few small
>> differences from the old hosting:
>>
>>
>>- HTTPS is now supported and enabled, though not yet mandatory, to
>>allow a period of migration, and making sure that no downstream tools will
>>break as a result of these changes. HSTS is also disabled for now. I
>>propose that mid-week I will update this to always redirect to HTTPS, and
>>then in another two or three weeks consider enabling HSTS if there have
>>been no reported issues.
>>- The samples.gwtproject.org domain now redirects to the showcase,
>>rather than giving a confusing 500 error. The samples are still at this
>>time hosted as static content rather than servlets.
>>- The GWT application that enhances the documentation has been
>>updated, picking up changes published ~2 years ago.
>>- Deep links that omit "www." (for example
>>gwtproject.org/doc/latest/DevGuide.html) will now redirect to the
>>expected page (in this case
>>www.gwtproject.org/doc/latest/DevGuide.html) rather than redirecting
>>only to www.gwtproject.org.
>>
>>
>> Building and deployment of the new site is currently described at
>> https://github.com/Vertispan/gwtproject.org, and should be hostable with
>> or without DNS entries or HTTPS (though handling your own dns for "
>> gwtproject.org" itself may eventually conflict with HSTS). The README
>> contains some basic details on how the hosting is structured and how to run
>> on any arbitrary server. There is also a TODO list at
>> https://github.com/Vertispan/gwtproject.org/blob/main/TODO.md, which
>> could eventually be migrated to actual github issues.
>>
>> This could have been implemented through a similar build process that
>> then pushed to github-pages, but at least for now we decided against this.
>> Once some kind of continuous integration is in place to create pre-built
>> artifacts for gwt-site-webapp and gwt-site itself, it might make sense to
>> reconsider this, but for samples it still may make sense to use custom
>> hosting to phase out the current static-only samples and provide some
>> samples which can interact in some way with the server.
>>
>> If there are no objections to the current layout, configuration,
>> deployment, and documentation, I propose migrating this project to
>> github.com/gwtproject, as well as following up on the bullet points of
>> the TODO list.
>>
>> --
>> 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/94a1c877-78ac-40ea-9084-405514b8b3d4n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2BkiFsf5SR%2BvhiEPWUJK8vWiwPfSPfuOUxAXnTzX0MBqp0eWXQ%40mail.gmail.com
> 
> .
>

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

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

['Goktug Gokdogan' via GWT Contributors]

I highly recommend dropping IE11 as well in the next release. It will be no
longer supported by Microsoft and GMail and Google Workspace will be
dropping its support in March 15:
https://workspaceupdates.googleblog.com/2020/12/ending-support-for-ie11-for-all-google-workspace.html

That means internally we will stop testing and developing for it and things
may start breaking over time.

On Wed, Mar 10, 2021 at 1:21 AM Thomas Broyer  wrote:

> Fwiw, a change in GWT emulation of longBitsToDouble and doubleBitsToLong (
> https://gwt-review.googlesource.com/c/gwt/+/23140) has landed that uses
> Typed Arrays. This means they won't work in IE8 and IE9 anymore:
> https://caniuse.com/typedarrays
>
> Maybe it's time to remove support for those old versions? (it's long
> overdue if you ask me)
> I'd actually go as far as only keeping IE11 for the time being (which uses
> the gecko1_8 permutation).
> A first step might be to disable them by default, like we did for the ie6
> and opera permutations in 2.6, removed in 2.7.
>
> Fwiw, for a while now, gwt-maven-archetypes has had  name="user.agent" value="ie10,gecko1_8,safari" /> (i.e. it already disabled
> ie8 and ie9), and I'll change it to gecko1_8,safari soon.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/5adb9f2d-d8df-45c9-a084-d361df389979n%40googlegroups.com
> 
> .
>

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

Re: [gwt-contrib] Re: Required JDK version to build GWT?

['Goktug Gokdogan' via GWT Contributors]

(which you already pointed but what matters me the most :))

On Tue, Jun 30, 2020 at 11:39 AM Goktug Gokdogan  wrote:

> Super sourcing with tests is errorprone; it is easy to get one method
> added in one version but note the other and basically you end up testing
> nothing.
>
> On Tue, Jun 30, 2020 at 1:36 AM Thomas Broyer  wrote:
>
>> So, IIUC, there are 2 distinct issues, but both related to JDK versions.
>>
>> First, the doclet/taglet where JDK8 has com.sun.javadoc and JDK9+ have
>> jdk.javadoc.doclet. This is an internal tool, so it would be wasted effort
>> to maintain 2 versions. Either we keep the current code and require JDK8,
>> or we migrate to the new API and require JDK.lts or JDK.latest. Those
>> requirements only apply to building the javadoc though, i.e. to actually
>> cut the releases.
>>
>> Next, the tests. If we want to be able to test JDK9+ syntax and/or APIs,
>> then we either have to require such a JDK (for those tests at least), or
>> supersource the code so it can run with JDK8.
>> So what are the pros and cons?
>>
>>- Require a specific JDK:
>>   - do we require JDK.lts? or JDK.latest? (currently, JDK.lts would
>>   be enough, but as soon as we add newer language syntax and/or APIs, 
>> we'd
>>   have to use JDK.latest to test those)
>>   - do we require it only for those specific tests (aka "use ant
>>   filters") or for the whole build? (and using "--release 8" for non-test
>>   code to target JDK 8; BTW, can we use "--release 8" at all? not all 
>> JDK8
>>   APIs are available that way, specifically "internal" APIs)
>>   requiring recent JDKs for the whole build means we no longer test
>>   with JDK8, and we *have* to migrate the doclets to the new API.
>>   Those are rather big cons if you ask me.
>>   - Assuming ant filters then:
>>  - pro: tests are easy to write/maintain, you only have to
>>  follow a naming convention for the test class
>>  - con: testing everything requires the JDK.lts/JDK.latest;
>>  running the tests with JDK8 only covers JDK8-compatible code. If we 
>> keep
>>  the doclets on JDK8, this means we have to run the build twice when 
>> cutting
>>  a release: once with JDK.lts/JDK.latest to make sure the tests 
>> pass, and
>>  then once with JDK8 to actually build the artifacts.
>>  - con: requires setting up the new JDKs, and new jobs, on the
>>  CI server. If we keep using the current build.gwtproject.org,
>>  this puts the burden on Google; that'd likely precipitate the 
>> replacement
>>  of the server.
>>  - con: requires 2 builds to make sure things still build/run
>>  with JDK8
>>   - Supersourcing
>>   - pro: tests can run with JDK8, so the whole build is
>>   JDK8-compatible and still covers all tests
>>   - con: requires somehow maintaining the tests twice, keeping the
>>   javac'd and supersourced versions in sync (AFAIK, the javac'd version 
>> has
>>   to have the test methods so they're detected by JUnit, even if their 
>> body
>>   is empty; so it would be rather easy to add a test to the supersourced
>>   version and never actually run it because the method is missing from 
>> the
>>   javac'd version)
>>
>> The situation requiring the minimum effort in the short term would be
>> keeping the doclets as they are and using supersourcing for the tests.
>> In the long run, as JDK9+ tests grow, supersourcing might become
>> unsustainable, but the impact on the CI server et al. is non-negligible. We
>> could still possibly, at least temporarily, build only with JDK8, and only
>> run the JDK9+ tests once in a while (at release time?), manually on a
>> developer's machine as a smoke test.
>>
>> So, my vote would be: "require JDK8 for javadoc, supersource tests", with
>> a fallback to an option you didn't list: "Allow any JDK 8+, use ant
>> filters, only actually produce javadoc on JDK8 builds", and if/when someone
>> wants to put the effort then migrate the doclets and move on to your third
>> option: "allow any JDK8+, use ant filters, only actually produce javadoc on
>> JDK9+ builds"
>>
>> On Tuesday, June 30, 2020 at 3:45:36 AM UTC+2, Colin Alworth wrote:
>>>
>>> As of somewhere in the time leading up to the GWT 2.9.0 release, it is
>>> no longer possible to build GWT with Java7, and similarly the decision was
>>> made to no longer officially support running on Java7
>>> (jsinterop-annotations use of "TYPE_USE", newer jetty version too I
>>> believe).
>>>
>>> There is still some defunct wiring in the build to handle Java 7 vs Java
>>> 8 though, mostly with regards to running tests - since we first javac our
>>> java classes, and then run gwtc on them, we need to make sure that the java
>>> version being use can correctly compile those tests.
>>>
>>> The issue https://github.com/gwtproject/gwt/issues/9683 is tracking
>>> some of the existing work on this: the 

Re: [gwt-contrib] Re: Required JDK version to build GWT?

['Goktug Gokdogan' via GWT Contributors]

Super sourcing with tests is errorprone; it is easy to get one method added
in one version but note the other and basically you end up testing nothing.

On Tue, Jun 30, 2020 at 1:36 AM Thomas Broyer  wrote:

> So, IIUC, there are 2 distinct issues, but both related to JDK versions.
>
> First, the doclet/taglet where JDK8 has com.sun.javadoc and JDK9+ have
> jdk.javadoc.doclet. This is an internal tool, so it would be wasted effort
> to maintain 2 versions. Either we keep the current code and require JDK8,
> or we migrate to the new API and require JDK.lts or JDK.latest. Those
> requirements only apply to building the javadoc though, i.e. to actually
> cut the releases.
>
> Next, the tests. If we want to be able to test JDK9+ syntax and/or APIs,
> then we either have to require such a JDK (for those tests at least), or
> supersource the code so it can run with JDK8.
> So what are the pros and cons?
>
>- Require a specific JDK:
>   - do we require JDK.lts? or JDK.latest? (currently, JDK.lts would
>   be enough, but as soon as we add newer language syntax and/or APIs, we'd
>   have to use JDK.latest to test those)
>   - do we require it only for those specific tests (aka "use ant
>   filters") or for the whole build? (and using "--release 8" for non-test
>   code to target JDK 8; BTW, can we use "--release 8" at all? not all JDK8
>   APIs are available that way, specifically "internal" APIs)
>   requiring recent JDKs for the whole build means we no longer test
>   with JDK8, and we *have* to migrate the doclets to the new API.
>   Those are rather big cons if you ask me.
>   - Assuming ant filters then:
>  - pro: tests are easy to write/maintain, you only have to follow
>  a naming convention for the test class
>  - con: testing everything requires the JDK.lts/JDK.latest;
>  running the tests with JDK8 only covers JDK8-compatible code. If we 
> keep
>  the doclets on JDK8, this means we have to run the build twice when 
> cutting
>  a release: once with JDK.lts/JDK.latest to make sure the tests pass, 
> and
>  then once with JDK8 to actually build the artifacts.
>  - con: requires setting up the new JDKs, and new jobs, on the CI
>  server. If we keep using the current build.gwtproject.org, this
>  puts the burden on Google; that'd likely precipitate the replacement 
> of the
>  server.
>  - con: requires 2 builds to make sure things still build/run
>  with JDK8
>   - Supersourcing
>   - pro: tests can run with JDK8, so the whole build is
>   JDK8-compatible and still covers all tests
>   - con: requires somehow maintaining the tests twice, keeping the
>   javac'd and supersourced versions in sync (AFAIK, the javac'd version 
> has
>   to have the test methods so they're detected by JUnit, even if their 
> body
>   is empty; so it would be rather easy to add a test to the supersourced
>   version and never actually run it because the method is missing from the
>   javac'd version)
>
> The situation requiring the minimum effort in the short term would be
> keeping the doclets as they are and using supersourcing for the tests.
> In the long run, as JDK9+ tests grow, supersourcing might become
> unsustainable, but the impact on the CI server et al. is non-negligible. We
> could still possibly, at least temporarily, build only with JDK8, and only
> run the JDK9+ tests once in a while (at release time?), manually on a
> developer's machine as a smoke test.
>
> So, my vote would be: "require JDK8 for javadoc, supersource tests", with
> a fallback to an option you didn't list: "Allow any JDK 8+, use ant
> filters, only actually produce javadoc on JDK8 builds", and if/when someone
> wants to put the effort then migrate the doclets and move on to your third
> option: "allow any JDK8+, use ant filters, only actually produce javadoc on
> JDK9+ builds"
>
> On Tuesday, June 30, 2020 at 3:45:36 AM UTC+2, Colin Alworth wrote:
>>
>> As of somewhere in the time leading up to the GWT 2.9.0 release, it is no
>> longer possible to build GWT with Java7, and similarly the decision was
>> made to no longer officially support running on Java7
>> (jsinterop-annotations use of "TYPE_USE", newer jetty version too I
>> believe).
>>
>> There is still some defunct wiring in the build to handle Java 7 vs Java
>> 8 though, mostly with regards to running tests - since we first javac our
>> java classes, and then run gwtc on them, we need to make sure that the java
>> version being use can correctly compile those tests.
>>
>> The issue https://github.com/gwtproject/gwt/issues/9683 is tracking some
>> of the existing work on this: the main remaining piece is to decide how to
>> handle javadoc. GWT has its own custom doclet to handle a few custom tags,
>> "example", "gwt.include", and "tip". None of this compiles after Java 8,
>> since Java 9 came with a new, 

Re: [gwt-contrib] Required JDK version to build GWT?

['Goktug Gokdogan' via GWT Contributors]

wrt running tests:
See https://gwt-review.googlesource.com/c/gwt/+/13861 for the pattern used
in JRE earlier; and the CI was updated to run in both 7 and 8 at the same
time.

PS: Compiler tests ("jjs.test.Java8Test") was different because we really
needed to run the compiler tests with new syntax inside Google which didn't
have the Java8 VM at the time. It wasn't a deal breaker to be not able run
Java8 JRE tests at the time so they are not super sourced.

I recommend the same approach.


On Mon, Jun 29, 2020 at 6:45 PM Colin Alworth  wrote:

> As of somewhere in the time leading up to the GWT 2.9.0 release, it is no
> longer possible to build GWT with Java7, and similarly the decision was
> made to no longer officially support running on Java7
> (jsinterop-annotations use of "TYPE_USE", newer jetty version too I
> believe).
>
> There is still some defunct wiring in the build to handle Java 7 vs Java 8
> though, mostly with regards to running tests - since we first javac our
> java classes, and then run gwtc on them, we need to make sure that the java
> version being use can correctly compile those tests.
>
> The issue https://github.com/gwtproject/gwt/issues/9683 is tracking some
> of the existing work on this: the main remaining piece is to decide how to
> handle javadoc. GWT has its own custom doclet to handle a few custom tags,
> "example", "gwt.include", and "tip". None of this compiles after Java 8,
> since Java 9 came with a new, incompatible API to build custom tags, so
> either we drop Java 8 support for building the toolkit, require _only_ Java
> 8 to build, support two parallel copies of the custom doc wiring, or drop
> the doc wiring entirely and remove these custom tags throughout the
> codebase.
>
> Since the release of GWT 2.9 and my own work on the above ticket, I've
> been picking back up some Java 9/10/11 JRE emulation work that I had
> previously paused, and I'm running into the issue described at the top - if
> you write a test that calls Map.of() and run it on Java8 as a GWTTestCase,
> you'll get a compile error.
>
> Two basic ways I can easily see to fix this: we can make two copies of
> each test, one as an empty "real" java type and one as supersource, or we
> can guard those tests behind java version args in the build glue like we
> did for Java7 vs Java8. The first option is clunky, and while I see this
> was done for `com.google.gwt.dev.jjs.test.Java8Test`, it clearly wasn't
> done for JRE emulation tests, and I assume there was a reason for that. The
> second option requires changing our CI to build+test on some new JRE...
>
> ...and given the constraints of the Java LTS system, and the java 8/9
> divide for custom doclet stuff, it seems like the clearest win is to move
> all the way to Java11, though continue to target java 8 releases, and test
> on all JREs up until current.
>
> So that's my pitch. For completeness, some other options that seem
> workable, keeping in mind that at present there are about 3 important JRE
> versions to support well: Java 8, Java 11, and the current stable release.
>  * Require Java8 for javadoc, supersource tests
>  * Allow any JRE 8+, use ant filters for tests for each version, maintain
> two javadoc builds
>  * Allow any JRE 8+, use ant filters, only actually produce javadoc on
> java9+ builds
>
> Other technical ways to deal with this, or have a missed an easier
> solution to one of these problems?
>
> --
> 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/0aa0701b-4287-4e4c-bbef-23952898c64an%40googlegroups.com
> 
> .
>

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

Re: [gwt-contrib] Re: Unicode support for Character.is* methods

['Goktug Gokdogan' via GWT Contributors]

I don't have access to that patch but if it was correct; I'm sure that it
was very costly though.

A recent attempt looked like following:

  private static class RegExps {/* Formatted strings for the
fallback regular expressions were generated with the following *
Python 3 script.from unicodedata import bidirectional, category
from itertools import *condition = lambda x:
category(chr(x)).startswith("L")  # adjust thisuchr = lambda x:
"u%04X" % x if bidirectional(chr(x)) in ("R", "AN", "AL") else
chr(x)ranges = []codepoints = [x for x in range(0, 0x) if
condition(x)]for _, group in groupby(enumerate(codepoints), lambda
t: t[0] - t[1]):l = list(item for (index, item) in group)
  ranges += [uchr(l[0]) + ("-" if len(l) > 2 else "") + (uchr(l[-1])
if len(l) > 1 else "")]formatted = "\"["for r in
ranges:if len(formatted) + len(r) > 99:
print(formatted + "\"")formatted = "+ \""
  formatted += rprint(formatted + "]\";") */private static
final String LETTER_FALLBACK =
"[A-Za-zªµºÀ-ÖØ-öø-ˁˆ-ˑˠ-ˤˬˮͰ-ʹͶͷͺ-ͽͿΆΈ-ΊΌΎ-ΡΣ-ϵϷ-ҁҊ-ԯԱ-Ֆՙա-և\\u05D0-\\u05EA\\u05F0-\\u05F2"
   + 
"\\u0620-\\u064A\\u066E\\u066F\\u0671-\\u06D3\\u06D5\\u06E5\\u06E6\\u06EE\\u06EF"
   + 
"\\u06FA-\\u06FC\\u06FF\\u0710\\u0712-\\u072F\\u074D-\\u07A5\\u07B1\\u07CA-\\u07EA"
   + 
"\\u07F4\\u07F5\\u07FA\\u0800-\\u0815\\u081A\\u0824\\u0828\\u0840-\\u0858"
   + 
"\\u08A0-\\u08B4\\u08B6-\\u08BDऄ-हऽॐक़-ॡॱ-ঀঅ-ঌএঐও-নপ-রলশ-হঽৎড়ঢ়য়-ৡৰৱਅ-ਊਏਐਓ-ਨਪ-ਰਲਲ਼ਵਸ਼ਸਹ"
   + 
"ਖ਼-ੜਫ਼ੲ-ੴઅ-ઍએ-ઑઓ-નપ-રલળવ-હઽૐૠૡૹଅ-ଌଏଐଓ-ନପ-ରଲଳଵ-ହଽଡ଼ଢ଼ୟ-ୡୱஃஅ-ஊஎ-ஐஒ-கஙசஜஞடணதந-பம-ஹௐఅ-ఌఎ-ఐ"
   + 
"ఒ-నప-హఽౘ-ౚౠౡಀಅ-ಌಎ-ಐಒ-ನಪ-ಳವ-ಹಽೞೠೡೱೲഅ-ഌഎ-ഐഒ-ഺഽൎൔ-ൖൟ-ൡൺ-ൿඅ-ඖක-නඳ-රලව-ෆก-ะาำเ-ๆກຂຄງຈຊຍ"
   + 
"ດ-ທນ-ຟມ-ຣລວສຫອ-ະາຳຽເ-ໄໆໜ-ໟༀཀ-ཇཉ-ཬྈ-ྌက-ဪဿၐ-ၕၚ-ၝၡၥၦၮ-ၰၵ-ႁႎႠ-ჅჇჍა-ჺჼ-ቈቊ-ቍቐ-ቖቘቚ-ቝበ-ኈኊ-ኍ"
   + 
"ነ-ኰኲ-ኵኸ-ኾዀዂ-ዅወ-ዖዘ-ጐጒ-ጕጘ-ፚᎀ-ᎏᎠ-Ᏽᏸ-ᏽᐁ-ᙬᙯ-ᙿᚁ-ᚚᚠ-ᛪᛱ-ᛸᜀ-ᜌᜎ-ᜑᜠ-ᜱᝀ-ᝑᝠ-ᝬᝮ-ᝰក-ឳៗៜᠠ-ᡷᢀ-ᢄᢇ-ᢨᢪ"
   + 
"ᢰ-ᣵᤀ-ᤞᥐ-ᥭᥰ-ᥴᦀ-ᦫᦰ-ᧉᨀ-ᨖᨠ-ᩔᪧᬅ-ᬳᭅ-ᭋᮃ-ᮠᮮᮯᮺ-ᯥᰀ-ᰣᱍ-ᱏᱚ-ᱽᲀ-ᲈᳩ-ᳬᳮ-ᳱᳵᳶᴀ-ᶿḀ-ἕἘ-Ἕἠ-ὅὈ-Ὅὐ-ὗὙὛὝὟ-ώ"
   + 
"ᾀ-ᾴᾶ-ᾼιῂ-ῄῆ-ῌῐ-ΐῖ-Ίῠ-Ῥῲ-ῴῶ-ῼⁱⁿₐ-ₜℂℇℊ-ℓℕℙ-ℝℤΩℨK-ℭℯ-ℹℼ-ℿⅅ-ⅉⅎↃↄⰀ-Ⱞⰰ-ⱞⱠ-ⳤⳫ-ⳮⳲⳳⴀ-ⴥⴧⴭⴰ-ⵧⵯ"
   + 
"ⶀ-ⶖⶠ-ⶦⶨ-ⶮⶰ-ⶶⶸ-ⶾⷀ-ⷆⷈ-ⷎⷐ-ⷖⷘ-ⷞⸯ々〆〱-〵〻〼ぁ-ゖゝ-ゟァ-ヺー-ヿㄅ-ㄭㄱ-ㆎㆠ-ㆺㇰ-ㇿ㐀-䶵一-鿕ꀀ-ꒌꓐ-ꓽꔀ-ꘌꘐ-ꘟꘪꘫꙀ-ꙮ"
   + 
"ꙿ-ꚝꚠ-ꛥꜗ-ꜟꜢ-ꞈꞋ-ꞮꞰ-ꞷꟷ-ꠁꠃ-ꠅꠇ-ꠊꠌ-ꠢꡀ-ꡳꢂ-ꢳꣲ-ꣷꣻꣽꤊ-ꤥꤰ-ꥆꥠ-ꥼꦄ-ꦲꧏꧠ-ꧤꧦ-ꧯꧺ-ꧾꨀ-ꨨꩀ-ꩂꩄ-ꩋꩠ-ꩶꩺꩾ-ꪯꪱꪵꪶ"
   + 
"ꪹ-ꪽꫀꫂꫛ-ꫝꫠ-ꫪꫲ-ꫴꬁ-ꬆꬉ-ꬎꬑ-ꬖꬠ-ꬦꬨ-ꬮꬰ-ꭚꭜ-ꭥꭰ-ꯢ가-힣ힰ-ퟆퟋ-ퟻ豈-舘並-龎ff-stﬓ-ﬗ\\uFB1D\\uFB1F-\\uFB28"
   + 
"\\uFB2A-\\uFB36\\uFB38-\\uFB3C\\uFB3E\\uFB40\\uFB41\\uFB43\\uFB44\\uFB46-\\uFBB1"
   + 
"\\uFBD3-\\uFD3D\\uFD50-\\uFD8F\\uFD92-\\uFDC7\\uFDF0-\\uFDFB\\uFE70-\\uFE74"
   + "\\uFE76-\\uFEFCＡ-Ｚａ-ｚｦ-ﾾￂ-ￇￊ-ￏￒ-ￗￚ-ￜ]";private
static final String DIGIT_FALLBACK =
"[0-9\\u0660-\\u0669۰-۹\\u07C0-\\u07C9०-९০-৯੦-੯૦-૯୦-୯௦-௯౦-౯೦-೯൦-൯෦-෯๐-๙໐-໙༠-༩၀-၉႐-႙០-៩᠐-᠙"
   + "᥆-᥏᧐-᧙᪀-᪉᪐-᪙᭐-᭙᮰-᮹᱀-᱉᱐-᱙꘠-꘩꣐-꣙꤀-꤉꧐-꧙꧰-꧹꩐-꩙꯰-꯹０-９]";
private static final String LOWER_CASE_FALLBACK =
"[a-zµß-öø-ÿāăąćĉċčďđēĕėęěĝğġģĥħĩīĭįıijĵķĸĺļľŀłńņňʼnŋōŏőœŕŗřśŝşšţťŧũūŭůűųŵŷźżž-ƀƃƅƈƌƍƒƕƙ-ƛƞơƣ"
   + 
"ƥƨƪƫƭưƴƶƹƺƽ-ƿdžljnjǎǐǒǔǖǘǚǜǝǟǡǣǥǧǩǫǭǯǰdzǵǹǻǽǿȁȃȅȇȉȋȍȏȑȓȕȗșțȝȟȡȣȥȧȩȫȭȯȱȳ-ȹȼȿɀɂɇɉɋɍɏ-ʓʕ-ʯͱ"
   + 
"ͳͷͻ-ͽΐά-ώϐϑϕ-ϗϙϛϝϟϡϣϥϧϩϫϭϯ-ϳϵϸϻϼа-џѡѣѥѧѩѫѭѯѱѳѵѷѹѻѽѿҁҋҍҏґғҕҗҙқҝҟҡңҥҧҩҫҭүұҳҵҷҹһҽҿӂӄӆӈӊ"
   + 
"ӌӎӏӑӓӕӗәӛӝӟӡӣӥӧөӫӭӯӱӳӵӷӹӻӽӿԁԃԅԇԉԋԍԏԑԓԕԗԙԛԝԟԡԣԥԧԩԫԭԯա-ևᏸ-ᏽᲀ-ᲈᴀ-ᴫᵫ-ᵷᵹ-ᶚḁḃḅḇḉḋḍḏḑḓḕḗḙḛḝ"
   + 
"ḟḡḣḥḧḩḫḭḯḱḳḵḷḹḻḽḿṁṃṅṇṉṋṍṏṑṓṕṗṙṛṝṟṡṣṥṧṩṫṭṯṱṳṵṷṹṻṽṿẁẃẅẇẉẋẍẏẑẓẕ-ẝẟạảấầẩẫậắằẳẵặẹẻẽếềểễệỉ"
   + 
"ịọỏốồổỗộớờởỡợụủứừửữựỳỵỷỹỻỽỿ-ἇἐ-ἕἠ-ἧἰ-ἷὀ-ὅὐ-ὗὠ-ὧὰ-ώᾀ-ᾇᾐ-ᾗᾠ-ᾧᾰ-ᾴᾶᾷιῂ-ῄῆῇῐ-ΐῖῗῠ-ῧῲ-ῴῶῷℊ"
   + 
"ℎℏℓℯℴℹℼℽⅆ-ⅉⅎↄⰰ-ⱞⱡⱥⱦⱨⱪⱬⱱⱳⱴⱶ-ⱻⲁⲃⲅⲇⲉⲋⲍⲏⲑⲓⲕⲗⲙⲛⲝⲟⲡⲣⲥⲧⲩⲫⲭⲯⲱⲳⲵⲷⲹⲻⲽⲿⳁⳃⳅⳇⳉⳋⳍⳏⳑⳓⳕⳗⳙⳛⳝⳟⳡⳣⳤⳬⳮⳳ"
   + 
"ⴀ-ⴥⴧⴭꙁꙃꙅꙇꙉꙋꙍꙏꙑꙓꙕꙗꙙꙛꙝꙟꙡꙣꙥꙧꙩꙫꙭꚁꚃꚅꚇꚉꚋꚍꚏꚑꚓꚕꚗꚙꚛꜣꜥꜧꜩꜫꜭꜯ-ꜱꜳꜵꜷꜹꜻꜽꜿꝁꝃꝅꝇꝉꝋꝍꝏꝑꝓꝕꝗꝙꝛꝝꝟꝡꝣꝥꝧꝩꝫꝭꝯ"
   + "ꝱ-ꝸꝺꝼꝿꞁꞃꞅꞇꞌꞎꞑꞓ-ꞕꞗꞙꞛꞝꞟꞡꞣꞥꞧꞩꞵꞷꟺꬰ-ꭚꭠ-ꭥꭰ-ꮿff-stﬓ-ﬗａ-ｚ]";
private static final String UPPER_CASE_FALLBACK =
"[A-ZÀ-ÖØ-ÞĀĂĄĆĈĊČĎĐĒĔĖĘĚĜĞĠĢĤĦĨĪĬĮİIJĴĶĹĻĽĿŁŃŅŇŊŌŎŐŒŔŖŘŚŜŞŠŢŤŦŨŪŬŮŰŲŴŶŸŹŻŽƁƂƄƆƇƉ-ƋƎ-ƑƓƔƖ-Ƙ"
   + 
"ƜƝƟƠƢƤƦƧƩƬƮƯƱ-ƳƵƷƸƼDŽLJNJǍǏǑǓǕǗǙǛǞǠǢǤǦǨǪǬǮDZǴǶ-ǸǺǼǾȀȂȄȆȈȊȌȎȐȒȔȖȘȚȜȞȠȢȤȦȨȪȬȮȰȲȺȻȽȾɁɃ-ɆɈɊɌ"
   + 
"ɎͰͲͶͿΆΈ-ΊΌΎΏΑ-ΡΣ-ΫϏϒ-ϔϘϚϜϞϠϢϤϦϨϪϬϮϴϷϹϺϽ-ЯѠѢѤѦѨѪѬѮѰѲѴѶѸѺѼѾҀҊҌҎҐҒҔҖҘҚҜҞҠҢҤҦҨҪҬҮҰҲҴҶҸҺҼ"
   + 
"ҾӀӁӃӅӇӉӋӍӐӒӔӖӘӚӜӞӠӢӤӦӨӪӬӮӰӲӴӶӸӺӼӾԀԂԄԆԈԊԌԎԐԒԔԖԘԚԜԞԠԢԤԦԨԪԬԮԱ-ՖႠ-ჅჇჍᎠ-ᏵḀḂḄḆḈḊḌḎḐḒḔḖḘḚḜḞ"
   + 
"ḠḢḤḦḨḪḬḮḰḲḴḶḸḺḼḾṀṂṄṆṈṊṌṎṐṒṔṖṘṚṜṞṠṢṤṦṨṪṬṮṰṲṴṶṸṺṼṾẀẂẄẆẈẊẌẎẐẒẔẞẠẢẤẦẨẪẬẮẰẲẴẶẸẺẼẾỀỂỄỆỈỊỌỎ"
   + 
"ỐỒỔỖỘỚỜỞỠỢỤỦỨỪỬỮỰỲỴỶỸỺỼỾἈ-ἏἘ-ἝἨ-ἯἸ-ἿὈ-ὍὙὛὝὟὨ-ὯᾸ-ΆῈ-ΉῘ-ΊῨ-ῬῸ-Ώℂℇℋ-ℍℐ-ℒℕℙ-ℝℤΩℨK-ℭℰ-ℳℾℿ"
   + 
"ⅅↃⰀ-ⰮⱠⱢ-ⱤⱧⱩⱫⱭ-ⱰⱲⱵⱾ-ⲀⲂⲄⲆⲈⲊⲌⲎⲐⲒⲔⲖⲘⲚⲜⲞⲠⲢⲤⲦⲨⲪⲬⲮⲰⲲⲴⲶⲸⲺⲼⲾⳀⳂⳄⳆⳈⳊⳌⳎⳐⳒⳔⳖⳘⳚⳜⳞⳠⳢⳫⳭⳲꙀꙂꙄꙆꙈꙊꙌꙎꙐꙒꙔꙖ"
   + 
"ꙘꙚꙜꙞꙠꙢꙤꙦꙨꙪꙬꚀꚂꚄꚆꚈꚊꚌꚎꚐꚒꚔꚖꚘꚚꜢꜤꜦꜨꜪꜬꜮꜲꜴꜶꜸꜺꜼꜾꝀꝂꝄꝆꝈꝊꝌꝎꝐꝒꝔꝖꝘꝚꝜꝞꝠꝢꝤꝦꝨꝪꝬꝮꝹꝻꝽꝾꞀꞂꞄꞆꞋꞍꞐꞒꞖꞘꞚꞜꞞꞠꞢꞤꞦ"
   + "ꞨꞪ-ꞮꞰ-ꞴꞶＡ-Ｚ]";private static final String
TITLE_CASE_FALLBACK = "[DžLjNjDzᾈ-ᾏᾘ-ᾟᾨ-ᾯᾼῌῼ]";// The expressions
below were generated by looping over all valid Unicode code points
using the// desktop version of Java.private static final
NativeRegExp WHITESPACE =new NativeRegExp(

Re: [gwt-contrib] GWT number constants generator ?!!

['Goktug Gokdogan' via GWT Contributors]

I'm not familiar with this but looking at the internal tool, it looks like;

zeroDigit data is coming from "commmon/upplemental/numberingSystems.xml".
defCurrencyCode is coming from "common/supplemental/supplementalData.xml".
monetarySeparator is under "numbers/symbols/decimal" locale data.
monetaryGroupingSeparator is under "numbers/symbols/group" locale data.
currency patterns are coming from the currencyFormats section of locale
data.

Logic for simpleCurrencyPattern:

def CreateSimpleCurrencyPattern(ref_pattern):
  """Return simple currency pattern.

  Before this pattern is available in CLDR, created based on general
currency
  pattern by applying this transformation:
  \\00a4+ ==> \\u00a4\\u00a4\\u00a4\\u00a4

  Args:
ref_pattern: pattern to unescape to create the simple pattern
  Returns:
simple currency pattern.
  """
  return re.sub(ur'\u00a4+', ur'\u00a4\u00a4\u00a4\u00a4', ref_pattern, 0)

Logic for globalCurrencyPattern:

def CreateGlobalCurrencyPattern(ref_pattern):
  """Return global currency pattern.

  Before this pattern is available in CLDR, created based on simple currency
  pattern.

  Args:
ref_pattern: pattern to escape to create the global pattern
  Returns:
the global currency pattern
  """
  simple_pattern = CreateSimpleCurrencyPattern(ref_pattern)
  global_pattern = ''
  in_quote = False
  for ch in simple_pattern:
if ch == '\'':
  in_quote = not in_quote
elif ch == ';' and not in_quote:
  global_pattern += ur' \u00a4\u00a4'
global_pattern += ch
  global_pattern += ur' \u00a4\u00a4'
  return global_pattern


On Fri, Jan 3, 2020 at 1:17 PM Ahmad Bawaneh  wrote:

> Dears
>
> I am trying to figure out a way to generate and update GWT number
> constants, looking around i could not find the tool that generates those
> number constants properties files, they are being generated using an
> external tool that is not present in the GWT repo.
>
> Now since i could not find the tool i decided to work on GWT CLDR importer
> tool to add a NumberConstants generator, i was able to read cldr data and
> generated classes for some of the attributes from the original properties
> file, but then i faced a problem where some of those attribute was pretty
> clear where to find in the CLDR data but for some other i was unable to
> find anything to lead me on how they were originally generated
>
> properties i was able to find in the cldr data and generate the proper
> code for
>
> --
> decimalSeparator
> groupingSeparator
> percent
> plusSign
> minusSign
> exponentialSymbol
> perMill
> infinity
> notANumber
> currencyPattern
> decimalPattern
> scientificPattern
> percentPattern
>
> Properties that i cant figure out where to find or how to generate at all
>
> 
> simpleCurrencyPattern
> monetarySeparator
> monetaryGroupingSeparator
> globalCurrencyPattern
> defCurrencyCode
> zeroDigit
>
>
> for some reason i feel like this is related to the same issue with
> TimeZone constants as mentioned in this thread
> https://groups.google.com/forum/#!topic/google-web-toolkit-contributors/VN4ATVrLrTA
>
> I will appreciate any help as this is one of the things that is delaying
> the release of GWT 3.0
>
> the tool that i use to generate CLDR related classes is here
> https://github.com/vegegoku/gwt-cldr-importer which is bases on the GWT
> tools.
>
> thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/f4887884-3de3-42d6-a39b-ea1faefb580c%40googlegroups.com
> 
> .
>

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

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

['Goktug Gokdogan' via GWT Contributors]

Could we proceed with dropping java 7 support? This has been causing rework 
for us to make tests compile with Java7.

On Thursday, May 2, 2019 at 4:47:10 AM UTC-7 (Unknown) wrote:

Fully support both java 8 and Jetty update.


On Thursday, April 25, 2019 at 7:31:36 PM UTC+3, t.b...@gmail.com wrote:
>
> Hi all,
>
> 3½ years ago, we announced 2.8.0-beta1 and that it now required JDK 7, and 
> that started quite a long discussion: 
> https://groups.google.com/d/topic/google-web-toolkit-contributors/TzsINiDf5xg/discussion
> A few days ago, there's been renewed interest into upgrading the Jetty 
> version GWT is using (for reasons I don't support, but that's orthogonal to 
> the point): https://github.com/gwtproject/gwt/issues/9606
> Upgrading Jetty however means requiring JDK 8; and *we have people 
> volunteering to do this work*.
>
> We're in April 2019, Oracle just gave the keys of OpenJDK 11 updates to 
> RedHat, them already being the stewards for OpenJDK 8 and 7.
> JDK 6 is dead and buried (Oracle's extended support ended last December, 
> and it looks like even Azul Systems –the company that, to my knowledge, 
> sells the longest support– no longer provides paid support for OpenJDK 6 
> either)
> OpenJDK 7 will receive free updates for only one more year (June 2020), 
> though some vendors will provide paid support 'til 2022 (e.g. Azul, even 
> providing "passive" support –whatever it means– 'til 2024); for Oracle JDK 
> 7, Oracle's Premier Support will end in July this year (tick tock tick 
> tock), and extended support will last 'til 2022.
> OpenJDK 8 will receive free updates until June 2023 (4 years from now, 
> almost the same time that has passed since 2.8.0-beta1, just sayin')
> For people sharing code with Android, correct me if I'm wrong, but latest 
> tooling improvements (D8 
> ) mean that you can 
> use libraries targeting JDK 8 even on older Android devices (basically, D8 
> integrates retrolambda into the Android toolchain), so *even Android is 
> no longer an excuse.*
>
> *Maybe it's time to switch to JDK 8 as the new baseline for GWT*: by the 
> time we release a 2.9 (who knows when), OpenJDK 7 will only have months to 
> go (tick tock, 14 months from now).
>
> Fwiw, my reasoning for mostly/only caring about free updates to the JDK 
> are:
>
>- AFAICT, GWT receives no money. Some companies (possibly?) dedicate 
>time for maintaining GWT, but it mostly runs on the free time and free 
> will 
>of a few people (I wouldn't even count myself in any longer)
>- Companies that run those older JDK versions likely pay for support. 
>If they have money for that, they can also build their own version of GWT 
>that still supports those older JDK versions (either adapting the most 
>recent GWT version to bring compatibility with older JDKs, or backport 
>fixes to older GWT versions).
>- Companies that run older JDKs without paying for support, besides 
>being crazy (particularly if their servers are exposed on the Internet), 
>can IMO live with older GWT versions too (for JDK 7, in a year from now, 
>that'll still include GWT up to 2.8.2, the current latest release)
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/78753cc2-6823-4da4-81a7-3c100b8d027e%40googlegroups.com.

Re: [gwt-contrib] GWT Java7 support

['Goktug Gokdogan' via GWT Contributors]

Could someone send a patch?

On Tue, Oct 22, 2019 at 4:11 AM Matt Davis  wrote:

> I feel like many more people would enjoy a decent version of embedded
> jetty. Java 7 hasn't had public support in awhile and Oracle premium
> support ended this earlier this.
>
> On Tue, Oct 22, 2019, 1:24 AM Jens  wrote:
>
>> 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
>> .
>>
> --
> 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/CAKAo3tSupuqgijH9sYu%2BN6fo-%2BBpPLuU4kzdpLSJHWUQ-QWC5A%40mail.gmail.com
> 
> .
>

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

[gwt-contrib] GWT Java7 support

['Goktug Gokdogan' via GWT Contributors]

Hi.

I'm wondering if you still need to support Java 7? If not, could you drop
the testing for it from ant? Supporting Java 7 syntax ends up adding extra
work on contributions.

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

Re: [gwt-contrib] Extracting jsinterop-annotations?

['Goktug Gokdogan' via GWT Contributors]

Sorry for the late response. The work of creating the repo is tiny but
wiring everything especially internally is plenty of work. The current
annotations in opensource is also missing J2CL specific ones that we need
to export as well so I don't see much value of you trying to extract a
repository.

Is there a particular reason that you would like to get this one sooner
than later other than generally cleaning things up and reducing deps?


On Fri, Mar 29, 2019 at 7:54 PM Peter Donald  wrote:

> On Sat, Mar 30, 2019 at 6:57 AM 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> Yes, google/jsinterop-annotations was the plan all along however
>> unfortunately most of the work is on our side and we couldn't get back to
>> it.
>>
>
> Is there any value in me trying to extract a repository for this or would
> that cause more work for you?
>
> --
> Cheers,
>
> Peter Donald
>
> --
> 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/CACiKNc761i8unTuxQWB3fsRJ1kGm_Y2oybwygACMYkXsYUg-Pw%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CACiKNc761i8unTuxQWB3fsRJ1kGm_Y2oybwygACMYkXsYUg-Pw%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Extracting jsinterop-annotations?

['Goktug Gokdogan' via GWT Contributors]

Yes, google/jsinterop-annotations was the plan all along however
unfortunately most of the work is on our side and we couldn't get back to
it.

On Thu, Mar 28, 2019 at 9:06 PM Peter Donald  wrote:

> Hi,
>
> The jsinterop annotation jar is shipped as an independent artifact and
> along with jsinterop-base and elemental2 seems to be among the artifacts
> that will be shared between GWT2.x and J2CL. I would like to see it moved
> to a separate top level project and am happy to do the work to make it so.
>
> My feeling is that it is basically maintained by the J2CL team so it seems
> like a good idea to formalise this.  "git log" seems to indicate that most
> of the changes were done by google engineers with the exception of one
> commit by Thomas Broyer.
>
> So I think a reasonable approach would be to basically extract it as
> 'google/jsinterop-annotations' project on github using Bazel modelled after
> jsinterop-base and friends. If that makes people uncomfortable I also went
> and nabbed the "jsinterop" github organization so it could be added as a
> project such as https://github.com/jsinterop/annotations or
> https://github.com/jsinterop/jsinterop-annotations
>
> The jsinterop annotations currently live in
> the user/src/jsinterop/annotations directory within GWT. It would be
> relatively easy to extract the code from their, preserving history of
> changes and put it in a new repository with a new build system.
>
> Thoughts?,
>
> Peter Donald
>
> --
> 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/CACiKNc6ukcq_Bqic%2BpAmoUR6RpJqvAcDPM8YonbO9ZWBc5LGVA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

If somebody could start doing the reviews esp. wrt APIs and +1, I can
review wrt implementation.

On Wed, Jan 30, 2019 at 10:31 AM Colin Alworth  wrote:

> Hey all, anyone want to review some code?
>
> Right around the new year, I finished up a first cut of all of the
> features mentioned so far on https://github.com/gwtproject/gwt/issues/9547,
> including tests. The first patch is at
> https://gwt-review.googlesource.com/c/gwt/+/21501, with a tentative -1
> from me to keep anyone from merging it until we're sure about the
> approaches I took there, and about how to get the build to run on something
> newer than Java 8. The full set of diffs can be seen at
> https://github.com/niloc132/gwt/commits/java9-collections, though in a
> fairly raw state, with the intention of splitting out changes piece by
> piece to land upstream.
>
> Can anyone take a glance at that so we can think about merging it, and
> starting to look at the later patches in that stream? Likewise, has someone
> had the chance to look at Java 9+ support for our ant build?
>
> --
> 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/3446a9bf-d1d7-47bb-ba24-2f13e70be82a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2_9gc1RMpiu1O-PMCh2tGZU7VU2C23wsr%3DuPMD1KRsyA%40mail.gmail.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

['Goktug Gokdogan' via GWT Contributors]

It is not a problem of a single class by itself. It is a problem of policy
and opening the gate for much more. Without a good justification to make an
exception in the policy, we get bombarded with emulation requests (most you
don't even see) that have zero or very little value. Inconsistency doesn't
help with that. Why do we have NoSuchMethodException but not other dozens
of similar classes

used in this library?

So why do we have such policy?
 - There is a consistent cost of transpilation, bundling, optimization etc.
for having an extra classes in emulation. Currently emulation already
reached to 7MBs.
 - Impossible code paths (e.g. catching an exception that will be never
thrown from our emulation) are source of potential bugs.

So we usually ask for a good justification to add such emulation.
In this particular case I don't see generators that mimic reflection as
such a case - it would need a lot more not only this class and it is fine
in such case for them to provide the emulation.
BTW, I only refer to Google code because it is usually a good reference
point from statistical point of view since it includes plenty of common 3rd
party GWT libs; not because it is special.

If this removal becomes an upgrade burden, we can consider putting it back
but I don't see couple of simple cases as a real upgrade issue. This
particular library could either add it, like it is already doing other
relevant classes or just change the internal API. We should wait and if
there are more concerns.

On Thu, Jan 3, 2019 at 11:36 PM Jens  wrote:

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

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0baf0UCX4rDntvGJ3%3D6Lw_YA35CEJyPt3rKyRnyiFD_w%40mail.gmail.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

['Goktug Gokdogan' via GWT Contributors]

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
I think IDE warnings in couple of corner cases is just a minor
inconvenience for the end user.

On Thu, Jan 3, 2019 at 6:35 AM Jens  wrote:

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

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

[gwt-contrib] Fwd: Happy to announce general access for J2CL!

['Goktug Gokdogan' via GWT Contributors]

-- Forwarded message -
From: Goktug Gokdogan 
Date: Tue, Nov 13, 2018 at 5:38 PM
Subject: Happy to announce general access for J2CL!
To: 


Dear GWTers!

We are happy to announce that we have opened up J2CL repository for general
access:
http://github.com/google/j2cl

Please see the README for details and instructions.

I also would like to use this opportunity to thank all Googlers who
contributed over the years and made this happen.

Enjoy!

Goktug, on behalf of J2CL team

PS: If you are using Windows, you might have a bumpy road but should get
better over time with your feedback and contributions.

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

Re: [gwt-contrib] Update on J2CL

['Goktug Gokdogan' via GWT Contributors]

2-3 weeks unless we hit a major issue.

On Wed, Oct 24, 2018 at 6:44 AM Konstantin Solomatov <
konstantin.soloma...@gmail.com> wrote:

> Do you have any info on how soon it will happen? I.e. days, weeks?
>
> Thanks,
> Kostya
>
> On Wednesday, October 24, 2018 at 1:02:45 AM UTC-4, Julien Dramaix wrote:
>>
>> Note that J2CL works for a while now inside Google and is used by several
>> big applications. But it was using several internal tools and api that
>> prevent us to opensource it.
>> We are close to finish the clean up and as Goktug mentioned in his
>> previous email, you should get an announcement soon if our internal
>> priorities don't change.
>>
>> On Tue, Oct 23, 2018 at 7:30 PM 'Goktug Gokdogan' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>
>>> We got it mostly working. Hopefully you should get an announcement soon.
>>>
>>> On Tue, Oct 23, 2018 at 10:06 AM Konstantin Solomatov <
>>> konstantin...@gmail.com> wrote:
>>>
>>>> Are there any updates on J2CL? A lot of time has passed.
>>>>
>>>> On Friday, June 15, 2018 at 3:54:08 AM UTC-4, Julien Dramaix wrote:
>>>>>
>>>>> > 2. J2CL itself is build with Bazel (for the reasons you mentioned).
>>>>> This would not matter much, *as long as you could push the J2CL
>>>>> artifacts to Maven Central in an automated (Bazel) pipeline*. *Can
>>>>> Bazel do that*?
>>>>>
>>>>> Yes it can. We are already building jsinterop-base and Elemental2 with
>>>>> Bazel and push artifact on Maven Central.
>>>>>
>>>>> -Julien
>>>>>
>>>>> On Thu, Jun 14, 2018 at 3:50 PM Hristo Stoyanov 
>>>>> wrote:
>>>>>
>>>>>> Guys,
>>>>>> Thanks for the update to J2CL! Here is what I understood, the
>>>>>> questions I have - correct me, if I am wrong:
>>>>>>
>>>>>> 1. Google is seeing good results from J2CL in a number of products,
>>>>>> so your internal funding won't be cut, J2CL won't be abandoned! That is
>>>>>> good news!
>>>>>>
>>>>>> 2. J2CL itself is build with Bazel (for the reasons you mentioned).
>>>>>> This would not matter much, *as long as you could push the J2CL
>>>>>> artifacts to Maven Central in an automated (Bazel) pipeline*. *Can
>>>>>> Bazel do that*?
>>>>>>
>>>>>> 3. Some GWT folks are developing Gradle and Maven plug-ins. *What is
>>>>>> the status of those*? I think this is the most important thing -
>>>>>> once the J2CL jars are in Maven central and the plug-ins ready, people 
>>>>>> can
>>>>>> start building apps with J2CL?
>>>>>>
>>>>>> 4. This comment from Goktug: ..."*we use some tools that does code
>>>>>> pruning during build which helps some with the performance, and those 
>>>>>> tools
>>>>>> are not available for open source. Something we will eventually look at 
>>>>>> but
>>>>>> not very soon" worries me. Is J2CL a 100% Java or you use other stuff 
>>>>>> that
>>>>>> can not be released?*
>>>>>>
>>>>>>
>>>>>> *5. I still don't quite understand why not dump everything J2CL on
>>>>>> Gihub "AS IS" and let us sort it out?*
>>>>>>
>>>>>>
>>>>>> *Also, It would be helpful if some of the developers who already
>>>>>> received the J2CL code drop comment and clarify what needs to be finished
>>>>>> from their point of view.*
>>>>>>
>>>>>>
>>>>>> *As far as GWT3, I don't understand what is the value of it at all,
>>>>>> maybe valuable time/resources can be spent on J2CL instead, once it is
>>>>>> placed on Github*
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Thanks. *
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "GWT Contributors" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to
>>>>>> 

Re: [gwt-contrib] Update on J2CL

['Goktug Gokdogan' via GWT Contributors]

We got it mostly working. Hopefully you should get an announcement soon.

On Tue, Oct 23, 2018 at 10:06 AM Konstantin Solomatov <
konstantin.soloma...@gmail.com> wrote:

> Are there any updates on J2CL? A lot of time has passed.
>
> On Friday, June 15, 2018 at 3:54:08 AM UTC-4, Julien Dramaix wrote:
>>
>> > 2. J2CL itself is build with Bazel (for the reasons you mentioned).
>> This would not matter much, *as long as you could push the J2CL
>> artifacts to Maven Central in an automated (Bazel) pipeline*. *Can Bazel
>> do that*?
>>
>> Yes it can. We are already building jsinterop-base and Elemental2 with
>> Bazel and push artifact on Maven Central.
>>
>> -Julien
>>
>> On Thu, Jun 14, 2018 at 3:50 PM Hristo Stoyanov 
>> wrote:
>>
>>> Guys,
>>> Thanks for the update to J2CL! Here is what I understood, the questions
>>> I have - correct me, if I am wrong:
>>>
>>> 1. Google is seeing good results from J2CL in a number of products, so
>>> your internal funding won't be cut, J2CL won't be abandoned! That is good
>>> news!
>>>
>>> 2. J2CL itself is build with Bazel (for the reasons you mentioned). This
>>> would not matter much, *as long as you could push the J2CL artifacts to
>>> Maven Central in an automated (Bazel) pipeline*. *Can Bazel do that*?
>>>
>>> 3. Some GWT folks are developing Gradle and Maven plug-ins. *What is
>>> the status of those*? I think this is the most important thing - once
>>> the J2CL jars are in Maven central and the plug-ins ready, people can start
>>> building apps with J2CL?
>>>
>>> 4. This comment from Goktug: ..."*we use some tools that does code
>>> pruning during build which helps some with the performance, and those tools
>>> are not available for open source. Something we will eventually look at but
>>> not very soon" worries me. Is J2CL a 100% Java or you use other stuff that
>>> can not be released?*
>>>
>>>
>>> *5. I still don't quite understand why not dump everything J2CL on Gihub
>>> "AS IS" and let us sort it out?*
>>>
>>>
>>> *Also, It would be helpful if some of the developers who already
>>> received the J2CL code drop comment and clarify what needs to be finished
>>> from their point of view.*
>>>
>>>
>>> *As far as GWT3, I don't understand what is the value of it at all,
>>> maybe valuable time/resources can be spent on J2CL instead, once it is
>>> placed on Github*
>>>
>>>
>>>
>>> *Thanks. *
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/807613cc-5945-49c1-8f5e-205dd53f5dea%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d4af467b-ae98-4ab6-a665-d465c5145527%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: "GWT RPC" and its role in the future of GWT

['Goktug Gokdogan' via GWT Contributors]

I understand GWT-RPC would be interesting at least for some people but that
still doesn't make it a trustworthy, decent RPC system and has fundamental
flaws which we have enumerated couple of times already.
I see it could be potentially replaced with something more sane and useable
but like some others have already suggested it seems like the replacement
is better to evolve and mature independently and later evaluated to see if
it is part of compatibility lib or something we can recommend for future
development.

On Thu, Oct 18, 2018 at 4:16 AM Learner Evermore 
wrote:

> I strongly disagree that this should be just a compatibility library.
> Thomas, will all due respect, if you don't find it useful for your work it
> does not mean others don't and REST APIs are seeing their own sunset as
> well and JavaScript approaches come nowhere near where they need to be to
> cover the points I listed. Even if I could expose APIs of any other kind
> (REST, GraphQL, JavaScript/JSON or not) the "GWT RPC (NG)" still has a
> great place, perhaps parallel (in addition to them) for all the reasons
> listed. RPC was what completed the GWT value proposition - without it it
> isn't much better (if at all better or even close to) than a number of
> other solutions out there and doesn't fulfill its own promise. Instead of
> performant abstraction we'd have a thin translator requiring the developers
> to continue to know and think about both Java and JavaScript world of
> things.
>
> JavaScript is an *awful* language and system in any of its incarnation for
> anything complex. Arguments that it is the best because of performance,
> size and library availability are the same as those used for assembly and
> Fortran a while back and are pointless, especially due to the prospect of
> WebAssembly. In my opinion, GWT should completely abstract that platform
> and be able to, eventually, leverage whatever is the best for it without
> impacting the apps built using it. As such, abstracting JS away as much as
> possible is a benefit just like it is using the paradigms of the core
> language of GWT - Java.
>
> Learner Evermore
>
>
>   Original Message
> From: t.bro...@gmail.com
> Sent: October 18, 2018 3:17 AM
> To: google-web-toolkit-contributors@googlegroups.com
> Reply to: google-web-toolkit-contributors@googlegroups.com
> Subject: [gwt-contrib] Re: "GWT RPC" and its role in the future of GWT
>
> Everyone knows I don't like GWT-RPC (specifically related to some of the
> points "Learner" listed), but I cannot deny that it's been a big selling
> point of GWT over the years.
> For that reason alone, I won't oppose to it being in the org.gwtproject
> namespace. So let's do that (but IMO make it more a "compatibility lib" for
> those coming from GWT 2, replacing its use in tutorials and samples with
> something else -- RESTish JSON APIs are easy nowadays with JsInterop, so
> probably use that instead, as that makes it easier to understand that GWT
> could be used with any backend)
>
> --
> 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/7785d7c8-4f2e-4d95-9ea9-b287c0b65544%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/2shv5gsgoe900hgcebeo5p86.1539861391103%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Union types hack

['Goktug Gokdogan' via GWT Contributors]

We have considered generics based unions but the current union
implementation in Elemental2 is much more practical for the Elemental API
needs since most of the time the consumption of the union is not based on a
shared abstraction but based on specific type guarded with type check. Here
is the Julien's pro/con summary from the design doc:

Advantage of generics based union:
  - Can be shared across different compilation unit.

Disadvantage:
  - The number of types involved in an union type is potentially infinite.
We will need several interfaces for covering the majority of use case of
union type.
  - need specific treatment by J2CL to emit the correct closure annotation
  - not really user friendly because we cannot implement isXyz test methods

Technically we can also add a helper to our union that takes a consumer
function similar to the article. That will give you the same benefit (i.e.
perform operations on the union based on the intersection in a type-safe
way). However I think that's rarely useful in Elemental case. If you think
it will be helpful, feel free to open feature request in elemental2 github
issue tracker with examples of the APIs that will benefit from this.

On Wed, Sep 12, 2018 at 2:20 PM Hristo Stoyanov 
wrote:

> I wonder if the hack described below can be applied to Elemental2 union
> types:
>
>
> https://blog.jooq.org/2016/02/16/an-ingenious-workaround-to-emulate-sum-types-in-java/
>
> --
> 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/fe6e7cc4-16fe-4975-8087-fc07ba1bc5a8%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Update on J2CL

['Goktug Gokdogan' via GWT Contributors]

I think you are overly underestimating Bazel but that is a side discussion
that I don't want to go into right now.

We already use Bazel and cannot use anything else internally so that's
already the starting point. Question is;
Should we have invested on completely different stack on Gradle (or put X
here) that we have no experience with where JavaScript and JsCompiler
plugins either exist and not properly supported or doesn't exist needs to
be built; and try to maintain that parallel solution just for the
open-source
or
make what we have on Bazel work in open-source with our limited bandwidth
towards something that we could give proper support for.

I assure you, you wouldn't get quicker access with the first option. We
decided to go with second one and gave early access to a trusted group of
users so they could start working on alternative build solutions and GWT3.
We believe this was a good middle ground.


On Tue, Jun 12, 2018 at 12:10 AM David Nouls  wrote:

> Thanks for the update,
>
> I fail to understand why the prerequisite of using bazel was enforced and
> why it seems to have such a big impact on opensourcing J2CL.
> As far as I understand Google is probably the only company that uses
> bazel, and internally that is not even the same product as the opensource
> one.
>
> Does J2CL depend on Bazel somehow ? That sounds like a liability to me.
> Newer versions of Gradle have a lot of optimisations and caching
> implemented, so was it really worth the effort to use Bazel ?
> On 12 Jun 2018, 08:54 +0200, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com>, wrote:
>
> *We recently sent an update on J2CL and we would like to cross post it to
> GWT contributor list since there was recent questions about it. I would
> like to also remind everybody that GWT3 != J2CL; GWT3 work is still ongoing
> in the open source community and I will talk to steering committee to see
> if an update on it could be provided as well.*
> 
>
> *Since we gave access to more people, we thought that this would be a good
> time to give you an update on J2CL; what is happening, if it is really a
> thing or not and what to expect from it.*
>
> *First the good parts:*
>
> *1- J2CL is feature complete for a while and had a very strong traction in
> Google in the last year.*
>
> *We got pretty big customers on board and some launched to production and
> they are pretty happy about it.  To name a few projects that are already
> running J2CL code: New GMail, Inbox, Docs, Slides. And more are coming.*
>
> *We could not have achieved this with GWT since our customers apps have
> very strict expectations on code size/performance and interoperation with
> their existing JavaScript stack. And this is why we built J2CL in the first
> place.*
>
> *2- J2CL has improved on code size compared to already quite performant
> GWT compiler.*
>
> *The last time I checked it was around 5-10% code size reduction and we
> will continue working on that.*
>
> *3- Optimized compiles improved by 50% and it is possible to get a couple
> of second refresh times for development.*
>
>
> *And now the “could be better” parts :)*
>
> *1- Open-source build is not fully working*
>
> *J2CL is highly optimized for Google infrastructure and scales very well
> with Bazel. There are multiple reasons for that:*
>
> *- Bazel works very well as a cross-platform build solution. You can build
> your Android, iOS and Web application together with Bazel.*
>
> *- Bazel has a very good caching/scaling architecture and we already
> designed J2CL based on that.*
>
> *- Bazel is our only expertise on build systems so we can only ensure
> developers gets a good development experience using Bazel.*
>
> *For pure J2CL experience in open source, we decided early on to rely on
> Bazel and made it a prerequisite for open-sourcing it.*
>
> *However, our internal build macros used things that are only available
> internally so we need to clean and port to a more proper solution that
> could also work well for open-source. And during that process we keep
> hitting limitations that block us and cause delays. Also please keep in
> mind that J2CL’s success is highly related to its internal success and we
> were busy helping internal customers to have successful production launches
> so we didn't have much bandwidth either.*
>
> *On the bright side, most of the blocking issues are getting resolved and
> we had progress in the last couple of months and we are prioritizing this
> even further.*
>
> *(Note that this doesn’t mean you will be *required* to use Bazel for J2CL
> and our contributors are already working on Maven/Gradle solutions.)*
>
> *2- For now your mileage may vary w.r.t performance*

[gwt-contrib] Update on J2CL

['Goktug Gokdogan' via GWT Contributors]

*We recently sent an update on J2CL and we would like to cross post it to
GWT contributor list since there was recent questions about it. I would
like to also remind everybody that GWT3 != J2CL; GWT3 work is still ongoing
in the open source community and I will talk to steering committee to see
if an update on it could be provided as well.*















*Since we gave access to more people, we thought that this would be a good
time to give you an update on J2CL; what is happening, if it is really a
thing or not and what to expect from it.First the good parts:1- J2CL is
feature complete for a while and had a very strong traction in Google in
the last year.We got pretty big customers on board and some launched to
production and they are pretty happy about it.  To name a few projects that
are already running J2CL code: New GMail, Inbox, Docs, Slides. And more are
coming.We could not have achieved this with GWT since our customers apps
have very strict expectations on code size/performance and interoperation
with their existing JavaScript stack. And this is why we built J2CL in the
first place.2- J2CL has improved on code size compared to already quite
performant GWT compiler.The last time I checked it was around 5-10% code
size reduction and we will continue working on that.3- Optimized compiles
improved by 50% and it is possible to get a couple of second refresh times
for development.And now the “could be better” parts :)1- Open-source build
is not fully workingJ2CL is highly optimized for Google infrastructure and
scales very well with Bazel. There are multiple reasons for that: - Bazel
works very well as a cross-platform build solution. You can build your
Android, iOS and Web application together with Bazel. - Bazel has a very
good caching/scaling architecture and we already designed J2CL based on
that. - Bazel is our only expertise on build systems so we can only ensure
developers gets a good development experience using Bazel.For pure J2CL
experience in open source, we decided early on to rely on Bazel and made it
a prerequisite for open-sourcing it.However, our internal build macros used
things that are only available internally so we need to clean and port to a
more proper solution that could also work well for open-source. And during
that process we keep hitting limitations that block us and cause delays.
Also please keep in mind that J2CL’s success is highly related to its
internal success and we were busy helping internal customers to have
successful production launches so we didn't have much bandwidth either.On
the bright side, most of the blocking issues are getting resolved and we
had progress in the last couple of months and we are prioritizing this even
further.(Note that this doesn’t mean you will be *required* to use Bazel
for J2CL and our contributors are already working on Maven/Gradle
solutions.)2- For now your mileage may vary w.r.t performanceEven though
optimized compiles are much better for Google, I am not sure how this will
translate to open- source  since the two compilers scale differently and
historically open source users got better performance out of GWT than we
did internally. However I'm optimistic on this in the long run.For
development edit/refresh cycles, it is hard to beat GWT’s SDM since it is
already designed to do the very minimal things required to serve
development code. Being said that it is still possible to have good refresh
times using something called 'iblaze' which is essentially a file watcher
that triggers a warm transpiler and code bundler where we could do
caching.One worry I have here is, we use some tools that does code pruning
during build which helps some with the performance, and those tools are not
available for open source. Something we will eventually look at but not
very soon.Anyway, this is the quick summary of how things are and I hope it
sheds some light to the questions.*

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

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

['Goktug Gokdogan' via GWT Contributors]

J2CL is yet-to-be open-sourced Google product, I'll post a separate update
on the state but that's why it wasn't developed openly.

GWT, which is community owned; there is nothing done in secrecy and people
in the community actively working on GWT 3.

On Sun, Jun 10, 2018 at 3:58 AM Norbert Sándor 
wrote:

> > it would be nice to have J2CL released separately as soon as it is ready
>
> I still don't get why the development of J2CL / GWT 3 cannot be done
> openly like any other open source project.
> Why this secrecy is necessary.
>
> This kind of project management type is very unusual in case of open
> source projects
> It will make many people to stay away from the project and to switch to
> (even worse) alternatives :(
>
> --
> Norbi
>
> On Saturday, 9 June 2018 22:47:48 UTC+2, Ming-Yee Iu wrote:
>>
>> Wow! It's great to see all that progress being made on GWT 3. That's a
>> lot more backwards compatibility than I was expecting.
>>
>> Still, it would be nice to have J2CL released separately as soon as it is
>> ready to do so because
>>
>>1. Based on past experience, it will take 1-2 years or more before
>>GWT 3 is released
>>2. J2CL is useful independent of GWT 3. Just recently, I wanted to
>>package up some Java code as node.js NPM packages for others to use, but
>>doing that really requires something like J2CL instead of GWT
>>3. It's good to have some time for people to develop best practices
>>for how J2CL code can be mixed with JS. Google's JS code style is very
>>clean, well-typed, and Java-like, so it will naturally work well with 
>> J2CL.
>>Much real-world JS code is ugly and makes use of horrible JS corner cases
>>and hacks, so it might take a while to figure out best practices for how 
>> to
>>deal with those.
>>
>> --
> 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/9516f69a-62cc-4eb9-86e6-aaeec3a09366%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

Please send your member requests with some background information on why
you need early access.

On Fri, Jun 1, 2018 at 3:08 PM Julien Dramaix 
wrote:

> I changed the permission settings. You should now be able to apply for
> membership at https://groups.google.com/forum/#!forum/j2cl-external
>
> -Julien
>
> On Fri, Jun 1, 2018 at 1:50 PM Alberto Mancini 
> wrote:
>
>> Hello Goktug,
>> thanks a lot for the opportunity.
>> Actually seems that the address j2cl-exter...@googlegroups.com does not
>> exist.
>>  mailer-dae...@google.com 
>> We're writing to let you know that the group you tried to contact
>> (j2cl-external) may not exist, or you may not have permission to post
>> messages to the group. A few more details on why you weren't able to post:
>>
>>  * You might have spelled or formatted the group name incorrectly.
>>  * The owner of the group may have removed this group.
>>  * You may need to join the group before receiving permission to post.
>>  * This group may not be open to posting.
>> - -
>>
>> It is just me, I'm not autrorized or actually the address is spelled
>> incorrectly?
>>
>> Thanks,
>>Alberto.
>>
>>
>> On Thu, May 31, 2018 at 11:51 PM 'Goktug Gokdogan' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>
>>> Hi all.
>>>
>>> Sorry for the delays in getting J2CL work for opensource. Some of the
>>> delays were out of our control but this is something we actively working on
>>> in the last few months and having progress. In the meantime plenty of
>>> active GWT contributors already has access to it for a long time and
>>> working on getting GWT 3 ready. Also a while back, I said "if there are
>>> more people who needs access to J2CL for GWT 3 porting, we can give them
>>> access" but it is not usable for average developer.
>>>
>>> If you think you need earlier access to J2CL in as-is state (which
>>> partially builds with plenty of workarounds), pls send a message to
>>> j2cl-exter...@googlegroups.com; and pls make your case (e.g. porting X
>>> from GWT 2 SDK to GWT 3) and we will give access. However we cannot help
>>> you a lot at the moment when you hit problems (you will) so pls set your
>>> expectations accordingly.
>>>
>>>
>>> On Thu, May 31, 2018 at 6:02 AM Ivan Markov 
>>> wrote:
>>>
>>>> Don't you think there could've been 2x or even 3x as much people
>>>> working on porting GWT2 stuff over to J2CL if J2CL was released in the
>>>> first place? For one, releasing J2CL could've made me reconsider how much
>>>> time I invest in my own SDBG pet project. Which - at the current situation
>>>> is exactly zero. Or whether to invest time in the abandoned typescript2java
>>>> effort, which would bring seamless JSInterop with gazillions of .d.ts'd JS
>>>> libraries without the need to manually code JSInterop bindings...
>>>>
>>>> Say what you want, but 3 months since my original rant that at the top
>>>> of this thread, the "basic Bazel building issues" of Goktug seem still to
>>>> be a roadblock and J2CL is still nowhere to be seen.
>>>>
>>>> ... and then we had Daniel planning to write a book on J2CL end of
>>>> 2016, remember? Come on guys, it is Q3 2018 now... I might now agree with
>>>> Learner Evermore on his points 2) to 5), but with point 1) he nailed it:
>>>> "1. The backing company backed off but kept the crucial new piece
>>>> secret - J2CL."
>>>>
>>>>
>>>> On Wednesday, May 30, 2018 at 6:07:25 PM UTC+3, Frank Hossfeld wrote:
>>>>>
>>>>> That's not really true. There are a lot of people working on the GWT
>>>>> module, getting them out of GWT and moving them to standalone artifacts.
>>>>> Doing that, they replace JSNI with JsInterop, replace generators, etc. 
>>>>> This
>>>>> is all done, to get GWT 2 ready for GWT 3. And if you want to see 
>>>>> something
>>>>> existing in GWT 3, you can ask vertispan to do the job.
>>>>>
>>>>> With the knowledge about the things, that will change with GWT 3 /
>>>>> J2CL, I was able to make mvp4g ready for GWT 3 / J2CL. I replaced the
>>>>> generator with APT and remove the dependency to any GWT classes. I created
>>>>> a sample application based on the new version (

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

['Goktug Gokdogan' via GWT Contributors]

Hi all.

Sorry for the delays in getting J2CL work for opensource. Some of the
delays were out of our control but this is something we actively working on
in the last few months and having progress. In the meantime plenty of
active GWT contributors already has access to it for a long time and
working on getting GWT 3 ready. Also a while back, I said "if there are
more people who needs access to J2CL for GWT 3 porting, we can give them
access" but it is not usable for average developer.

If you think you need earlier access to J2CL in as-is state (which
partially builds with plenty of workarounds), pls send a message to
j2cl-exter...@googlegroups.com; and pls make your case (e.g. porting X from
GWT 2 SDK to GWT 3) and we will give access. However we cannot help you a
lot at the moment when you hit problems (you will) so pls set your
expectations accordingly.


On Thu, May 31, 2018 at 6:02 AM Ivan Markov  wrote:

> Don't you think there could've been 2x or even 3x as much people working
> on porting GWT2 stuff over to J2CL if J2CL was released in the first place?
> For one, releasing J2CL could've made me reconsider how much time I invest
> in my own SDBG pet project. Which - at the current situation is exactly
> zero. Or whether to invest time in the abandoned typescript2java effort,
> which would bring seamless JSInterop with gazillions of .d.ts'd JS
> libraries without the need to manually code JSInterop bindings...
>
> Say what you want, but 3 months since my original rant that at the top of
> this thread, the "basic Bazel building issues" of Goktug seem still to be a
> roadblock and J2CL is still nowhere to be seen.
>
> ... and then we had Daniel planning to write a book on J2CL end of 2016,
> remember? Come on guys, it is Q3 2018 now... I might now agree with Learner
> Evermore on his points 2) to 5), but with point 1) he nailed it:
> "1. The backing company backed off but kept the crucial new piece secret -
> J2CL."
>
>
> On Wednesday, May 30, 2018 at 6:07:25 PM UTC+3, Frank Hossfeld wrote:
>>
>> That's not really true. There are a lot of people working on the GWT
>> module, getting them out of GWT and moving them to standalone artifacts.
>> Doing that, they replace JSNI with JsInterop, replace generators, etc. This
>> is all done, to get GWT 2 ready for GWT 3. And if you want to see something
>> existing in GWT 3, you can ask vertispan to do the job.
>>
>> With the knowledge about the things, that will change with GWT 3 / J2CL,
>> I was able to make mvp4g ready for GWT 3 / J2CL. I replaced the generator
>> with APT and remove the dependency to any GWT classes. I created a sample
>> application based on the new version (mvp4g2) and Elemental 2. And yes, it
>> works with J2CL.
>>
>> And, keep in mind, applications written in GWT in 2010 still work. What
>> was the favorite JS framework at that time? I don't remember.
>>
> --
> 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/03d79d23-11e5-423b-9009-d439a569c512%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] The elusive J2CL

['Goktug Gokdogan' via GWT Contributors]

A basic functionality missing in open-source build doesn't mean it is far
away. We were trying to get it ready by this quarter but it didn't work out
as I explained earlier.
For 'pure' J2CL experience, we have chosen bazel. Bazel works/scales pretty
well and same as our internal setup which makes it much easier to maintain
as well. Keep in mind J2CL != GWT 3. A bunch of contributors are already
working on GWT/Maven/Gradle support on top of that so you are not be forced
to use bazel.

On Fri, Mar 9, 2018 at 12:06 PM Slava Pankov  wrote:

> Yes, I agree "even basic missing functionalities" sounds scary. And why
> bazel? It's not even close in popularity with Maven and Gradle.
>
> On Friday, March 9, 2018 at 1:52:34 AM UTC-8, Ivan Markov wrote:
>>
>> Goktug, sorry for being a but stubborn here, but we need a tad more
>> visibility:
>>
>> {quote}
>> The main blocker for releasing J2CL for wider audience is even basic
>> missing functionalities around building it in open-source and seeing at
>> least some output for your compilations.
>> {quote}
>>
>> "even basic missing functionalities" sounds quite worrysome. What is the
>> ETA for implementing these and releasing a preview? If e.g. two months,
>> fine. If we are talking Q4/2018 or 2019, then that's a different
>> proposition altogether. I guess, not just for us. Please don't answer with
>> the "it's done when it is done" slogan. :) That's one of the major pains
>> for this community imo.
>>
>> Final Q: are all the legal issues for releasing in the open resolved by
>> now? From personal experience, these might take forever to resolve.
>>
>> On Thursday, March 8, 2018 at 10:51:21 PM UTC+2, Goktug Gokdogan wrote:
>>>
>>> > There is still tone of work to do for a polished open source
>>> experience but at least we can give access to more people who is really
>>> interested.
>>>
>>> What I meant here; is giving access *after* basic bazel stuff is
>>> finished so there will be something to play with. We don't want to give
>>> access to a broader group for something that is dead on arrival.
>>>
>>>
>>> On Thu, Mar 8, 2018 at 5:31 AM Alberto Mancini 
>>> wrote:
>>>
 Hello,
 yes, definitely I would like to be in.
 I am really interested.

 Cheers,
Alberto.


 On Thu, Mar 8, 2018 at 2:21 PM Nándor Előd Fekete 
 wrote:

> I am *really* interested. Can you sign me up?
>
>
> On Thursday, March 8, 2018 at 9:13:01 AM UTC+1, Goktug Gokdogan wrote:
>>
>> The main blocker for releasing J2CL for wider audience is even basic
>> missing functionalities around building it in open-source and seeing at
>> least some output for your compilations. That is blocked on missing
>> functionalities in bazel. After that we can probably finished in more
>> timely manner.
>> There is still tone of work to do for a polished open source
>> experience but at least we can give access to more people who is really
>> interested.
>>
> --
> 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/8de62b64-4bc8-4158-80d4-b15ef688f523%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
 --
 You received this message because you are subscribed to the Google
 Groups "GWT Contributors" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGv30V%3DfWDpwQ45u9mPVuXY%3D62PJZ%2B9uxearZk5Lq_a0j2yjaA%40mail.gmail.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/5e3a16fb-2eda-40b0-a59a-6525b87a17d6%40googlegroups.com
> 

Re: [gwt-contrib] The elusive J2CL

['Goktug Gokdogan' via GWT Contributors]

> There is still tone of work to do for a polished open source experience
but at least we can give access to more people who is really interested.

What I meant here; is giving access *after* basic bazel stuff is finished
so there will be something to play with. We don't want to give access to a
broader group for something that is dead on arrival.


On Thu, Mar 8, 2018 at 5:31 AM Alberto Mancini  wrote:

> Hello,
> yes, definitely I would like to be in.
> I am really interested.
>
> Cheers,
>Alberto.
>
>
> On Thu, Mar 8, 2018 at 2:21 PM Nándor Előd Fekete 
> wrote:
>
>> I am *really* interested. Can you sign me up?
>>
>>
>> On Thursday, March 8, 2018 at 9:13:01 AM UTC+1, Goktug Gokdogan wrote:
>>>
>>> The main blocker for releasing J2CL for wider audience is even basic
>>> missing functionalities around building it in open-source and seeing at
>>> least some output for your compilations. That is blocked on missing
>>> functionalities in bazel. After that we can probably finished in more
>>> timely manner.
>>> There is still tone of work to do for a polished open source experience
>>> but at least we can give access to more people who is really interested.
>>>
>> --
>> 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/8de62b64-4bc8-4158-80d4-b15ef688f523%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGv30V%3DfWDpwQ45u9mPVuXY%3D62PJZ%2B9uxearZk5Lq_a0j2yjaA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] The elusive J2CL

['Goktug Gokdogan' via GWT Contributors]

The main blocker for releasing J2CL for wider audience is even basic
missing functionalities around building it in open-source and seeing at
least some output for your compilations. That is blocked on missing
functionalities in bazel. After that we can probably finished in more
timely manner.
There is still tone of work to do for a polished open source experience but
at least we can give access to more people who is really interested.



On Wed, Mar 7, 2018 at 11:43 PM Ivan Markov  wrote:

> I posted my message (OK. My rant!) here, because I wanted to get the
> attention of Goktug, Daniel & the rest of  the Google crew. It is a plea to
> change something ASAP, and if someone could, it is them.
>
> As for the rest of your comments... don't know where to start. Most
> important is, you seem to imply that using J2CL will resurrect something
> similar to the old legacy development mode. That couldn't be farther from
> the truth - I suggest you check the available (scarce) info on J2CL. Also:
> with the new compiler toolchain we (should) have even faster compiles. "We
> should" because it is not available anywhere, so we can't play with it. We
> are currently in the 5 to 10 seconds of recompile time with GWT, and I want
> this down to 2 seconds. I want Webpack all the way down, also for my Java
> code. With HMR. With HMR + react-hot-loader. Maybe that's possible with the
> GWT toolchain, but I'm not holding my breath...
>
> On Thursday, March 8, 2018 at 6:17:28 AM UTC+2, Tony BenBrahim wrote:
>>
>> I am perfectly happy with Java/JsInterop in its current state. Sure there
>> are some things that could be improved, but what couldn't. BTW, I have
>> never used the GWT widgets, so my case may be different. I tried TS,
>> Angular, etc..., and have come back to GWT with JsInterop to deal with
>> large projects. Porting a largish Angular/Typescript project back to GWT
>> with JsInterop, I found several bugs, because Typescript gives the illusion
>> of types and "type checking", while GWT does real type checking.
>> Put me in the camp that does not care if J2CL ever comes out. I want fast
>> compiles, especially in dev mode, anything that threatens that with a 2
>> step compile is of no interest to me. I am also not interested in anything
>> that would compile differently in dev mode than in production mode in the
>> interest of fast compiles, we have been down that road before with the
>> legacy development mode, and when something worked in dev mode but not in
>> prod mode, it was not fun to fix.
>> Anyways, I am quite sure this does not belong in this group, so let's
>> continue the discussion in the main GWT group
>>
>> On Tue, Mar 6, 2018 at 4:48 AM, Ivan Markov  wrote:
>>
>>> This time I'll bite...
>>>
>>> J2CL has been - what? - two to three years in the making - yet, there is
>>> nothing released to the public yet (aside from a preview to a few blessed
>>> individuals).
>>>
>>> Before someone follows up again with the usual matra that "it is not
>>> production ready yet and it will do more harm than good" or "somebody is
>>> porting the GWT widgets to J2CL as without these J2CL would be unusable"
>>> let's ask ourselves: *are these statements holding any ground anymore*?
>>>
>>> Here's a situation which is very likely not typical to just us:
>>> We have to - like NOW - start replacing - in our app - all the dying GWT
>>> widget-set/RPC legacy with a maintained and more contemporary toolkit
>>> (React, Angular2, whatever).
>>>
>>> (And please let's not argue over whether the GWT widget-set is still an
>>> option for any new development. For us it is not. Also let's not argue if
>>> coding against JavaScript libs with the existing GWT compiler toolchain is
>>> a viable option in the long term - it is obviously not.)
>>>
>>> The question: shall we scrap GWT altogether and rewrite in JS/TS? Or
>>> shall we continue with Java/JSInterop?
>>>
>>> Now, please enlighten me how we can defend the option of continuing in
>>> Java/JSInterop - even in front of ourselves - given that 3 years from the
>>> initial announcement - J2CL is still just smoke and mirrors for almost all
>>> Google outsiders?  We can't play with it to gain some confidence that it
>>> will work for us.. Also what happens if Google changes their mind and
>>> decides not to release it - say - due to legal issues? We would be stuck
>>> with an all-new Java/JSInterop code still bound to the dying compiler
>>> toolchain of GWT. Not a situation anybody wants to end up with, I guess...
>>>
>>>
>>> --
> 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/d9a326c6-ae1b-4577-8dd4-71d765ff547f%40googlegroups.com
> 

Re: [gwt-contrib] JUnit tests without Generators

['Goktug Gokdogan' via GWT Contributors]

The dependency issue could be solved separately in a much simpler change.
I agree improvements could be made for 2.8 testing but it is a big project
and I think it might be more worthwhile to have 3.x sooner.

Anyway we can discuss this further after we release the source.



On Fri, Feb 16, 2018 at 12:09 PM Colin Alworth  wrote:

> Several things I'd like to achieve:
>  * I'd like to support JUnit 4 in GWT2 (well, I'd actually like to support
> JUnit 5 in both, but one step at a time) - JUnit 3 practically doesn't
> exist outside of GWT2.
>  * There are probably better ways to do testing than the existing junit
> shell wiring in GWT2, such as leveraging SDM to quickly make changes and
> re-run tests, finding other ways to serve content, avoiding generators and
> arcane servlet tags, etc. Adopting JUnit4 to replace the current generator
> in GWT2 gets part of that work done up front.
>  * Existing junit shell wiring has some annoying dependencies and needs a
> rewrite anyway if we are to continue migrating and updating official
> modules - even if we decide that JUnit 3 is superior to 4, and that
> recompiling without SDM is better in GWT2, we still can't (for example)
> properly unit test an updated I18n module which uses a system property
> named `locale` without running into issues with the existing I18n module,
> which the old junit wiring makes every test use (JUnit -> Logging ->
> LoggingDisabled -> UI, which includes basically everything else in
> gwt-user).
>
> On Friday, February 16, 2018 at 1:59:12 PM UTC-6, Goktug Gokdogan wrote:
>>
>> I haven't thought about separating it from J2CL, not sure if it is a good
>> idea.
>> Why do you need it for GWT2? For code sharing, we simply use Junit3 style
>> and we didn't feel much pain about it.
>>
>>
>> On Thu, Feb 15, 2018 at 12:15 PM Colin Alworth  wrote:
>>
>>> Anything we can do to facilitate this? Also, if it is released under
>>> j2cl, is there an expectation that it could be factored out and made to
>>> work with GWT2, and released generally instead of just under J2CL (in its
>>> binaries and its deadlines)?
>>>
>>> On Friday, January 26, 2018 at 9:17:39 PM UTC-6, Goktug Gokdogan wrote:

 Yes, that's correct.

 It is a simple system with two part generation.
 First part in bazel that generates an empty java class with a class
 annotation that points to JUnit suite to trigger APT.
 The second part in APT that generates the wrapper around junit3/junit4
 tests that are listed in the suite to export test function to the global
 scope (as the javascript framework expects).

 There is no hybrid mode GwtTestcCase/JunitShell that tries to drive to
 compile or make things look like regular JVM test. End result is a pure
 javascript suite executed by a javascript test framework driver.

 On Fri, Jan 26, 2018 at 2:59 PM, Thomas Broyer 
 wrote:

> Correct me if I'm wrong, this is relying on JUnit 4 suited to generate
> appropriate goog.testing code, JUnit 3 test cases (GWTTestCase basically,
> possibly simply TestCase), with a "new" emulation of those classes based 
> on
> JsInterop to goog.testing, right? (goog.testing behaving similar to JUnit 
> 3
> to find test, setup, teardown methods/functions by naming rules)
>
> --
> 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/a083c6c4-43aa-44f0-a639-2eab1a12a2c7%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] JUnit tests without Generators

['Goktug Gokdogan' via GWT Contributors]

I haven't thought about separating it from J2CL, not sure if it is a good
idea.
Why do you need it for GWT2? For code sharing, we simply use Junit3 style
and we didn't feel much pain about it.


On Thu, Feb 15, 2018 at 12:15 PM Colin Alworth  wrote:

> Anything we can do to facilitate this? Also, if it is released under j2cl,
> is there an expectation that it could be factored out and made to work with
> GWT2, and released generally instead of just under J2CL (in its binaries
> and its deadlines)?
>
> On Friday, January 26, 2018 at 9:17:39 PM UTC-6, Goktug Gokdogan wrote:
>>
>> Yes, that's correct.
>>
>> It is a simple system with two part generation.
>> First part in bazel that generates an empty java class with a class
>> annotation that points to JUnit suite to trigger APT.
>> The second part in APT that generates the wrapper around junit3/junit4
>> tests that are listed in the suite to export test function to the global
>> scope (as the javascript framework expects).
>>
>> There is no hybrid mode GwtTestcCase/JunitShell that tries to drive to
>> compile or make things look like regular JVM test. End result is a pure
>> javascript suite executed by a javascript test framework driver.
>>
>> On Fri, Jan 26, 2018 at 2:59 PM, Thomas Broyer  wrote:
>>
>>> Correct me if I'm wrong, this is relying on JUnit 4 suited to generate
>>> appropriate goog.testing code, JUnit 3 test cases (GWTTestCase basically,
>>> possibly simply TestCase), with a "new" emulation of those classes based on
>>> JsInterop to goog.testing, right? (goog.testing behaving similar to JUnit 3
>>> to find test, setup, teardown methods/functions by naming rules)
>>>
>>> --
>>> 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/a083c6c4-43aa-44f0-a639-2eab1a12a2c7%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/daeccad3-886f-4fda-801d-694c3d4f19d3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] JUnit tests without Generators

['Goktug Gokdogan' via GWT Contributors]

Yes, that's correct.

It is a simple system with two part generation.
First part in bazel that generates an empty java class with a class
annotation that points to JUnit suite to trigger APT.
The second part in APT that generates the wrapper around junit3/junit4
tests that are listed in the suite to export test function to the global
scope (as the javascript framework expects).

There is no hybrid mode GwtTestcCase/JunitShell that tries to drive to
compile or make things look like regular JVM test. End result is a pure
javascript suite executed by a javascript test framework driver.

On Fri, Jan 26, 2018 at 2:59 PM, Thomas Broyer  wrote:

> Correct me if I'm wrong, this is relying on JUnit 4 suited to generate
> appropriate goog.testing code, JUnit 3 test cases (GWTTestCase basically,
> possibly simply TestCase), with a "new" emulation of those classes based on
> JsInterop to goog.testing, right? (goog.testing behaving similar to JUnit 3
> to find test, setup, teardown methods/functions by naming rules)
>
> --
> 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/a083c6c4-43aa-
> 44f0-a639-2eab1a12a2c7%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] JUnit tests without Generators

['Goktug Gokdogan' via GWT Contributors]

+dramaix +dankurka

It doesn't support runners nor rules; just the basic stuff.

@dramaix: Let's release the source of J2CL junit emulator under the J2CL
repo. We don't need to wait until it works for bazel.

On Fri, Jan 26, 2018 at 12:02 PM, Colin Alworth  wrote:

> As we look at how to keep migrating GWT provided user modules to modern
> best practices, the JUnit runner is a hairy one - it relies on a lot of the
> practices we discourage, including a great many modules in GWT that we
> might prefer it not use. It also assumes
>
> As has been discussed on other lists, Google has an internal APT-based
> JUnit runner that presumably emits some Java and/or JS to enable some
> JS-based test running tools to iterate through the required tests and
> notify the user of failing code, including hints as to why it failed, with
> stack traces, etc. It has been previously discussed that this might be
> something that could be shared in whole or in part with the open source
> community, time permitting.
>
> Is this still in the cards? Can any aspects of this implementation be
> discussed ahead of time so we can prepare our own tests for it? For
> example, does it use JUnit 4, and if so, can it use Rules, or just
> before/after methods?
>
> --
>
> Along similar lines, I did some work last fall to try to get JUnit 5 tests
> to work in a browser, but stopped shortly after working out how to replace
> the Engine with one that could in theory hand off control to a browser, and
> report back when complete. My idea was that if the JVM could dictate which
> tests were available to run, then JUnit 4 emulation could work, and JUnit 5
> wiring would just ask our custom engine to transpile and run those tests,
> and report back all results in the familiar junit xml, with the expected
> build tool and IDE integration. This still might be worth pursuing, perhaps
> in parallel with any work Google already has working and is able to share.
>
> Thanks,
> Colin
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/7ecb26e6-e315-
> 4e99-a89f-29a1a1a3c1b7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: What is the status of J2CL?

['Goktug Gokdogan' via GWT Contributors]

We have preview version already released to a group of
contributors/steering committee members who are playing with it and see how
it will fit into GWT 3.0 plan (things like maven workflow for J2CL +
JsCompiler).

In the meantime, we are working towards some open source usability
improvements (fixing bazel rules and open sourcing more pieces) before
giving access to wider audience.

On Wed, Jan 10, 2018 at 2:48 PM, Konstantin Solomatov <
konstantin.soloma...@gmail.com> wrote:

> Are there any updates on J2CL? More than 1 years has passed since the
> initial message.
>
> Thanks,
> Kostya
>
> On Monday, November 28, 2016 at 12:09:37 PM UTC-5, Goktug Gokdogan wrote:
>>
>> J2CL is not a replacement of GWT Java->Js compiler until it gets
>> open-source and get decided by GWT steering as a viable replacement of the
>> GWT compiler.
>>
>> For arrays, you don't need something special. You can cast your
>> javascript array to Object[] or a native jstype array  and use regular java
>> array syntax.
>>
>>
>>
>>
>>
>> On Mon, Nov 28, 2016 at 7:47 AM, Brandon Donnelson <
>> brandon@sencha.com> wrote:
>>
>>> No, JSNI will no longer be supported with J2CL, it won't be needed. That
>>> said, we are waiting on a core library with elemental to be released so
>>> that JSNI doesn't have to be used anymore, meaning you can work with arrays
>>> elements. It's a small lib.
>>>
>>> Google is working on J2CL, they're close but more work is needed before
>>> the release. I can't speak to the timeline, but it sounded not to far off.
>>>
>>>
>>> On Monday, November 28, 2016 at 7:25:07 AM UTC-8, Kirill Prazdnikov
>>> wrote:

 It is interesting: does J2CL support JSNI or not.
 Currently, @JsIndexer annotation does exist, so that it is impossible
 to work with js-arrays without JSNI.
 There are possibilities for J2CL: to have @JsIndexer, to support JSNI,
 both, something else.

 Konstantin, have you ever considered using Kotlin-js ?


 --
>>> 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/ms
>>> gid/google-web-toolkit-contributors/3fcf2415-cb8d-4edb-814e-
>>> 3c1d467fe911%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/b84a9860-a755-
> 47b0-b205-079dfbc0e9df%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: Which API for a future, modern JSON library?

['Goktug Gokdogan' via GWT Contributors]

Inline with what others asked; I think it is best to start with emulating
an existing established API instead of introducing a new proprietary API -
assuming they could be emulated with a reasonable performance.


On Sat, Dec 16, 2017 at 8:24 AM, Thomas Broyer  wrote:

>
>
> On Monday, December 11, 2017 at 10:44:07 PM UTC+1, Slava Pankov wrote:
>>
>> I think it's better to replicate GSON like API on client side. Another
>> option is doing better version of RestyGWT without GWT.create()
>>
>
> Do you mean GSON's JsonElement API, or mapping to POJOs?
> If the latter, then it's out of scope.
> (I'm not saying it's not an interesting goal, it's just not the one I'm
> pursuing here)
>
> --
> 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/12c77fe4-0509-
> 46e3-b1d3-bdcdbe8040fb%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: Elemental2:1.0.0-beta-2 released

['Goktug Gokdogan' via GWT Contributors]

+dramaix

IIRC, Elemental2 beta should only work with GWT head snapshot.

On Mon, Dec 4, 2017 at 8:20 AM, Colin Alworth 
wrote:

> com.google.jsinterop:base:1.0.0-beta-3 was released to maven central on
> nov 10:
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.
> google.jsinterop%22%20AND%20a%3A%22base%22
>
> --
>   Colin Alworth
>   co...@colinalworth.com
>
> On Sun, Dec 3, 2017, at 07:28 PM, Hristo Stoyanov wrote:
> > Hm ... Julien states it only works with the latest get head snapshot,
> > maybe not 2.8.2? Also, seems like beta-3 with Colin's findings was never
> > pushed out to maven?
> >
> > --
> > 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/214ed3ca-ddf7-46e4-a588-09ff28d731fc%40googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/1512404451.
> 1048938.1193498520.6BB7DB76%40webmail.messagingengine.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

It could be hard to communicate and set expectations with a live
work-in-progress gwt-project repository and via publishing on maven
central. I agree with Jens on first setting up a foundation, rules and also
maturing what GWT3 is; and in the meantime let people iterate in their own
repos which will set expectation accordingly.

On Wed, Nov 15, 2017 at 9:31 AM, Jens  wrote:

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

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

Re: [gwt-contrib] jsinterop-base github repository and new beta release

['Goktug Gokdogan' via GWT Contributors]

*Obviously, It should be new Object[] instead Object(). I didn't run the
code so there might be other similar issue.

On Mon, Nov 13, 2017 at 1:19 PM, Goktug Gokdogan  wrote:

> @Harald:
> JsPropertMap obj.set("key0", "value");
> obj.set("key1", 42);
> obj.set("key2", true);
> obj.set("key3", new Object() { "one", "two", "three" } );
>
> Unfortunately best documentation right now is the unit tests.
> Maybe somebody could start a cookbook for common patterns and we can
> slowly build on top of that based on questions like how can I do x, y etc?
>
>
>
> On Sun, Nov 12, 2017 at 12:19 AM, Harald Pehl 
> wrote:
>
>> +1 for some basic documentation!
>>
>> Especially the proper use
>>
>> {
>>   'key0': 'value',
>>   'key1': 42,
>>   'key2': true,
>>   'key3': ['one', 'two', 'three']
>> }
>>
>> as JsPropertyMap would help.
>>
>>
>>
>> Am Samstag, 11. November 2017 13:16:52 UTC+1 schrieb Vassilis Virvilis:
>>>
>>> Hi,
>>>
>>> is there any documentation available that we can read?
>>>
>>> It's not a big library and I can read through the code but I would
>>> appreciate a high level overview when we should employ jsinterop-base, what
>>> is the best casting strategy and all these...
>>>
>>>Vassilis
>>>
>>> On Sat, Nov 11, 2017 at 9:59 AM, 'Julien Dramaix' via GWT Contributors <
>>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>>
 I'll create a new release of elemental2 next week. Stay tuned.


 On Friday, November 10, 2017 at 6:13:31 PM UTC-8, Peter Donald wrote:
>
> Great work - thanks!
>
> Is this compatible with the last release of elemental2? (IIRC it
> was 1.0.0-beta-1)
>
> On Sat, Nov 11, 2017 at 12:22 PM, 'Julien Dramaix' via GWT
> Contributors  wrote:
>
>> Dear contributors,
>>
>> We've just created a new github repository containing the source code
>> of jsinterop-base: https://github.com/google/jsinterop-base
>>
>> We've also released a new beta version of the library:
>> jsinterop-base:1.0.0-beta-3
>> 
>>
>> You can try it by downloading the jar file
>> 
>> or use the following Maven dependency:
>>
>>
>> 
>>   com.google.jsinterop
>>   base
>>   1.0.0-beta-3
>> 
>>
>>
>> Don’t hesitate to report any bugs, issues, concerns you have on the 
>> github
>> issue tracker .
>>
>> -Julien
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to google-web-toolkit-contributor
>> s+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contrib
>> utors/CABXeq2TrKCNg0i0R%2BUB%2BPBDGEPL2r--jQFA5ZQOyywdOGvsds
>> g%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Cheers,
>
> Peter Donald
>
 --
 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-contributor
 s+unsubscr...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/ms
 gid/google-web-toolkit-contributors/ff40c05b-5f30-418e-9caa-
 6a53a96dfa84%40googlegroups.com
 
 .

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

>>>
>>>
>>>
>>> --
>>> Vassilis Virvilis
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT 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/ms
>> gid/google-web-toolkit-contributors/b288f5a1-5f7d-4244-94a0-
>> f3852f636cc9%40googlegroups.com
>> 
>> .
>>
>> For more options, visit 

Re: [gwt-contrib] jsinterop-base github repository and new beta release

['Goktug Gokdogan' via GWT Contributors]

@Harald:
JsPropertMap wrote:

> +1 for some basic documentation!
>
> Especially the proper use
>
> {
>   'key0': 'value',
>   'key1': 42,
>   'key2': true,
>   'key3': ['one', 'two', 'three']
> }
>
> as JsPropertyMap would help.
>
>
>
> Am Samstag, 11. November 2017 13:16:52 UTC+1 schrieb Vassilis Virvilis:
>>
>> Hi,
>>
>> is there any documentation available that we can read?
>>
>> It's not a big library and I can read through the code but I would
>> appreciate a high level overview when we should employ jsinterop-base, what
>> is the best casting strategy and all these...
>>
>>Vassilis
>>
>> On Sat, Nov 11, 2017 at 9:59 AM, 'Julien Dramaix' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>
>>> I'll create a new release of elemental2 next week. Stay tuned.
>>>
>>>
>>> On Friday, November 10, 2017 at 6:13:31 PM UTC-8, Peter Donald wrote:

 Great work - thanks!

 Is this compatible with the last release of elemental2? (IIRC it
 was 1.0.0-beta-1)

 On Sat, Nov 11, 2017 at 12:22 PM, 'Julien Dramaix' via GWT Contributors
  wrote:

> Dear contributors,
>
> We've just created a new github repository containing the source code
> of jsinterop-base: https://github.com/google/jsinterop-base
>
> We've also released a new beta version of the library:
> jsinterop-base:1.0.0-beta-3
> 
>
> You can try it by downloading the jar file
> 
> or use the following Maven dependency:
>
>
> 
>   com.google.jsinterop
>   base
>   1.0.0-beta-3
> 
>
>
> Don’t hesitate to report any bugs, issues, concerns you have on the github
> issue tracker .
>
> -Julien
>
> --
> You received this message because you are subscribed to the Google
> Groups "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to google-web-toolkit-contributor
> s+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contrib
> utors/CABXeq2TrKCNg0i0R%2BUB%2BPBDGEPL2r--jQFA5ZQOyywdOGvsds
> g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



 --
 Cheers,

 Peter Donald

>>> --
>>> 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/ms
>>> gid/google-web-toolkit-contributors/ff40c05b-5f30-418e-9caa-
>>> 6a53a96dfa84%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Vassilis Virvilis
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT 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/b288f5a1-5f7d-
> 4244-94a0-f3852f636cc9%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

Sorry I lost my context in user groups - didn't notice this was external
group.

What I sent was just for Google internal usages; pls ignore my message.

On Tue, Oct 31, 2017 at 2:52 PM, 'Jonathan Nieder' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Is there a public announcement equivalent to [1] for external users to
> read?
>
> вт, 31 окт. 2017 г. в 14:47, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com>:
>
>> They are not going to change and plenty of people use it for production
>> but there is a bigger issue:
>> GWT-RPC is deprecated and in maintenance mode for over 2 years now [1].
>>
>> [1] https://groups.google.com/a/google.com/d/topic/gwt-
>> announce/RjxACk-nJYI/discussion
>>
>> On Tue, Oct 31, 2017 at 4:51 AM, Rencia Cloete <rencia.clo...@gmail.com>
>> wrote:
>>
>>> Gwt Documentation as well as GWT IN action recommend extending
>>> XsrfProtectedService on client side and XsrfProtectedServiceServlet on
>>> server side
>>>
>>> But both thse methods are still marked as "EXPERIMENTAL and subject to
>>> change. Do not use this in production code."
>>>
>>> What gives? is this a leftover - or are they now safe to use in
>>> production?
>>>
>>> Thanks for your help in advance!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/google-web-toolkit-contributors/378e7424-394a-
>>> 4a04-9f18-1d00536b5fee%40googlegroups.com
>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/378e7424-394a-4a04-9f18-1d00536b5fee%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/google-web-toolkit-contributors/CAN%3DyUA2Xoq1bKSKtE5j3kanOuzKBwDN
>> uHi%2BY%3Dt4H-Rpg8LxeSw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2Xoq1bKSKtE5j3kanOuzKBwDNuHi%2BY%3Dt4H-Rpg8LxeSw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/CAKokkPEEic7jY%
> 3DiCv2u_0L_9Nq_zzprptC0zR%2BT1%2B1tEuVb85w%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKokkPEEic7jY%3DiCv2u_0L_9Nq_zzprptC0zR%2BT1%2B1tEuVb85w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

They are not going to change and plenty of people use it for production but
there is a bigger issue:
GWT-RPC is deprecated and in maintenance mode for over 2 years now [1].

[1]
https://groups.google.com/a/google.com/d/topic/gwt-announce/RjxACk-nJYI/discussion

On Tue, Oct 31, 2017 at 4:51 AM, Rencia Cloete 
wrote:

> Gwt Documentation as well as GWT IN action recommend extending
> XsrfProtectedService on client side and XsrfProtectedServiceServlet on
> server side
>
> But both thse methods are still marked as "EXPERIMENTAL and subject to
> change. Do not use this in production code."
>
> What gives? is this a leftover - or are they now safe to use in production?
>
> Thanks for your help in advance!
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/378e7424-394a-
> 4a04-9f18-1d00536b5fee%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] GWT 2.8.2 release

['Goktug Gokdogan' via GWT Contributors]

On Fri, Oct 20, 2017 at 1:32 AM, David  wrote:

> Thanks guys!
>
> One question:
>
>- Migrate guava JRE emulation to GWT
>
>
No you don't need to.
The emulation included in both for now.
Later versions of Guava will drop them and when that happens, you need to
make sure you are using 2.8.2 or a newer version of GWT if your code was
depending on emulation that was provided from Guava (e.g.
java.util.concurrent).



> Does this mean I have to migrate to a newer version of guava ?
>
> On Thu, Oct 19, 2017 at 10:31 PM Colin Alworth  wrote:
>
>> Today we released the next version of GWT, version 2.8.2. A few quick
>> highlights from this new release:
>>
>>- GWT can now run on Java 9 (though Java 9 features are not yet
>>supported, coming soon!)
>>- Chrome 61 change in getAbsoluteTop/Left has been fixed
>>- Errors on the page reported from window.onerror are now reported to
>>your uncaught exception handler
>>- GWT now generates CSP compliant dom elements
>>
>> The release notes can be found at http://www.gwtproject.org/
>> release-notes.html#Release_Notes_2_8_2. Get yours from Maven Central, or
>> from the zip release .
>> Special thanks to Max Barkley of RedHat who helped lead the release
>> effort this time, and to all of the fantastic testers who helped us ensure
>> that this release was ready to go.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/google-web-toolkit-contributors/c22fab4d-87ee-
>> 4c75-a49a-460cdc6ac3a7%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CABrJHW3jvQnQDFSLJ4vSdGJ5Ck%
> 2B8mubj%2B1hrEqv63xhmp%2BT3Yg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

I think waiting for a month to discuss issues in person is impractical when
you can use the contributor list and usually get responses less than a day.
Plus the discussion is documented automatically for future reference.
For the cases of releases where more issues / discussions needed (not
always); I agree that we could setup a time to meet to process things
quicker in bulk (gitter SGTM) .

On Wed, Oct 11, 2017 at 3:33 PM, Jens  wrote:

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

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

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

['Goktug Gokdogan' via GWT Contributors]

There should be something around syncToServer + HtmlUnit causes the issue
(I guess RPC gets called back sooner than timeout(0) but didn't debug) but
I don't think this in practice will effect anything else.

Enabling batch mode by default for everything potentially effects timeouts
also sometimes it might be incompatible with the test runner that drives
the java side of the tests (for example it doesn't work well with our
internal test sharding mechanism). Hence I don't think it worths the
trouble. I think just having batch mode enabled for junit tests is good
enough to move forward.

Daniel's patch is important for both hand written jsinterop code and
Elemental2 and yes unfortunately Scheduler.scheduleFinally will be affected.

PS: pls avoid the urge to discuss technical stuff in steering commitee and
try to keep it in the contributor list ;)

On Wed, Oct 11, 2017 at 9:59 AM, Thomas Broyer  wrote:

> As discussed minutes ago in meeting: here's the patch to enable -batch
> module for all our HtmlUnit tests: https://gwt-review.
> googlesource.com/c/gwt/+/19740
> Once that one and the HtmlUnit workaround are in, we can rebase Daniel's
> patch about trapping window.onerror by default.
>
> On Wednesday, October 11, 2017 at 10:52:41 AM UTC+2, Thomas Broyer wrote:
>>
>>
>>
>> On Wednesday, October 11, 2017 at 4:52:06 AM UTC+2, Goktug Gokdogan wrote:
>>>
>>> tbroyer: Are you using batch mode while testing? We are using -batch
>>> module internally and maybe you guys do not externally? (though you linked
>>> the code that only runs in batch mode, IIRC).
>>>
>>
>> That's right, we do not use batch mode, **and** it fixes the tests! \o/
>>
>> I wonder, should the default batching strategy be changed to module? or
>> should we use "-batch module" for all tests? only HtmlUnit tests? (we only
>> run those on CI anyway; also I tested in Firefox with -runStyle
>> ExternalBrowser:firefox, and the tests pass without the need for -batch
>> module)
>> What would you recommend?
>>
>> Colin: do we try to slip this into 2.8.2 at the last minute? (and
>> possibly revert if there's any red flag during smoke testing)
>>
>> Daniel/Goktug: iiuc, this change means that you no longer need to wrap
>> everything into $entry() to get the UncaughtExceptionHandler called on
>> errors, right? This makes things easier with JsInterop and @JsFunction
>> callbacks (or exposing objects whose @JsMethods will be called from JS),
>> but as a non-negligible side effect you won't get the
>> Scheduler.scheduleEntry and Scheduler.scheduleFinally commands called. Am I
>> getting things right?
>>
>>
>>>
>>> On Tue, Oct 10, 2017 at 1:04 PM, Thomas Broyer 
>>> wrote:
>>>
 I'll try with the manual runstyle, i.e. with a real browser, and see
 how it goes. Thanks for the feedback.

 --
 You received this message because you are subscribed to the Google
 Groups "GWT Contributors" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to google-web-toolkit-contributor
 s+unsubscr...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/ms
 gid/google-web-toolkit-contributors/1fab1f52-557b-4857-a0a9-
 f017c1d4822d%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

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

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

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

['Goktug Gokdogan' via GWT Contributors]

tbroyer: Are you using batch mode while testing? We are using -batch module
internally and maybe you guys do not externally? (though you linked the
code that only runs in batch mode, IIRC).

On Tue, Oct 10, 2017 at 1:04 PM, Thomas Broyer  wrote:

> I'll try with the manual runstyle, i.e. with a real browser, and see how
> it goes. Thanks for the feedback.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/1fab1f52-557b-
> 4857-a0a9-f017c1d4822d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Digest for google-web-toolkit-contributors@googlegroups.com - 3 updates in 1 topic

['Goktug Gokdogan' via GWT Contributors]

JsArrayLike doesn't model arrays and the code in question doesn't return an
array, so this is not about filling the gap between native array and java
arrays. JavaScript arraylike objects also doesn't have foreach.

The point of JsArrayLike.asList in the API is to bring a reasonable bridge
for array like to java world. That could be done with asIterable but if
asIterable needs to depend on Symbol.iterator which is not available
everywhere. You can do a sparse iteration with JsObect.foreach by providing
a callback.


On Thu, Aug 3, 2017 at 5:14 AM, Tony BenBrahim <tony.benbra...@gmail.com>
wrote:

> The compatibility works well when you write all of the code in Java and
> leave the JavaScript intricacies to GWT.
> That completely breaks down when you are working at the JavaScript level
> with JsInterop, because it allows you to do things you could not do in Java
> without JSNI or jsinterop.
> Take for example this sparse array:
>
> arr=[], arr[0]=10, arr[10]=20; console.log(arr.length); arr.forEach(x => 
> console.log(x));111020
>
> Even though the length of the sparse array is 11, the iterator only
> returns the 2 defined elements. The only way to correctly model that
> behavior is with asIterable() rather than asList(). I have implemented just
> that, so it is very doable.
> ​
>
> On Thu, Aug 3, 2017 at 6:00 AM, Arnaud TOURNIER <ltea...@gmail.com> wrote:
>
>> Why not make a polyfill on the native js array loaded with the gwt
>> runtime (dynamically adding needed functions on it) so that it conforms to
>> the Java array type?
>> Would be ok to do that 99%of the time I think.
>> It would simplify so much interoperability between them, IMHO...
>> Arnaud
>>
>> Le jeu. 3 août 2017 à 12:50, > r...@googlegroups.com> a écrit :
>>
>>> google-web-toolkit-contributors@googlegroups.com
>>> <https://groups.google.com/forum/?utm_source=digest_medium=email#!forum/google-web-toolkit-contributors/topics>
>>>  Google
>>> Groups
>>> <https://groups.google.com/forum/?utm_source=digest_medium=email/#!overview>
>>> <https://groups.google.com/forum/?utm_source=digest_medium=email/#!overview>
>>> Topic digest
>>> View all topics
>>> <https://groups.google.com/forum/?utm_source=digest_medium=email#!forum/google-web-toolkit-contributors/topics>
>>>
>>>- NodeList and JsArrayList.asArray
>>>
>>> <#m_-5465465850387233679_m_5374890559451667673_m_1814740188090366034_m_-6068370991899046413_group_thread_0>
>>>- 3 Updates
>>>
>>> NodeList and JsArrayList.asArray
>>> <http://groups.google.com/group/google-web-toolkit-contributors/t/9a0b1ab8b5df74bc?utm_source=digest_medium=email>
>>> Vassilis Virvilis <vasv...@gmail.com>: Aug 02 03:41PM +0300
>>>
>>> Can you expand a little bit on this? Are there any consequences we need
>>> to
>>> look for?
>>>
>>> Is there a commit to look at?
>>>
>>> On Mon, Jul 31, 2017 at 8:44 PM, 'Goktug Gokdogan' via GWT Contributors <
>>>
>>> --
>>> Vassilis Virvilis
>>> Goktug Gokdogan <gok...@google.com>: Aug 02 10:01AM -0700
>>>
>>> Unfortunately jsinterop.base doesn't have github repo available yet so
>>> you
>>> can't see the commut.
>>>
>>> Change is asArray method is replaced with asList that looks like this:
>>>
>>> @JsOverlay
>>> default List asList() {
>>> // Since it is hidden behind Arrays.asList, it is safe to do
>>> uncheckedCast.
>>> T[] asArray = Js.uncheckedCast(this);
>>> return Arrays.asList(asArray);
>>> }
>>>
>>> ​
>>>
>>> Tony BenBrahim <tony.benbra...@gmail.com>: Aug 02 02:00PM -0700
>>>
>>> In my opinion, there is too much effort put in making Array behave like
>>> a
>>> normal Java class when it is not. There are already plenty of good
>>> options
>>> in GWT/Java for collections, arrays, etc…
>>> A JavaScript Array is not equivalent to T[], for example this is a
>>> perfectly fine JavaScript Array [1,2,3,"abc", true, {x:1, y:2}] and
>>> cannot
>>> be modeled in Java. In my opinion, Array should maintain its JavaScript
>>> nature.
>>>
>>> For example if the from method actually returned an Array like it does
>>> in
>>> JavaScript:
>>>
>>> public static Array from(JsArrayLike arrayLike);
>>>
>>> instead of
>>>
>>> pu

Re: [gwt-contrib] NodeList and JsArrayList.asArray

['Goktug Gokdogan' via GWT Contributors]

Unfortunately jsinterop.base doesn't have github repo available yet so you
can't see the commut.

Change is asArray method is replaced with asList that looks like this:

  @JsOverlay
  default List asList() {
// Since it is hidden behind Arrays.asList, it is safe to do uncheckedCast.
T[] asArray = Js.uncheckedCast(this);
return Arrays.asList(asArray);
  }

​

On Wed, Aug 2, 2017 at 5:41 AM, Vassilis Virvilis <vasv...@gmail.com> wrote:

> Can you expand a little bit on this? Are there any consequences we need to
> look for?
>
> Is there a commit to look at?
>
> On Mon, Jul 31, 2017 at 8:44 PM, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> It is fixed internally. asArray API replaced with asList API
>>
>> On Mon, Jul 24, 2017 at 3:11 PM, Goktug Gokdogan <gok...@google.com>
>> wrote:
>>
>>> For following code:
>>>
>>> class A {
>>>   T[] asArray {}..
>>> }
>>>
>>> A st;
>>> String[] arr = st.asArray();
>>>
>>> I wasn't expecting an erasure cast at the call site for this but seems
>>> like I was wrong and erasure cast seems right here otherwise you cannot
>>> guarantee that arr[0] which won't have a cast to return String.
>>>
>>> We should be able to repro this in jsinterop.base; will take a look.
>>>
>>>
>>> On Sun, Jul 23, 2017 at 8:18 PM, Colin Alworth <niloc...@gmail.com>
>>> wrote:
>>>
>>>> Using GWT 2.8.1, I'm trying to iterate through items found via a query
>>>> selector:
>>>>
>>>> Arrays.asList(document.querySelectorAll("button.with-some-class").
>>>> asArray()).forEach(
>>>> item -> doSomething(item)
>>>> );
>>>>
>>>> Unfortunately, this seems to always fail - querySelectorAll returns a
>>>> NodeList, and while asArray() seems to specify Js.uncheckedCast,
>>>> the resulting generated code is
>>>>
>>>> $forEach_1(new Arrays$ArrayList(*castToJsArray*(($clinit_DomGlobal() ,
>>>> document_0).querySelectorAll('button.with-some-class'))), new
>>>> SampleClass$lambda$0$Type);
>>>>
>>>> Predictable, the bolded castToJsArray causes an exception at runtime,
>>>> since a NodeList isn't actually a JS Array at all.
>>>>
>>>> Is there a correct way to do this, or perhaps a nicer way to iterate
>>>> through NodeLists?
>>>>
>>>> I assume this should be a bug filed against jsinterop-base, but am not
>>>> seeing a repo for it, or is this a bug in GWT itself?
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "GWT Contributors" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to google-web-toolkit-contributor
>>>> s+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/google-web-toolkit-contributors/4764126b-ed92-409a-bb4b-
>>>> d1d1fead2e3c%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/4764126b-ed92-409a-bb4b-d1d1fead2e3c%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/google-web-toolkit-contributors/CAN%3DyUA3o45d%3DO9nDyVX
>> 0z_gb%2BTzkgAh_EVwOdfmO2qhxNQ5p3Q%40mail.gmail.com
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA3o45d%3DO9nDyVX0z_gb%2BTzkgAh_EVwOdfmO2qhxNQ5p3Q%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Vassilis Virvilis
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT 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/CAKbOjEycK-P-
> vSSa1TcwzcdaLWrCiFg0z3QTqKbH9JPtVYPMjA%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKbOjEycK-P-vSSa1TcwzcdaLWrCiFg0z3QTqKbH9JPtVYPMjA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Elemental2: KeyboardEvent Issues in Safari

['Goktug Gokdogan' via GWT Contributors]

Per https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key and
https://caniuse.com/#feat=keyboardevent-key it is available in Safari.

Being said that pls use gwt-user group for getting support.




On Wed, Jul 26, 2017 at 4:44 PM, Harsh Yadav  wrote:

> The following code breaks in Safari, as KeyboardEvent.key is not supported
> in Safari (https://www.w3schools.com/jsref/event_key_key.asp):
>
> inputElement.addEventListener("keypress", inKeyPressEvent -> {
>
>  if (!"Enter".equals(((KeyboardEvent) inKeyPressEvent).key)) {
>
>   handleKeyPress();
>  }
> });
>
>
> The possible alternatives like:
> charCode, keyCode ,
> which 
> could be used in this case, however they are not exposed via the
> KeyboardEvent class inside Elemental2
> Is there a work-around (other than JSNI as it works correctly)?
>
> Thanks,
> Harsh
>
> --
> 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/da14cf45-97b8-
> 43bd-b826-c34d6101b07f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] NodeList and JsArrayList.asArray

['Goktug Gokdogan' via GWT Contributors]

It is fixed internally. asArray API replaced with asList API

On Mon, Jul 24, 2017 at 3:11 PM, Goktug Gokdogan  wrote:

> For following code:
>
> class A {
>   T[] asArray {}..
> }
>
> A st;
> String[] arr = st.asArray();
>
> I wasn't expecting an erasure cast at the call site for this but seems
> like I was wrong and erasure cast seems right here otherwise you cannot
> guarantee that arr[0] which won't have a cast to return String.
>
> We should be able to repro this in jsinterop.base; will take a look.
>
>
> On Sun, Jul 23, 2017 at 8:18 PM, Colin Alworth  wrote:
>
>> Using GWT 2.8.1, I'm trying to iterate through items found via a query
>> selector:
>>
>> Arrays.asList(document.querySelectorAll("button.with-some-class").asArray
>> ()).forEach(
>> item -> doSomething(item)
>> );
>>
>> Unfortunately, this seems to always fail - querySelectorAll returns a
>> NodeList, and while asArray() seems to specify Js.uncheckedCast,
>> the resulting generated code is
>>
>> $forEach_1(new Arrays$ArrayList(*castToJsArray*(($clinit_DomGlobal() ,
>> document_0).querySelectorAll('button.with-some-class'))), new
>> SampleClass$lambda$0$Type);
>>
>> Predictable, the bolded castToJsArray causes an exception at runtime,
>> since a NodeList isn't actually a JS Array at all.
>>
>> Is there a correct way to do this, or perhaps a nicer way to iterate
>> through NodeLists?
>>
>> I assume this should be a bug filed against jsinterop-base, but am not
>> seeing a repo for it, or is this a bug in GWT itself?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/google-web-toolkit-contributors/4764126b-ed92-409a-bb4b-
>> d1d1fead2e3c%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [gwt-contrib] Re: Java 9

['Goktug Gokdogan' via GWT Contributors]

Colin, Thomas;

Since Google doesn't utilize all the code paths, I think it is important to
manually test these in supported JVMs by our contributors. Any place that
might have different classpath entries or places with potentially different
class loaders probably good places to verify; like Eclipse plugins
(superdev server, legacy dev server, junit web/dev mode).

On Wed, Jul 26, 2017 at 6:43 PM, 'Roberto Lublinerman' via GWT Contributors
 wrote:

> The correct link for the patches are
>
> https://gwt-review.googlesource.com/#/c/19000/
> https://gwt-review.googlesource.com/#/c/19020/
>
> On Wed, Jul 26, 2017 at 6:29 PM, Roberto Lublinerman 
> wrote:
>
>> I have uploaded two patches for review to allow GWT to run under a Java 9
>> vm.
>>
>> https://gwt-review.googlesource.com/#/c/19000/
>> https://gwt-review.googlesource.com/#/c/19001/
>>
>> The main issue is (as noted by James) that the class loading has been
>> revamped and GWT can no longer assume that the class loaders are
>> UrlClassLoaders.
>>
>> The idea is first to be able to run GWT on a Java 9 vm compiling Java 8
>> sources.
>>
>> On Wed, Jun 14, 2017 at 3:01 PM, James Nelson 
>> wrote:
>>
>>>
 It is my understanding that we use ASM to load the annotation
 attributes from source classes, and then create a Proxy to load member
 values / classes / enums off the classpath.  JDT is not involved at all
 (strange that it isn't...).


>>> The most likely reason we aren't using JDT to compile the annotaitons is
>>> we are really only using the parser, but not the linker (no code to emit
>>> classfiles)
>>>
>>> --
>>> 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/ms
>>> gid/google-web-toolkit-contributors/d08d7ad2-4f67-4118-bf81-
>>> 2924fedfddf3%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/CAC7T7gnO-OFBnzEKyoF1mi3W4Tqn%2BjE_
> CDTrNpGU2i98yKPjhA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] NodeList and JsArrayList.asArray

['Goktug Gokdogan' via GWT Contributors]

For following code:

class A {
  T[] asArray {}..
}

A st;
String[] arr = st.asArray();

I wasn't expecting an erasure cast at the call site for this but seems like
I was wrong and erasure cast seems right here otherwise you cannot
guarantee that arr[0] which won't have a cast to return String.

We should be able to repro this in jsinterop.base; will take a look.


On Sun, Jul 23, 2017 at 8:18 PM, Colin Alworth  wrote:

> Using GWT 2.8.1, I'm trying to iterate through items found via a query
> selector:
>
> Arrays.asList(document.querySelectorAll("button.with-some-class").asArray
> ()).forEach(
> item -> doSomething(item)
> );
>
> Unfortunately, this seems to always fail - querySelectorAll returns a
> NodeList, and while asArray() seems to specify Js.uncheckedCast,
> the resulting generated code is
>
> $forEach_1(new Arrays$ArrayList(*castToJsArray*(($clinit_DomGlobal() ,
> document_0).querySelectorAll('button.with-some-class'))), new
> SampleClass$lambda$0$Type);
>
> Predictable, the bolded castToJsArray causes an exception at runtime,
> since a NodeList isn't actually a JS Array at all.
>
> Is there a correct way to do this, or perhaps a nicer way to iterate
> through NodeLists?
>
> I assume this should be a bug filed against jsinterop-base, but am not
> seeing a repo for it, or is this a bug in GWT itself?
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/4764126b-ed92-
> 409a-bb4b-d1d1fead2e3c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

I created the patch that's moving plenty of Guava's super source to our
emulation, will send it soon.

However, I'm not planning to (and strongly against) moving CountDownLatch
since I think it will do more harm than good.

On Fri, Jul 14, 2017 at 1:28 AM, Jens  wrote:

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

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

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

['Goktug Gokdogan' via GWT Contributors]

This is a known issue that we will address.

On Thu, Jun 1, 2017 at 12:37 PM, Marcin Okraszewski 
wrote:

> Hi,
> First of all, thanks for working on this.
>
> I have some doubt if *Array* really work on *double* indexes? I know in
> JS every number is floating point, but still, indexes are logically
> integers, it would be more natural to work with integers here. Moreover,
> JsArrayLike interface is using int for interfaces, so it is even not
> consistent in this respect.
>
> I mean for instance those methods of *Array*:
>
>   public native *double *indexOf(T obj, *double *fromIndex);
>
>   public native *double *indexOf(T obj);
>
>
> While in *JsArrayLike *
>
>   default T getAt(*int* index)
>
>   default *int *getLength()
>
>
> Marcin
>
> --
> 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/54f5d447-6dff-
> 4289-a619-1d4a57204c1e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Using GWT libraries from J2CL

['Goktug Gokdogan' via GWT Contributors]

J2CL doesn't require @JsType; JsType serves same purpose as in GWT.

The likely steps required to make GWT library work with J2CL
(future-proofing) already described in multiple talks earlier but briefly;
no JSNI/JSO, no GWT.create, no generators and no com.google.gwt.*
references. This applies recursively to the library's deps as well.

On Wed, May 31, 2017 at 1:29 PM, Anders Forsell 
wrote:

> Hello,
>
> From the small examples of J2CL examples I have seen, the Java classes
> have been annotated with @JsType.
> I understand that all Java code will be transpiled to ES6 JS classes with
> J2CL but can you refer/use other Java classes/libraries without adding
> specific annotations?
>
> More concretely, if I have a GWT/Java library will I be able to use that
> library with J2CL without modifying the source of it?
>
> Thanks,
>
> Anders
>
> --
> 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/3193454b-b4c7-
> 428b-8a19-3e730601868f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

>  Is it predicated on reaching a certain quality level

Yes. It needs to be at a point that we can comfortable commit to maintain
in the longer term since it will be very like a base for compatibility
across different libraries / APIs.
We have some rough corners that we already aware and we hope to discover
more as developers play with different APIs.

On Thu, May 11, 2017 at 7:11 AM, Paul Stockley  wrote:

> Do you have a general idea for how long the Beta phase will take? Is it
> predicated on reaching a certain quality level?
>
> On Tuesday, May 9, 2017 at 6:06:12 PM UTC-4, Goktug Gokdogan wrote:
>>
>> BTW, if you are using elemental2, keep in mind that these are beta
>> releases to get feedback and APIs will keep changing until we finalize it.
>> So be prepared for breakages in releases until we do the final release cut.
>>
>> On Tue, May 9, 2017 at 2:32 PM, Julien Dramaix 
>> wrote:
>>
>>> I forgot to mention: as a workaround, you can create your own JsFunction
>>> callback and cast it to Function:
>>> @JsFunction
>>> interface MyJsFunction {
>>>   void onInvoke();
>>>
>>>   default Function asFunction() {
>>> return (Function) this;
>>>   }
>>> }
>>>
>>> On Tue, May 9, 2017 at 9:37 AM Julien Dramaix 
>>> wrote:
>>>
 > I believe it's due to how they're declared in the Closure externs:
 onreadystatechange and onerror: https://github.com/go
 ogle/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a1338172d
 f3f/externs/browser/w3c_xml.js#L393-L403
 vs all the other callbacks: https://github.com/
 google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2cca
 ac747722b/externs/browser/html5.js#L2828-L2862

 Yes, the externs use the Function object as type instead of using a
 function type like {function():any}.
 We'll fix that for the next version.

 On Tue, May 9, 2017 at 6:02 AM Thomas Broyer  wrote:

>
>
> On Tuesday, May 9, 2017 at 2:02:40 PM UTC+2, Daniel Harezlak wrote:
>>
>>
>>
>> On Tuesday, May 9, 2017 at 1:03:41 PM UTC+2, Thomas Broyer wrote:
>>>
>>>
>>>
>>> On Tuesday, May 9, 2017 at 1:03:00 PM UTC+2, Daniel Harezlak wrote:

 HI, what are the replacements for elemental2.Global.window and
 similar in this new release?

>>>
>>> elemental2.DomGlobal.window (in elemental2-dom dependency)
>>>
>> Thanks!
>>
>> Another inconsistency with the previous release of elemental2 which
>> broke my code is the use of elemental2.core.Function for the
>> onreadystatechange field in the elemental2.dom.XMLHttpRequest type
>> which prevents providing the function as a lambda. Other function fields 
>> in
>> the mentioned type (e.g. onprogress or onloadstart) seem to keep the
>> functional interface semantics. Is this intended or is it an oversight?
>>
>
> I believe it's due to how they're declared in the Closure externs:
> onreadystatechange and onerror: https://github.com/go
> ogle/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a1338172d
> f3f/externs/browser/w3c_xml.js#L393-L403
> vs all the other callbacks: https://github.com/
> google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2cca
> ac747722b/externs/browser/html5.js#L2828-L2862
>
>
> --
> 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-contributor
> s+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contrib
> utors/e1331a22-74f7-4648-b76b-0a2fb43a2dfc%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/google-web-toolkit-contributors/CABb_3%3D52vj1gbcf_MPq5U
>>> iThib3y0w4nDQHs0Bu8Sb6Ubg5Tyw%40mail.gmail.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop 

Re: [gwt-contrib] Minor thing with Elemental 2 DomGlobal.requestAnimationFrame

['Goktug Gokdogan' via GWT Contributors]

We will soon have a github repro but right now this is the right place to
report it.

It looks like closure definition is missing return definition:
https://github.com/google/closure-compiler/blob/master/externs/browser/w3c_anim_timing.js#L26

Updating that should resolve the issue. Could you file a bug in closure and
cc us as well?



On Tue, May 9, 2017 at 2:43 AM, Anders Forsell 
wrote:

> Hi,
>
> I found a small annoyance with DomGlobal.requestAnimationFrame in that
> you have to supply a function which returns an Object.
>
>   DomGlobal.requestAnimationFrame(event -> {
> myPresenter.loadContent();
> return null;
>   });
>
> I'd like to be able to pass a void method, where should I report this?
>
> Anders
>
>
> --
> 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/d6469b0d-43a1-
> 4ea3-9292-7a07d7b73dd8%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

Yes, theoretically you should be able to use the second parameter on
Json.parse Json.stringify for conversion back and forth between java
collections and js primitives. In this model, your javascript code needs to
use Java collection APIs.

> java.util.Arrays.asList() should be enough

keep in mind that Arrays.asList won't let you go out of bounds.


> I believe it was in plans with @JsConvert


We are not working on @JsConvert right now. JsConvert is just convenience
and you can mimic it:


  @JsType(isNative=true)
  interface MyType {
 @JsConvert(ListConverter.class)
 List getMyArray()
 void setMyArray(@JsConvert(ListConverter.class) List array)
  }

is roughly equivalent to:

  @JsType(isNative=true)
  interface MyType {
 @JsProperty(name="myArray")
 Object[] getMyArrayInternal();

 @JsOverlay
 default List getMyArray() { return Arrays.asList(getMyArray()); }

 @JsProperty(name="myArray")
 void setMyArrayInternal(Object[] array);

 @JsOverlay
 default void setMyArray(List list) {
   setMyArrayInternal(array.toArray());
 }
  }


On Tue, May 9, 2017 at 9:32 AM, Thomas Broyer  wrote:

>
>
> On Tuesday, May 9, 2017 at 4:34:48 PM UTC+2, Marcin Okraszewski wrote:
>>
>> There is indeed something in it. Actually you could have some type of
>> naming convention, like in TJSON (https://tonyarcieri.com/intro
>> ducing-tjson-a-stricter-typed-form-of-json) or TypedJson (
>> https://www.npmjs.com/package/typed-json) to figure out proper types.
>> But then I would need to create eg. ArrayList with the Manuel's trick (the
>> asList() from Polymer). I'll test it.
>>
>
> java.util.Arrays.asList() should be enough actually: https://github.com/
> gwtproject/gwt/blob/2.8.1/user/super/com/google/gwt/
> emul/java/util/Arrays.java#L136 (note that the ArrayList there is not
> java.util.ArrayList, it's an internal java.util.Arrays.ArrayList class that
> directly wraps the array with no copy).
>
> --
> 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/95e1bd43-b4a6-
> 4b2d-bd89-6cc6fb206631%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

BTW, if you are using elemental2, keep in mind that these are beta releases
to get feedback and APIs will keep changing until we finalize it. So be
prepared for breakages in releases until we do the final release cut.

On Tue, May 9, 2017 at 2:32 PM, Julien Dramaix 
wrote:

> I forgot to mention: as a workaround, you can create your own JsFunction
> callback and cast it to Function:
> @JsFunction
> interface MyJsFunction {
>   void onInvoke();
>
>   default Function asFunction() {
> return (Function) this;
>   }
> }
>
> On Tue, May 9, 2017 at 9:37 AM Julien Dramaix 
> wrote:
>
>> > I believe it's due to how they're declared in the Closure externs:
>> onreadystatechange and onerror: https://github.com/
>> google/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a13381
>> 72df3f/externs/browser/w3c_xml.js#L393-L403
>> vs all the other callbacks: https://github.com/
>> google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2cc
>> aac747722b/externs/browser/html5.js#L2828-L2862
>>
>> Yes, the externs use the Function object as type instead of using a
>> function type like {function():any}.
>> We'll fix that for the next version.
>>
>> On Tue, May 9, 2017 at 6:02 AM Thomas Broyer  wrote:
>>
>>>
>>>
>>> On Tuesday, May 9, 2017 at 2:02:40 PM UTC+2, Daniel Harezlak wrote:



 On Tuesday, May 9, 2017 at 1:03:41 PM UTC+2, Thomas Broyer wrote:
>
>
>
> On Tuesday, May 9, 2017 at 1:03:00 PM UTC+2, Daniel Harezlak wrote:
>>
>> HI, what are the replacements for elemental2.Global.window and
>> similar in this new release?
>>
>
> elemental2.DomGlobal.window (in elemental2-dom dependency)
>
 Thanks!

 Another inconsistency with the previous release of elemental2 which
 broke my code is the use of elemental2.core.Function for the
 onreadystatechange field in the elemental2.dom.XMLHttpRequest type
 which prevents providing the function as a lambda. Other function fields in
 the mentioned type (e.g. onprogress or onloadstart) seem to keep the
 functional interface semantics. Is this intended or is it an oversight?

>>>
>>> I believe it's due to how they're declared in the Closure externs:
>>> onreadystatechange and onerror: https://github.com/
>>> google/closure-compiler/blob/8ac08c03cd695b84f8a79ac3a13381
>>> 72df3f/externs/browser/w3c_xml.js#L393-L403
>>> vs all the other callbacks: https://github.com/
>>> google/closure-compiler/blob/b85c29855a714cae446f61c8a7b2cc
>>> aac747722b/externs/browser/html5.js#L2828-L2862
>>>
>>>
>>> --
>>> 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/e1331a22-74f7-
>>> 4648-b76b-0a2fb43a2dfc%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/CABb_3%3D52vj1gbcf_
> MPq5UiThib3y0w4nDQHs0Bu8Sb6Ubg5Tyw%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

What do you mean exactly by "collection support in JsInterop"? From you
description I only understand that you want to keep using java collection
API for existing & server side code.
If you want use your JavaScript array/map instance from Java, you need an
adaptor; doesn't matter who provides. And sure you can do it yourself.
If you want use you Java collection from JavaScript, we already
jsinterop-enabled many collection APIs.

On Mon, May 8, 2017 at 1:44 PM, Manuel Carrasco Moñino 
wrote:

> If in your model is enough to have Collections/Lists based on ArrayList
> you can easily convert from JsArrays to ArrayLists and vice-versa by using
> a bit of JSNI since the ArrayList implementation in GWT relies on a
> javascript array.
>
> Take a look to this code used in the gwt-polymer-elements library (put
> attention to asList and asArrayList methods)
>
> https://github.com/manolo/gwt-api-generator/blob/master/lib/
> com/vaadin/polymer/Polymer.java#L522
>
> - Manolo
>
>
> On Mon, May 8, 2017 at 10:27 PM, Marcin Okraszewski 
> wrote:
>
>> Basically what we need it for is REST. Currently we use AutoBeans, but we
>> want to change it because we need to pass the model to JS too; secondly
>> AutoBeans generate a lot of code. We would like to still preserve shared
>> model with the server. So, JsInterop seems the most natural choice, except
>> it doesn't support collections. We mostly need List and Map. Switching to
>> JsInterop with replacing Lists with some JS array view would be quite an
>> effort. It would introduce that into our server logic too (by the shared
>> model). And and you could even use Java's for each loop, as native JsType
>> cannot extend non-JsType interfaces, so it could not extend Iterable (of
>> course adapter could be instantiated for every list you want to iterate).
>> Same for streams.
>>
>> Therefore we look for collection support in JsInterop, which was planned
>> for "phase 2". If that was in our reach, we could help in getting it.
>>
>> Marcin
>>
>>
>> On Monday, 8 May 2017 16:42:17 UTC+2, Ray Cromwell wrote:
>>>
>>> The adapter class adds overhead though and you need to convert into and
>>> out of it every time you pass it to JS. At that point you may as well use
>>> Java.util.List and write an adapter around JS array.
>>>
>>>
>>> On Mon, May 8, 2017 at 7:10 AM Jens  wrote:
>>>
 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-contributor
 s+unsubscr...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/ms
 gid/google-web-toolkit-contributors/4d08f88c-ec88-4818-b778-
 3e0e247f2e7e%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/google-web-toolkit-contributors/5e9868cd-35d6-4f48-81b8-
>> ef26ff791906%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/CAM28XAsesxqBxAS9Pjov%3DfPqy_
> u2raCEmFWLsO6OZN%3DbDrcpqA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop 

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

['Goktug Gokdogan' via GWT Contributors]

Maybe related to $wnd, but here we are basically shooting in the dark. You
should debug your code and tell us where it behaves unexpectedly otherwise
we cannot help much...

On Wed, May 3, 2017 at 12:57 PM, TimOnGmail  wrote:

> Ok... here's the client app side - I haven't tried running this as-is,
> since it was culled from a much bigger piece of code.  But this is the gist
> of it:
>
> package com.example;
>
> public class ChromeAPIExample {
>
> private static final String CHROME_APP_ID = "..."; // Replace with
> actual Chrome app id
>
> public ChromeAPIExample() {
> initChromeListener();
> }
>
> private native void initChromeListener() /*-{
>
> try {
>
> $wnd.example = new Object();
>
> $wnd.example.isChrome = function() {
>
> var isChromeBrowser = false;
>
> try {
> isChromeBrowser = (typeof chrome !== 'undefined');
> } catch (e) {
> console.log('isChrome: cannot determine if using
> chrome: ' + e);
> }
>
> return isChromeBrowser;
> };
>
> if (!$wnd.example.isChrome()) {
> console.log('initChromeListener: not using chrome;
> returning');
> return;
> }
>
> if ($wnd.example.chromePort && ($wnd.example.chromePort !=
> null)) {
> console.log"initChromeListener: chromePort still exists,
> returning");
> return;
> }
>
> console.log('initChromeListener: this is chrome');
>
> var thisInstance = this;
> var chromeAppId = @com.example.ChromeAPIExample:
> :CHROME_APP_ID;
>
> try {
>
> // Check if the app is installed and enabled by opening a
> messaging port
> var port = chrome.runtime.connect(chromeAppId);
>
> if (port) {
>
> $wnd.example.chromePort = port;
>
> console.log('initChromeListener: got port: ' + port);
>
> port.onMessage.addListener(function(msg) {
> console.log('chrome listener: msg: ' + msg);
>
> });
>
> }
>
> } catch (e) {
> console.log('initChromeListener: Inner Error: ' + e);
> }
> } catch (e2) {
> alert('initChromeListener: Outer Error: ' + e2);
> }
>
> }-*/;
>
> }
>
>
>
> ... and here's a snippet of code from the Chrome app.  If the above code
> was run in GWT 2.6, the Chrome app would log the connection attempt from
> the app.  In GWT 2.8, we get a port object back from the Chrome connection
> attempt, but the Chrome app doesn't see the connection attempt:
>
> ...
>
> initialize();
>
> function initialize() {
> chrome.runtime.onConnectExternal.addListener(onConnectExternal);
> }
>
> function onConnectExternal(port) {
>
>   logMsg('onConnectExternal: port=' + port);
>
> port.onDisconnect.addListener(function() {
> logMsg('Port disconnected');
> });
> }
>
>
> - Tim
>
>
> On Tuesday, May 2, 2017 at 7:10:12 PM UTC-7, Goktug Gokdogan wrote:
>>
>> This might be related to linker changes but not sure that in which
>> version that was changed.
>>
>> Pls provide the code snippet that was working before and no longer
>> working.
>>
> --
> 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/87a97383-b3a1-
> 436a-832f-79594a4b1b3b%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

This might be related to linker changes but not sure that in which version 
that was changed.

Pls provide the code snippet that was working before and no longer working.


On Tuesday, May 2, 2017 at 6:00:50 PM UTC-7, TimOnGmail wrote:
>
> No no, I had been calling Java -> JSNI -> Chrome ; that worked in GWT 2.6
>
> Now, in GWT 2.8, the above does NOT work.
>
> I modified the code to do: Java -> JSNI -> JavaScript that's not wrapped 
> in a JSNI method (it's in the app's main JSP file) -> Chrome, and it works 
> again.
>
> So, JSNI methods calling Chrome APIs directly appear to no longer be 
> working.
>
> Does that explain it better?
>
> - Tim
>
>
> On Monday, May 1, 2017 at 4:11:29 PM UTC-7, Colin Alworth wrote:
>>
>> What had been the care previously? Were you calling the chrome methods in 
>> some way other than through JSNI? Java methods can't call raw JavaScript 
>> without JSNI (or JsInterop, which didn't exist in GWT 2.6). 
>> Otherwise I'm not sure what you changed it _from_ to get to the 
>> psuedocode in your post.
>>
>> I'm not aware of breaking changes that should have happened (though it 
>> has been three years between the releases). It is possible that you were 
>> using JSNI in a way that probably shouldn't have worked previously, and 
>> since then it has been "fixed"?
>>
>> On Monday, May 1, 2017 at 5:02:09 PM UTC-5, TimOnGmail wrote:
>>>
>>> So it appears that this is caused by JSNI methods somehow being morphed 
>>> when the GWT app is compiled.  I don't know how, but I do know that calls 
>>> to Chrome proprietary APIs aren't working correctly.  I modified my code to 
>>> do the following:
>>>
>>> Java method calls JSNI method
>>> JSNI method calls raw JavaScript method in base app loading page (a JSP 
>>> page)
>>>
>>> ... and it now works.  So the GWT compiler is doing something funny to 
>>> JSNI methods that cause the Chrome API calls not to work as expected.
>>>
>>> Anyone know what's happened there?
>>>
>>> - Tim
>>>
>>>

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

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

['Goktug Gokdogan' via GWT Contributors]

Nice!
But just FYI, I'm not sure how up to date the loggings in the compiler are
so the results might be misleading.

On Mon, Apr 24, 2017 at 5:07 PM, Jens  wrote:

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

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

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

['Goktug Gokdogan' via GWT Contributors]

jsinterop.base doesn't try to replace elemental, just provide methods that
would normally require special syntax in js. You can find Object.keys in
the related elemental class (JsObject)

On Thu, Apr 13, 2017 at 1:42 PM, Ignacio Baca Moreno-Torres <
igna...@bacamt.com> wrote:

> Hi, a question about JsPropertyMap.
>
> It does not have a keys() method, ideally using Object.keys, this is on
> purpose?
> And, the unique method to obtain the keys is the forEach method, but
> current implementation iterates over all properties wich might be
> dangerous, why this method do not use Object.keys or isOwnProperty?
>
> Thanks!
>
> On Friday, April 7, 2017 at 1:57:44 AM UTC+2, Roberto Lublinerman wrote:
>>
>> We relaxed restriction checking to allow void return type from getters.
>>
>> Cl is up for review:
>> https://gwt-review.googlesource.com/#/c/18020/
>>
>>
>>
>> On Thu, Apr 6, 2017 at 3:17 PM, Jens  wrote:
>>
>>> 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/ms
>>> gid/google-web-toolkit-contributors/d460f0fb-6519-4eab-869b-
>>> 4838e51077ad%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/7aae33f9-32af-
> 4c40-9c15-81860a109fa6%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

Thanks for the feedback.

On Wed, Feb 15, 2017 at 1:05 PM, Ming-Yee Iu  wrote:

> Well, ok. Thanks.
>
> Just in terms of general feedback on Elemental2:
>
> 1. I'm not sure whether the conversion of JavaScript properties to Java
> fields is the best choice. Sure, it "feels" more like the original
> JavaScript, but
>


> a) it's inconsistent with Java semantics,
>

This could be a stylistic inconsistency not a semantic one. All arguments
that I have seen in favor for having accessors instead of fields are
inapplicable to Elemental fields since they all assume changes in the
implementation of accessors which in our case always a pass through.

However I am aware of the stylistic expectation from some java devs and we
might end up providing setter/getter as overlays for people who would like
to stick conventional style.


> b) I'd be afraid that a Java compiler might apply some unexpected
> optimization there as a result,
>

I don't think that's possible.


>  c) it's harder to mock the behavior of the classes for unit tests
>

Actually a field doesn't require mocking; but native accessor as you are
proposing does require mocking.


> and d) alternate implementations of Elemental2 aren't possible (for
> example, I couldn't make a DevMode-like JavaFx version of Elemental2 like I
> did with Elemental 1).
>

I can see how accessor can help with this as it gives you more flexibility
on your  re-implementation of the API.


>
> 2. Personally, I would prefer if Elemental 2 used interfaces over classes
> (for similar reason as above), though I understand that being able to use
> "new ...()" syntax on things is nice too.
>

That is more than that:  https://groups.google.com/d/
topic/google-web-toolkit-contributors/L6uh96NcZtE/discussion


>
> 3. The number of callback classes is out-of-control. Can they be
> consolidated somehow?
>
>
Hopefully next release will cleanup plenty of them.


> 4. Also, is it possible to supplement the typing information for some of
> those callbacks from Typescript? Everyone knows that "onclick" handlers
> pass a MouseEvent. I'm not sure if Closure has a rich enough type system or
> is sufficiently well-developed to generate the best API there.
>

The language gap between TypeScript and Java is actually higher than
Closure and Java. That makes it harder to precisely mimic type info that
exists in d.ts via Java abstractions.

Hopefully we could make this work better over time.


>
> 5. Can there be some magic that makes elemental2.Iterable a real Java
> Iterable?
>

We can probably do something here. Will track that issue.


>
> Otherwise, it seems nice. I like that there's a NodeList now!
>
> --
> 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/ms
> gid/google-web-toolkit-contributors/cb2a997b-2d25-43c0-911a-
> ba13a448e14e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

+dramaix

On Sat, Feb 11, 2017 at 3:11 PM, Ming-Yee Iu  wrote:

> It's a little unfortunate that Elemental is being developed privately
> since it's the one part of GWT that's self-contained enough that I am able
> and willing to contribute to it. But is it possible to get an early,
> unofficial, unsupported code drop of the current Elemental code generator?
>
>
https://groups.google.com/d/msg/google-web-toolkit-contributors/bpJDcYWLJDk/tY1NeT2tAQAJ


> I'm a big user of Elemental 1, and I'm thinking about custom generating my
> own framework instead of using Elemental 2 so that I can have an API that
> works better with my own workflow. Being able to see the existing code
> generator would help me in knowing how much work would be involved and
> would allow me to avoid duplicating effort.
>

Writing a generic generator is complex task since Closure and TypeScript
type system are quite rich. Our generator is already over 25k and growing.
It might be more trivial if you just target a subset and gave up strictness
of the types in the API (e.g. using Object when you see union types).


>
> If that's not possible, would it be possible to at least get some details
> about the implementation? Is it written in Python like Elemental 1 was or
> is it written in Java? What data sources does it consume? Does it take
> Typescript or Web IDL as input or something else?
>

It is written in Java and supports 2 entry points:
  1- TypeScript input which uses official TypeScript parser/AST.
  2- Closure extern files which uses Closure compiler / AST.

Both entry points end up creating a common Java model that rest of the
generation pipeline runs over and finalizes the Java APIs.


>
> Thanks
> -Ming
>
> --
> 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/507ab806-d365-
> 4889-81ce-ece6c0e7885a%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

Small correction: Google is not planning to delete dev-mode from GWT
proper. That's community's decision based on how the would like to move
forward with GWT 3.0.

Wrt. J2CL; pls don't expect a beta release of J2CL this quarter. Also J2CL
doesn't even have devmode since transpilation is instant (think java).

On Fri, Jan 13, 2017 at 7:34 AM, Kirill Prazdnikov 
wrote:

> have been pushing for more than a year now to delete it from GWT proper
>> too.
>>
>
> Are there any updates on that ?
> Is there some patch for review ?
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/beafcbb5-8e3e-
> 4fd3-8254-eb279307549a%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: What is the status of J2CL?

['Goktug Gokdogan' via GWT Contributors]

J2CL is not a replacement of GWT Java->Js compiler until it gets
open-source and get decided by GWT steering as a viable replacement of the
GWT compiler.

For arrays, you don't need something special. You can cast your javascript
array to Object[] or a native jstype array  and use regular java array
syntax.





On Mon, Nov 28, 2016 at 7:47 AM, Brandon Donnelson <
brandon.donnel...@sencha.com> wrote:

> No, JSNI will no longer be supported with J2CL, it won't be needed. That
> said, we are waiting on a core library with elemental to be released so
> that JSNI doesn't have to be used anymore, meaning you can work with arrays
> elements. It's a small lib.
>
> Google is working on J2CL, they're close but more work is needed before
> the release. I can't speak to the timeline, but it sounded not to far off.
>
>
> On Monday, November 28, 2016 at 7:25:07 AM UTC-8, Kirill Prazdnikov wrote:
>>
>> It is interesting: does J2CL support JSNI or not.
>> Currently, @JsIndexer annotation does exist, so that it is impossible to
>> work with js-arrays without JSNI.
>> There are possibilities for J2CL: to have @JsIndexer, to support JSNI,
>> both, something else.
>>
>> Konstantin, have you ever considered using Kotlin-js ?
>>
>>
>> --
> 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/3fcf2415-cb8d-
> 4edb-814e-3c1d467fe911%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: Utils

['Goktug Gokdogan' via GWT Contributors]

wrt general refactoring:

I think the biggest value to take apart is emulation + annotations.
You might want to take out the testing infra so it is not compiled together
with the rest. Similarly SDM as well.
For the rest I don't see much value trying to separate into multiple pieces.

PS: Speedtracer is probably already dead; at least for us internally for
very long time.


On Sun, Nov 13, 2016 at 8:31 AM, Jens  wrote:

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

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

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

['Goktug Gokdogan' via GWT Contributors]

FWIW, I agree with tbroyer's assessment and the suggestion to use a helper
sounds reasonable.

On Thu, Nov 3, 2016 at 10:40 AM, Thomas Broyer  wrote:

>
>
> On Thursday, November 3, 2016 at 5:33:31 PM UTC+1, Colin Alworth wrote:
>>
>> With 3.0 on the horizon, we've promised consistency of a sort in 2.x, and
>> without 3.0 actually in sight, 2.x is going to need to see active
>> development. Encouraging a third generation of url tools is not a bad
>> thing, but only switching over half-way leaves something to be desired.
>>
>> I'll play devil's advocate a bit - I'm not addressing the patch
>> specifically (since I haven't fully read all of it or the discussion around
>> it, and if it was a bad patch, I'm sure it would have been shot down on its
>> own merits) but the thinking to use around what goes into the 2.x branch:
>>  * (point 1) We're not ready for maintenance mode, at least until we have
>> timelines and completed APIs for GWT 3. If we are, we should be forbidding
>> all merge requests to gwt-user that don't fix critical bugs.
>>
>>  * (point 2 and 3) Can't argue with new tools arriving that solve the
>> problem better, especially if they are going into 3 as a cross-platform way
>> of solving the problem (gwt/java/j2cl). Obvious caveat here (even for the
>> devil's advocate) that with the release of 3, breaking changes off of 2 are
>> acceptable and expected.
>>
>>  * (point 4) Without transitioning the existing GWT Safe* tools,
>> SafeHtmlTemplates is stuck in the past, as is UiBinder, I18n Messages, and
>> any HasSafeHtml widget (both in GWT and in the general ecosystem). This is
>> a lot to leave behind in the name of "but the tool didn't belong in GWT in
>> the first place". We've had our chance to properly deprecate it for the 2.8
>> release, and if our past timelines are any measure, it is going to be at
>> least a year before we finally ship a release with SafeHtml, and all that
>> use it, deprecated. And once we've reached that point, unless gwt-user
>> depends on (or rebases, etc) safe-html-types or any other successor, all of
>> the above downstream classes which use SafeHtml are left effectively broken
>> (not unlike the unported Generators and Linkers we have today).
>>
>> Obviously ClientBundle/GssResource isn't actually deprecated, but we have
>> officially said that new tools should not use the features that it takes
>> advantage of. SafeHtml takes this a step further - GssResource got several
>> upgrades within the 2.8 release (unlike other generators), despite it being
>> deprecated, but with SafeHtml going out, it takes out features within many
>> GWT Widgets themselves. There will be no officially supported way to
>> correctly assign safe html content into an HTML widget.
>>
>> Now yes, a bit of hyperbole there - you can of course (as Thomas noted in
>> his email) simply asString() the not-gwt SafeHtml and use it, or provide
>> your own wrapper, but depending on your project size (and GWT users out
>> there have some big ones) that could be hundreds or thousands of sites to
>> fix in code. Yet another change would be needed for any widgets that the
>> project has which implement HasSafeHtml (so it can still be used in
>> UiBinder), UiBinder @UiFields or getters (which return SafeUri for use in
>> its embedded SafeHtml handling), Messages (to wrap any incoming url). This
>> ignores any use of Messages/Constants in a SafeHtml-using uibinder itself -
>> I'm not seeing a clear path there without the use of default methods in
>> I18n interfaces (which admittedly, would probably work, but isn't going to
>> be pretty).
>>
>
> You forgot one major point here: this patch is proposing a new API (new
> overloads to existing methods), without actually changing the current API
> (at least in terms of its contract).
> So it's not about changing "every call sites for SafeHtml/UriUtils API",
> it's about being able to take advantage of a new behavior by selectively
> calling a new API.
> If you want that behavior everywhere, then yes you'll have to update all
> call sites; but the patch doesn't change that in any way (except what you
> change your code *to*)
> All those existing usage of SafeHtml you cited (SafeHtmlTemplates,
> UiBinder, I18N and HasSafeHtml) would be unchanged and keeping their
> current behavior (and only 2 of them deal with SafeUri: SafeHtmlTemplates
> and UiBinder). And the only two cases where UriUtils is called by those
> (vs. receiving a SafeUri value from the "user") are discouraged and
> generate a warning (and would continue to only use the default whitelist
> and reject "tel:" URIs; if you'd like to allow "tel:" URIs there, you'd
> have to change to SafeUri anyway, and then the responsibility of converting
> a String to a SafeUri falls on you, so no change to UriUtils or other
> APIs/generators is actually *required*):
> https://github.com/gwtproject/gwt/blob/3a41a8067767965ff72f4e49eb015f
> 

Re: [gwt-contrib] Re: Elemental2 - What's the big secret?

['Goktug Gokdogan' via GWT Contributors]

I think you misinterpreted "overhead to make it available outside".

On Tue, Oct 11, 2016 at 6:38 PM, Alex White  wrote:

> On Wednesday, October 12, 2016 at 9:59:40 AM UTC+10, Goktug Gokdogan wrote:
>>
>> Elemental 2 is based on a generator and the generator is in active
>> development and constantly changing. I don't think it is feasible to get
>> any contributions at this stage. Since we cannot get contributions and
>> there is an overhead to make it available outside, we chose to release it
>> after more maturity.  I know it is not an ideal but more of a practical
>> choice.
>>
>>
> It would be better if you just said "we wish to keep this part of gwt
> proprietary". Because what you are saying here, you could say that about
> any project; and it doesn't hold water. No one would force you to accept
> outside patches, it's a voluntary process.
>
> --
> 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/b51ecd8a-fcd1-
> 4fdf-8e47-f32edfe997a1%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: Elemental2 - What's the big secret?

['Goktug Gokdogan' via GWT Contributors]

Elemental 2 is based on a generator and the generator is in active
development and constantly changing. I don't think it is feasible to get
any contributions at this stage. Since we cannot get contributions and
there is an overhead to make it available outside, we chose to release it
after more maturity.  I know it is not an ideal but more of a practical
choice.

On Tue, Oct 11, 2016 at 2:43 PM, Alex White  wrote:

>
>> Elemental 2 is a completely new project that is being developed
>> internally by Google, but their intention is to publish it as open source
>> once the maturity of the code matches their internal threshold.
>>
>>
>>
> Just curious if this is still going to see the light of day? What's the
> point in having an open source project if other engineers can't contribute?
>
> --
> 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/6686fa2a-ac0b-
> 47b8-b12c-8e8b47e60282%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

We are doing a last minute fix. Next RC should be ready very soon and if no
major issues it will be called final release around 2-3 weeks.

On Wed, Sep 28, 2016 at 3:16 AM, Hitesh Kumar 
wrote:

> Is there an ETA on GWT 2.8.0 release?
>
> On Friday, 12 August 2016 06:49:03 UTC+5:30, Daniel Kurka wrote:
>>
>> Hi all,
>>
>> I just build the GWT 2.8.0 RC2 and pushed it to maven central. The
>> complete SDK is also available from here .
>>
>> Please start testing and let us know if you run into any trouble and file
>> bugs .
>>
>> We are planing to release this as GWT 2.8.0 if we do not here about any
>> serious issues within the next two weeks. The release notes for RC
>> 2
>>  will
>> be made available shortly after this notice, in the mean time you can take
>> a look at the github repository
>> 
>> .
>>
>> Daniel,
>> on behalf of the GWT team
>>
>>
>>
>> --
> 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/4eb77ad7-0dec-
> 43d4-910d-a3f3ef490045%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

We should hold up the release. There is another path around arrays as well.

On Fri, Sep 9, 2016 at 8:04 AM, Colin Alworth  wrote:

> Another issue at may warrant attention - https://github.com/
> gwtproject/gwt/issues/9424. This was brought up some time ago, but wasn't
> reduced to be reproducible until now (which is funny, given how minimal the
> test case is).
>
> On Fri, Sep 9, 2016 at 9:30 AM 'Daniel Kurka' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> +Goktug Gokdogan  +Roberto Lublinerman
>>   Should we be holding RC3, I guess so right?
>>
>> On Fri, Sep 9, 2016 at 4:12 PM Jens  wrote:
>>
>>>
>>> Can you file an issue and ping Daniel (by mail or hangout) to delay the
 RC3 a bit? (if not already too late, as it's 4pm cest)

>>>
>>> Done.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/google-web-toolkit-contributors/6386bb88-f488-
>>> 4144-b830-99ddb387b677%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/google-web-toolkit-contributors/CALLujirOwMPQTKzDuJtmtF0hF2bXV
>> r%3Dij-V240vzP6Bh5SMRAA%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

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

['Goktug Gokdogan' via GWT Contributors]

Global object is not scoped to window unless you explicitly say "window";
so it should be $wnd by default.

On Wed, Sep 7, 2016 at 2:50 AM, David <david.no...@gmail.com> wrote:

> I was depending on JsInterop Global.document to get access to UI
> components generated by my template engine.
> The Global object is now scoped window, so I guess it is accessing the
> wrong document as well ?
>
>
> On Wed, 7 Sep 2016 at 11:40, David <david.no...@gmail.com> wrote:
>
>> I'm sure that it worked before. I'm also seeing some other issues where I
>> am using JsInterop to interact with some generated HTML - but I am still
>> investigating if that is due to changes in GWT or in our codebase.
>>
>> I did not work on this project for about 8 weeks, so I have quite a
>> backlog to go through.
>>
>> On Tue, 6 Sep 2016 at 19:28, 'Goktug Gokdogan' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>
>>> It is surprising as Jens pointed out, we always qualified references
>>> with $wnd until https://gwt-review.googlesource.com/#/c/15520/
>>> (submitted 5 weeks ago). So it shouldn't have worked earlier if you were
>>> not injecting it to TOP_WINDOW.
>>> If it worked earlier, then we unintentionally fixed a bug. Could you
>>> double check if this was working before so we can see if there are some
>>> other unintended behavior change introduced somewhere else?
>>>
>>> On Tue, Sep 6, 2016 at 2:43 AM, stuckagain <david.no...@gmail.com>
>>> wrote:
>>>
>>>> It was working fine before.
>>>>
>>>> Since it looks like JsInterop has changed recently (and it is still in
>>>> beta) I will just update my code to either inject in the TOP_WINDOW or I
>>>> try it with using window as namespace.
>>>>
>>>>
>>>> On Monday, September 5, 2016 at 6:29:48 PM UTC+2, Jens wrote:
>>>>>
>>>>> 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+unsubscribe@
>>>> googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/google-web-toolkit-contributors/7862784c-854a-
>>>> 4bb1-85c0-2b7734a984d3%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/7862784c-854a-4bb1-85c0-2b7734a984d3%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/google-web-toolkit-contributors/CAN%3DyUA0RioQk7GatwdbkvwZKT6gKDEm
>>> B0daytVoKa9a%3DnGUd3A%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0RioQk7GatwdbkvwZKT6gKDEmB0daytVoKa9a%3DnGUd3A%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubs

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

['Goktug Gokdogan' via GWT Contributors]

It is surprising as Jens pointed out, we always qualified references with
$wnd until https://gwt-review.googlesource.com/#/c/15520/ (submitted 5
weeks ago). So it shouldn't have worked earlier if you were not injecting
it to TOP_WINDOW.
If it worked earlier, then we unintentionally fixed a bug. Could you double
check if this was working before so we can see if there are some other
unintended behavior change introduced somewhere else?

On Tue, Sep 6, 2016 at 2:43 AM, stuckagain  wrote:

> It was working fine before.
>
> Since it looks like JsInterop has changed recently (and it is still in
> beta) I will just update my code to either inject in the TOP_WINDOW or I
> try it with using window as namespace.
>
>
> On Monday, September 5, 2016 at 6:29:48 PM UTC+2, Jens wrote:
>>
>> 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/GcsW
>> UuzexvE/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/7862784c-854a-
> 4bb1-85c0-2b7734a984d3%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

That is added relatively recent.
And thanks for pointing the documentation issue; add a issue to review all
before the final release.

On Thu, Sep 1, 2016 at 10:08 PM, Arnaud TOURNIER <ltea...@gmail.com> wrote:

> Thanks a lot for your answer.
>
> I tried the solution with defender methods earlier but it did not work, as
> far as i remember the compiler refused @JsOverlay defender methods on the
> JsFunction. The @JsFunction documentation says that : "A JsFunction
> interface cannot have defender methods."
> I will try again in this direction and let you know if i find a bug.
>
> Thanks
> Arnaud
>
> Le ven. 2 sept. 2016 à 05:28, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> a écrit :
>
>> The limitation around @JsFunction is basically driven from the
>> limitations of being a function. I think there was an earlier discussion in
>> the contibutor list where we explained this in more detail.
>>
>> Being said that, you can handle some overloading in JsFunction interfaces
>> via defender methods marked with @JsOverlay that are delegating to a main
>> method. Something like:
>>
>>
>> @JsFunction
>> public interface Resolver {
>>
>> void resolve(Object value);
>>
>> @JsOverlay
>> default void resolve() { resolve(null); }
>> @JsOverlay
>> default void resolve(T value) { resolve(value); }
>> @JsOverlay
>> default void resolve(Promise value) { resolve(value); }
>> }
>>
>> Let's us know before it is too late if you hit any bugs around this :)
>>
>>
>> On Tue, Aug 30, 2016 at 7:13 AM, Arnaud TOURNIER <ltea...@gmail.com>
>> wrote:
>>
>>> Oh thanks! I'll try that.
>>> Once I think we need to merge our work on those topics...
>>> Thanks!
>>>
>>> Le mar. 30 août 2016 16:06, Paul Stockley <pstockl...@gmail.com> a
>>> écrit :
>>>
>>>> If you are passing  Resolver into some function. You could instead
>>>> create 3 Resolver interfaces and then overload the function so that it took
>>>> each of the resolver interfaces.
>>>>
>>>>
>>>> On Saturday, August 27, 2016 at 9:51:50 AM UTC-4, Arnaud TOURNIER wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am playing with js Promises and maybe there's a problem with
>>>>> JsInterop or i don't understand something.
>>>>>
>>>>> When wrapping the promises with JsInterop, i come to define the
>>>>> Resolver interface which represents the resolving callback that is given
>>>>> when constructing a promise. In Javascript it is a function and not an
>>>>> object, so the interface has the @JsFunction annotation.
>>>>>
>>>>> Here is the Resolver interface (inspired from the TypeScript
>>>>> definition of Promises...) :
>>>>>
>>>>> @JsFunction
>>>>> @FunctionalInterface
>>>>> public interface Resolver
>>>>> {
>>>>> void resolve( T value );
>>>>> }
>>>>>
>>>>> Since the Javascript "resolve" function can be called without
>>>>> parameters and also with a Promise instead of a value, i would like to 
>>>>> make
>>>>> those versions available in the interface.
>>>>>
>>>>> But the @JsFunction annotation prevents from having this :
>>>>>
>>>>> @JsFunction
>>>>> public interface Resolver
>>>>> {
>>>>> void resolve();
>>>>>
>>>>> void resolve( T value );
>>>>>
>>>>> void resolve( Promise value );
>>>>> }
>>>>>
>>>>> That's because it allows only one method in the annotated interface.
>>>>>
>>>>> That is what i don't understand : AFAIK, the gwt compiler has to call
>>>>> the same function in the same way for the three declared methods (because
>>>>> of the semantic of the @JsFunction annotation), just changing the calling
>>>>> parameters. So i don't understand why is there the limitation of having
>>>>> only one method allowed in @JsFunction interfaces... If it would it would
>>>>> give even much power to JsInterop !
>>>>>
>>>>> Could you please bring light to my misunderstanding ?
>>>>>
>>>>> Thanks !
>>>>>
>

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

['Goktug Gokdogan' via GWT Contributors]

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

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


@JsFunction
public interface Resolver {

void resolve(Object value);

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

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


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

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

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

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

['Goktug Gokdogan' via GWT Contributors]

Document includes a comment about it in the examples and the section that
describes the migration from 2.7 has an instruction to add the flag.

On Mon, Aug 22, 2016 at 7:17 AM, Boris Brudnoy  wrote:

> Thanks guys. A note on this should certainly make it into the public
> JsInterop doc, somewhere close to the definition of the
> JsType/JsMethod/JsProperty contract.
>
> On Mon, Aug 22, 2016 at 8:04 AM Jens  wrote:
>
>>
>> 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/ms
>> gid/google-web-toolkit-contributors/6ea6ad27-695d-4eec-8e0c-
>> c2a49be9a422%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> *BORIS BRUDNOY*
> Web Application Developer, Java/GWT Enthusiast (LinkedIn
> )
>
> --
> 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/ms
> gid/google-web-toolkit-contributors/CAD%3DgKQ0_A3T9i-6nn9rL5
> bFBC9SatO8rbYiY%2BWQ82arAQwmTsg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Experimental release of Elemental2

['Goktug Gokdogan' via GWT Contributors]

On Mon, Aug 8, 2016 at 6:40 AM, stuckagain  wrote:

> Some comments:
>
> - Is there a possibility that the API's don't overuse double in the future
> ? For example the XMLHttpRequest.status property is supposed to be an
> integer not a double.
>

Yes, we will look into.


> - The API's do not use set/get/is as was the case in the old Elemental. So
> how can I now detect that a property is readOnly ?
>
>
We can probably make it final but if we know it is readonly but I think we
are not sure when the field is readonly. Julien?


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

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

Re: [gwt-contrib] GWT 2.8.0-rc1 issue (GWT 2.8.0-beta1 working)

['Goktug Gokdogan' via GWT Contributors]

I'm not sure what you mean by working fine. If animal doesn't exist in the
object; it is expected to fail. Can you provide a full repro example?

On Thu, Aug 4, 2016 at 2:50 AM, Teletin Alin 
wrote:

> Hi,
>
> I do have a problem since moving to rc1 related to a map object.
> Using beta1 the code works ok, but with rc1 it yields
> "this.static$.animals.put is not a function".
>
> Example code:
>
> @JsNative(isNative = true, namespace="Example.com", name="Person")
> public class Person{
>
> @JsProperty(name = "name")
> public String name;
> @JsProperty(name = "age")
> public int age;
>
> private Map animals; //an extra property that is
> not found in javascript
>
> public native boolean isOld();
>
> @JsOverlay
> public final void buyAnimal(Animal animal){ // I don't know if it
> matters, but Animal object is also native as Person
> String animalName = animal.getName();
> animals.put(animalName, animal); // this fails with
> "this.static$.animals.put is not a function"
> }
> }
>
> The above code works fine when using beta1.
> Is there some documentation related to differences between rc1 and
> beta1(at least related to jsinterop)?
> *What other changes should I make when moving to rc1?*
>
> My pom file contains:
> ...
> 
> ...
> 1.8
> 2.8.0-rc1
> 2.8.0-SNAPSHOT version>
> 1.0.0-SNAPSHOT
> ...
> 
> ...
> 
> org.codehaus.mojo
> gwt-maven-plugin
> ${gwt.maven.plugin.version}
> 
> ${java.version}
> ${java.version}
> true
> ${gwt.style}
>
> -Xmx2048m -Xss1024k -XX:MaxPermSize=256m
> ${webappDirectory}
> ${superDevMode}
> true
> ...
> ...
> htmlunit
> 
> 
> 
> compile
> 
> compile
> 
> 
> 
> run
> 
> run
> 
> 
> 
> test
> 
> test
> 
> 
> **/GwtTestSuite*.java
> 
> 
> 
> 
> ...
> 
> ...
> 
> 
> com.google.gwt
> gwt-servlet
> 
> 
> com.google.gwt
> gwt-user
> provided
> 
> 
> com.google.gwt
> gwt-dev
> provided
> 
> 
> com.google.gwt
> gwt-codeserver
> provided
> 
> ...
> 
> ...
>
> Thank you,
>
> --
> 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/0d7bb6ac-a184-
> 4c55-a6f0-f09af725a82a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

Can you share a small repro for this? (EventListener requiring
generateJsInteropExports)

On Thu, Jul 28, 2016 at 12:27 AM, Steve Andrews 
wrote:

> I've done some more testing and cleared my cache and can still only get
> EventListener to work with the generateJsInteropExports flag set.
>
> I've had another problem with EventListener on a select element but I'm
> using an external framework for my project (Materialize) and think that
> it's their framework that doesn't like the EventListener object. If I use a
> standard select element then it's working. I can get around this by adding
> the listener through a JQuery wrapper so no problem.
>
> I've also found that Window.location returns an Object - will this be
> sorted in a future release?
>
> Other than that Elemental is working well so far! Nice work!
>
> Steve
>
> On Friday, 22 July 2016 11:31:24 UTC+1, Jens wrote:
>>
>>
>> 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/16498b97-7d3d-44c7-b42b-e40be9de1e26%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Experimental release of Elemental2

['Goktug Gokdogan' via GWT Contributors]

We will look into that.

On Sat, Jul 2, 2016 at 6:13 PM, Paul Stockley  wrote:

> Would it be possible to break the project into a few packages? It would
> make it easier to find things.
>
> --
> 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/127fd7d4-56ab-407e-9981-1da8d2d91a91%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

Elemental2 currently purely driven by the JavaScript extern files. So it is
not trivial. Maybe a later version could include some kind of type
extension.
For now perhaps we can improve the generated code to use generics so you
don't need to cast but we cannot modify the API.

On Sat, Jul 2, 2016 at 2:07 PM, Manuel Carrasco Moñino <man...@apache.org>
wrote:

> I'm wondering if it would be possible to have type-safe convenience
> methods for creating elements, so as the user does not have to provide the
> string tag name, nor cast the object, maybe something like :
>
> HTMLButtonElement button = HTMLButtonElement.createElement();
>
> instead of
>
> HTMLButtonElement button = (HTMLButtonElement)
> document.createElement("button");
>
>
>
> El sáb., 2 jul. 2016 a las 4:38, 'Goktug Gokdogan' via GWT Contributors (<
> google-web-toolkit-contributors@googlegroups.com>) escribió:
>
>> Closure extern definition uses a union type here:
>>
>> https://github.com/google/closure-compiler/blob/master/externs/browser/w3c_event.js#L34
>>
>> So it accepts either EventListener interface or a function.
>>
>> When we see a union type, we generate overloads for each type so
>> Elemental should provide overloads that includes both. And it seems like it
>> does. If not please let us know.
>>
>> On Fri, Jul 1, 2016 at 3:39 AM, Jens <jens.nehlme...@gmail.com> wrote:
>>
>>>
>>> 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
>>> <https://developer.mozilla.org/en-US/docs/Web/API/Event> interface) when an
>>> event of the specified type occurs. This must be an object implementing the
>>> EventListener
>>> <https://developer.mozilla.org/en-US/docs/Web/API/EventListener> interface,
>>> or simply a JavaScript function
>>> <https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Functions>.*
>>>
>>> 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
>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/73b36bdb-c496-4768-a221-21fe8b5a437c%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0ZfCbS%2Bnwtre0QuAnhDdLYz%2B3LuzXqD3WqoWqK%3DFe%2BEg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0ZfCbS%2Bnwtre0QuAnhDdLYz%2B3LuzXqD3WqoWqK%3DFe%2BEg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-cont

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

['Goktug Gokdogan' via GWT Contributors]

Closure extern definition uses a union type here:
https://github.com/google/closure-compiler/blob/master/externs/browser/w3c_event.js#L34

So it accepts either EventListener interface or a function.

When we see a union type, we generate overloads for each type so Elemental
should provide overloads that includes both. And it seems like it does. If
not please let us know.

On Fri, Jul 1, 2016 at 3:39 AM, Jens  wrote:

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

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

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

['Goktug Gokdogan' via GWT Contributors]

On Thu, Jun 30, 2016 at 11:42 PM, Ignacio Baca Moreno-Torres <
igna...@bacamt.com> wrote:

> Yep, not sure why... but I just try again and the parameter is used
> correctly by the codeserver, so it works as you said. When you said 'you
> are implementing a native JsType' you are talking about the JsFunction
> callbacks, isn't it?
>

No, I'm talking about JsType(isNative=true). The lambda in your code
implements EventListener which is a native JsType interface; not a
JsFunction.



> The issue said 'do not honor' so looks like the opposite direction (I
> mean, 'do not honor' is what is happening before issue is fixed or what
> should happen after the issue is fixed).
>

Yes, the patch description is not accurate. It stops honoring non-native
JsType names in SDM to detect missing flag early on. In addition to that,
it also makes sure that if you are implementing  a native JsType, it works
with or without the flag. The description doesn't capture this part.


> To confirm, will this issue make this native JsFunction callbacks works
> without the export flag?
>
>
JsFunction implementations already work with or without the flag. The patch
will also make sure native JsType implementations to work with or without
the flag.
So if you are using elemental, you won't need the flag (more common).
If you are exporting a Java API to be used by some JavaScript, you will
need the flag (less common).



> On Friday, July 1, 2016 at 12:16:34 AM UTC+2, Goktug Gokdogan wrote:
>>
>> You are probably missing the flag.
>> In this particular situation you are implementing a native JsType and
>> that is considered a form exporting in current compiler and hence affected
>> by the flag. I know that is surprising and it will be fixed in
>> https://gwt-review.googlesource.com/#/c/15193/ (which will be submitted
>> before the final release).
>>
>> On Thu, Jun 30, 2016 at 3:03 PM, Ignacio Baca Moreno-Torres <
>> ign...@bacamt.com> wrote:
>>
>>> I just applied elemental2 to this simple drang and FileReader
>>> showcase (
>>> https://github.com/ibaca/dndfiles-gwt/blob/master/src/main/java/dndfiles/client/DndFiles.java).
>>> Elemental2 looks good, but I think that JsInterop still a bit...
>>> unpredictable. The project compiles correctly, but the codeserver fails,
>>> pruning/ignoring some methods. Or maybe I do not set the
>>> generateJsInteropExports correctly... not sure, but even if this is the
>>> problem, I'm still confusing why I need this flag if I'm not exporting
>>> anything. If I do not set this flag, the project do not work (some lambdas
>>> are pruned).
>>>
>>> On Thursday, June 30, 2016 at 8:21:55 PM UTC+2, Ray Cromwell wrote:

 should be able to make this a little tighter:

 button.addEventListener("click", (evt) -> {
 button.parentNode.removeChild(button); alert("Button has been
 removed."); });

 :)


 On Thu, Jun 30, 2016 at 4:16 AM, Julien Dramaix
  wrote:
 > I'll try to find some time next week for uploading examples on my
 github
 > account.
 >
 > A simple example could be:
 >
 > package elemental.sample.simple;
 >
 > import static elemental2.Global.alert;
 > import static elemental2.Global.document;
 >
 > import com.google.gwt.core.client.EntryPoint;
 >
 > import elemental2.Event;
 > import elemental2.EventListener;
 > import elemental2.HTMLButtonElement;
 >
 > public class SimpleApp implements EntryPoint{
 >   public void onModuleLoad() {
 > final HTMLButtonElement button = (HTMLButtonElement)
 > document.createElement("button");
 > button.textContent = "Click me";
 > button.addEventListener(
 > "click",
 > new EventListener() {
 >   @Override
 >   public void handleEvent(Event evt) {
 > button.parentNode.removeChild(button);
 > alert("Button has been removed.");
 >   }
 > });
 > document.body.appendChild(button);
 >   }
 > }
 >
 > Elemental2.Global can be considered as the entry point of the
 library. It
 > gathers all methods/fields available from the global scope (but not
 the
 > window API).
 >
 > On Thu, Jun 30, 2016 at 12:15 PM Matic Petek 
 wrote:
 >>
 >> Hi,
 >>   I would be nice If you could publish simple example how to start
 using
 >> it.
 >> Regards,
 >>Matic
 >>
 >> On Thursday, June 30, 2016 at 2:23:51 AM UTC+2, Julien Dramaix
 wrote:
 >>>
 >>> A new experimental version of Elemental2 using the new JsInterop
 >>> specification has been pushed on Sonatype today.
 >>>
 >>>
 >>> You can try it by downloading the jar file or adding this following
 maven
 >>> dependency:
 >>>
 >>>
 >>> 
 >>>
 >>>  com.google.gwt
 >>>
 >>>  elemental2-experimental
 >>>
 

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

['Goktug Gokdogan' via GWT Contributors]

You are probably missing the flag.
In this particular situation you are implementing a native JsType and that
is considered a form exporting in current compiler and hence affected by
the flag. I know that is surprising and it will be fixed in
https://gwt-review.googlesource.com/#/c/15193/ (which will be submitted
before the final release).

On Thu, Jun 30, 2016 at 3:03 PM, Ignacio Baca Moreno-Torres <
igna...@bacamt.com> wrote:

> I just applied elemental2 to this simple drang and FileReader
> showcase (
> https://github.com/ibaca/dndfiles-gwt/blob/master/src/main/java/dndfiles/client/DndFiles.java).
> Elemental2 looks good, but I think that JsInterop still a bit...
> unpredictable. The project compiles correctly, but the codeserver fails,
> pruning/ignoring some methods. Or maybe I do not set the
> generateJsInteropExports correctly... not sure, but even if this is the
> problem, I'm still confusing why I need this flag if I'm not exporting
> anything. If I do not set this flag, the project do not work (some lambdas
> are pruned).
>
> On Thursday, June 30, 2016 at 8:21:55 PM UTC+2, Ray Cromwell wrote:
>>
>> should be able to make this a little tighter:
>>
>> button.addEventListener("click", (evt) -> {
>> button.parentNode.removeChild(button); alert("Button has been
>> removed."); });
>>
>> :)
>>
>>
>> On Thu, Jun 30, 2016 at 4:16 AM, Julien Dramaix
>>  wrote:
>> > I'll try to find some time next week for uploading examples on my
>> github
>> > account.
>> >
>> > A simple example could be:
>> >
>> > package elemental.sample.simple;
>> >
>> > import static elemental2.Global.alert;
>> > import static elemental2.Global.document;
>> >
>> > import com.google.gwt.core.client.EntryPoint;
>> >
>> > import elemental2.Event;
>> > import elemental2.EventListener;
>> > import elemental2.HTMLButtonElement;
>> >
>> > public class SimpleApp implements EntryPoint{
>> >   public void onModuleLoad() {
>> > final HTMLButtonElement button = (HTMLButtonElement)
>> > document.createElement("button");
>> > button.textContent = "Click me";
>> > button.addEventListener(
>> > "click",
>> > new EventListener() {
>> >   @Override
>> >   public void handleEvent(Event evt) {
>> > button.parentNode.removeChild(button);
>> > alert("Button has been removed.");
>> >   }
>> > });
>> > document.body.appendChild(button);
>> >   }
>> > }
>> >
>> > Elemental2.Global can be considered as the entry point of the library.
>> It
>> > gathers all methods/fields available from the global scope (but not the
>> > window API).
>> >
>> > On Thu, Jun 30, 2016 at 12:15 PM Matic Petek 
>> wrote:
>> >>
>> >> Hi,
>> >>   I would be nice If you could publish simple example how to start
>> using
>> >> it.
>> >> Regards,
>> >>Matic
>> >>
>> >> On Thursday, June 30, 2016 at 2:23:51 AM UTC+2, Julien Dramaix wrote:
>> >>>
>> >>> A new experimental version of Elemental2 using the new JsInterop
>> >>> specification has been pushed on Sonatype today.
>> >>>
>> >>>
>> >>> You can try it by downloading the jar file or adding this following
>> maven
>> >>> dependency:
>> >>>
>> >>>
>> >>> 
>> >>>
>> >>>  com.google.gwt
>> >>>
>> >>>  elemental2-experimental
>> >>>
>> >>>  16-06-30
>> >>>
>> >>> 
>> >>>
>> >>>
>> >>> Then, inherits the elemental2 module:
>> >>>
>> >>>
>> >>> 
>> >>>
>> >>>
>> >>> This experimental version works only with the last 2.8-snapshot
>> release
>> >>> of GWT.
>> >>>
>> >>>
>> >>> The goal of this release is to get feedback so don’t hesitate to
>> report
>> >>> any bugs, issues, concerns you have on this mailing list.
>> >>>
>> >>>
>> >>> Important note: This is an experimental release and without doubt the
>> >>> future updates until the final release are going to break code!
>> >>>
>> >>>
>> >>> - Julien
>> >>>
>> >>>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "GWT Contributors" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an
>> >> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>
>> >> To view this discussion on the web visit
>> >>
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%40googlegroups.com.
>>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "GWT Contributors" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D5M5DQS--awYZ1bS8nHBu9po8Ne8JPY_ianrUjNZrSqyg%40mail.gmail.com.
>>
>> >
>> > For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this 

Re: [gwt-contrib] Re: Elemental2 - What's the big secret?

['Goktug Gokdogan' via GWT Contributors]

Elemental2 is purely generated; doesn't have handrolled collection/json
APIs. It uses closure extern files so you can investigate what will be
available checking here:

https://github.com/google/closure-compiler/tree/master/externs

On Fri, Jun 17, 2016 at 8:18 AM, Thomas Broyer  wrote:

>
>
> On Friday, June 17, 2016 at 4:15:00 PM UTC+2, Paul Stockley wrote:
>>
>> The question I have is more general. What will the scope of Elemental 2
>> be? Will it include collections and json support like elemental or will it
>> be just an interface to browser API's?
>>
>
> With https://github.com/gwtproject/gwt/issues/9365 (not sure what it
> actually means though, I might be wrong) and
> https://github.com/gwtproject/gwt/issues/9364, I don't think you'd need
> elemental.json anymore (given that String, Double and Boolean directly map
> to JS String, Number and Boolean). The former might also remove the need
> for elemental.util "collections".
>
> --
> 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/43b64e81-7793-45f4-a532-a384ff6a6ece%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

My only issue is Guava emulates stuff like just like mocks but I guess we
can go case by case basic for that.
I will talk to Chris Povirk who is maintaining those.

On Wed, Jun 8, 2016 at 3:04 AM, Jens  wrote:

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

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

Re: [gwt-contrib] Error: cannot extend JsFunction implementation

['Goktug Gokdogan' via GWT Contributors]

Works as intended.

Any form of polymorphism is avoided in JsFunction design so that we could
generate a simple javascript function out of it:
https://gwt-review.googlesource.com/#/c/12810/

On Mon, May 23, 2016 at 10:50 PM, Manuel Carrasco Moñino 
wrote:

>
> Is there any reason why a Class implementing a JsFunction cannot be
> extended or it is a bug?
>
> In the @JsFunction documentation there is nothing about this constrain.
>
> @JsFunction
> interface I {
>   void call(...);
> }
> class A implements I {...}
> class B extends A {...}
>
> [ERROR] : 'A' cannot extend JsFunction implementation 'B'.
>
>
> Thanks
> - Manolo
>
> --
> 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/CAM28XAuQi8iTbWcgUcMLSHOgYKbQqNOhwMAG-tLJFtZkTEqpig%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: Elemental 2?

['Goktug Gokdogan' via GWT Contributors]

Just a correction; we have a prototype generator that allows TypeScript
inputs but currently we are not using TypeScript for generating Elemental.
We instead use Closure externs files that are nicely typed:
https://github.com/google/closure-compiler/tree/master/externs

Generator currently using common ancestor for union types.

On Fri, May 20, 2016 at 7:27 AM, Paul Stockley  wrote:

> It will be interesting to see how using typescript definitions work out.
> From my experience of using them, many leave a lot to be desired from a
> strict typing point of view. A lot of people get lazy and just use 'any'
> everywhere. How will you handle union types? e.g.  string | int |
> someobject | array
>
> I can see them being a good starting point but probably they will require
> manual changes to make user friendly Java API's.
>
>
> On Thursday, November 19, 2015 at 4:39:20 AM UTC-5, Rene Hangstrup Møller
> wrote:
>>
>> Hi
>>
>> A year ago I tried to write a tool for generating JsInterop classes from
>> WebIDL, I abandoned the project because there was no good solution for
>> method overloading and constructors back then. I know others have attempted
>> the same.
>>
>> It looks like the new JsInterop spec solves those problems, so i was
>> considering reviving that project, but I don't want to waste the time if
>> Elemental 2 is going to be released within the next couple of months.
>>
>> I guess it should be possible to release it as a separate project that
>> can be used from GWT 2.8 and the in the far future J2CL.
>>
>> Any chance that Elemental 2 will be available shortly or should I build
>> my own?
>>
>> Best regards
>> Rene
>>
>> --
> 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/c742158a-c87c-4b00-868f-b93a7672a214%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

We cannot impose @JsFunction restrictions on standard library
@FunctionInterfaces. You can see some of the limitations in the Javadoc.

@Colin: I didn't understand your solution. Feel free to propose something
more concrete and we can discuss over that.

On Wed, May 11, 2016 at 4:22 PM, Colin Alworth  wrote:

> Unfortunately, you can't add the annotation to an interface with more than
> one method, even if those methods are default methods, at least as it is
> currently implemented.
>
> I can't remember the exact specifics around why this is the case, but
> believe it has to do with handling functions passed from js into java, and
> not being able to nicely handle instances that decide to override those
> other methods as well.
>
> You could nearly achieve this effect by just making a method reference to
> the "apply" or "test" method, and passing that as an actual JsFunction
> type. I don't right away see a problem with syntactic sugar doing this
> automatically, but am sure that someone will be able to enlighten us as to
> what confusing side effects this might have (or alternately confirm that
> this is a great idea, and point to where in the compiler the changes need
> to be made).
>
>
> On Wed, May 11, 2016, 6:15 PM David Becker 
> wrote:
>
>> I think it would be good to add @JsFunction to all of the
>> java.util.function interfaces in the JRE Emulation so that we can use
>> standard function signatures with JsInterop.
>>
>> Would that work?  Any drawbacks?
>>
>> If you think that's a good idea, I can submit a patch.
>>
>> Thanks!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/13df9bed-108f-4cdf-8c00-123f1186e461%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMzaxRmFrvZUkQMG0VQETyJo5TWmjtFqPsn3msrBBvvLGg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

I can see that most of the new usages (e.g. Optional.java) is incorrect.
Can you guys fix those?

On Mon, May 9, 2016 at 2:12 PM, Goktug Gokdogan  wrote:

>
>
> On Mon, May 9, 2016 at 12:52 PM, Jens  wrote:
>
>> 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.
>>
>>
> That's fair; the way you described actually sounds like a good candidate
> for checkCritical. We already did similar with Arrays.copy to not end of
> with messed up indices.
>
>
>> I guess in some cases its just tough to draw the line.
>>
>>
> Yes, at the end it becomes a judgement call.
>
>
>> -- 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.
>>
>
>

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

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

['Goktug Gokdogan' via GWT Contributors]

On Mon, May 9, 2016 at 12:52 PM, Jens  wrote:

> 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.
>
>
That's fair; the way you described actually sounds like a good candidate
for checkCritical. We already did similar with Arrays.copy to not end of
with messed up indices.


> I guess in some cases its just tough to draw the line.
>
>
Yes, at the end it becomes a judgement call.


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

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

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

['Goktug Gokdogan' via GWT Contributors]

Thanks for asking; I think I never explained this well.

This is mostly judgement call but in general the rule of thumb is:
 - Assume no checks as the starting point
 - Look at the code and see what will happen if we don't have the check:
 - If the missing check will leave the object in a very broken state or
will cause other hard to debug issues, add a critical check.
 - Otherwise, add a regular check.
 - The exception to the rule; adding NPE in cases where it would throw
TypeError anyway doesn't worth the extra check; and not even needed for
J2CL anyway since it will convert them to NPEs.

Keep in mind that; these checks are enabled by default and it is a opt-in
for the apps that are willing trade-off some java semantics and some
debuggability to get extra performance and reduce code size. So they need
to be used sparingly.

If you look at the current examples in JRE, they are only in a handfull
places and there is always a good reason to do that.
For example;
 - Throwable.initCause is using it to prevent self-causation as if we don't
do that then user can create cycle that might cause infinite loops in code
that is processing Throwable; like logging frameworks.
 - Enum does some of the checks with critical; as somebody might use it for
verification (and similar for BigInteger).
 - In LinkedHashMap; the check in iterator is critical because otherwise it
will leave the iterator in a state that will cause infinite loop.


On Mon, May 9, 2016 at 4:22 AM, Jens  wrote:

> 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?
>
>
No actually, meeting JRE contract without much value is a case where we use
regular check vs. critical ones.


> 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?
>
>
Doesn't fit to description above; so checkNotNull is appropriate.


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

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

Re: [gwt-contrib] Creating an Array class using Interop

['Goktug Gokdogan' via GWT Contributors]

Oh sorry. I totally misread. So you are saying if you DON'T set
'jre.checks.checkLevel" to MINIMaL everything works fine? That's very
surprising. You should reproduce the the issue and file a bug.

On Mon, May 2, 2016 at 12:03 PM, Paul Stockley  wrote:

> It wasn't to get around underlying cast problems, just more for code size
> and speed improvements.  I guess the behavior was kind of unexpected in
> SDM. Ideally using  jre.checks.checkLevel mininal  should work in SDM or
> at the very least give an error stating it is incompatible.
>
>
> On Monday, May 2, 2016 at 2:06:08 PM UTC-4, Goktug Gokdogan wrote:
>>
>> If you need to disable cast checking, you are definitely doing something
>> wrong; you should fix underlying problem instead of disabling checks.
>>
>> On Sun, May 1, 2016 at 6:19 AM, Paul Stockley  wrote:
>>
>>> I am trying to create a native JsType to represent a javascript Array.
>>> Up to this point I have been using JSNI. Below is the outline of what I
>>> have. I want to use an Interface as my eventual goal is to be able to
>>> define JSON structures using the same class on client and server.
>>>
>>> @JsType(isNative = true, namespace = JsPackage.GLOBAL, name = "Array")
>>> public interface Array {
>>>
>>>
>>>@JsOverlay
>>>default T get(int index) {
>>>   return JSHelper.getArrayValue(this, index);
>>>
>>>}
>>>
>>>
>>>...Rest of native methods
>>>
>>>
>>> *}*
>>>
>>>
>>> The Helper.getArrayValue method maps to a native function I define outside 
>>> of GWT. I have been trying to track down an error that
>>>
>>> only happened in SDM. When I called the get method, I would get the 
>>> following error:
>>>
>>>
>>>
>>> *ArrayTest.java:14Uncaught ReferenceError: S$c_g$ is not defined*
>>>
>>>
>>> On a side note, tracking down these kind of problems is a real pain given 
>>> that all the function names are obfuscated in SDM.
>>>
>>> I tried -XmethodNameDisplayMode ABBREVIATED. However, this only works for 
>>> methods defined in my modules. Is there another
>>>
>>> way to turn off obfuscation?
>>>
>>>
>>> Anyway, it turns out the problem is the following line I had in may gwt.xml 
>>> file
>>>
>>>
>>> 
>>>
>>>
>>> I had this to strip out cast checking from my final production compile. If 
>>> I remove this, it works fine.
>>>
>>>
>>>
>>> --
>>> 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/26f49d6c-a5fc-4dbe-9f9e-840be96a2f1c%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/ebbf8dd5-3180-4a1f-936b-8118e1679edc%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

A powerful mocking tool. like PowerMock, will let you mock native JsType if
you prefer pure JRE unit tests.

On Sun, May 1, 2016 at 9:55 AM, Thomas Broyer  wrote:

>
>
> On Sunday, May 1, 2016 at 5:46:26 PM UTC+2, Jens wrote:
>>
>> 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.
>>
>
> I think you *have* to run them in prod mode though (this is now the
> default, but in case your gwt.args contains an explicit -devMode, you may
> want to remove it or replace it with -web or -prod)
>
> --
> 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/73974bec-3e59-4b92-8553-004b29069624%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Creating an Array class using Interop

['Goktug Gokdogan' via GWT Contributors]

If you need to disable cast checking, you are definitely doing something
wrong; you should fix underlying problem instead of disabling checks.

On Sun, May 1, 2016 at 6:19 AM, Paul Stockley  wrote:

> I am trying to create a native JsType to represent a javascript Array. Up
> to this point I have been using JSNI. Below is the outline of what I have.
> I want to use an Interface as my eventual goal is to be able to define JSON
> structures using the same class on client and server.
>
> @JsType(isNative = true, namespace = JsPackage.GLOBAL, name = "Array")
> public interface Array {
>
>
>@JsOverlay
>default T get(int index) {
>   return JSHelper.getArrayValue(this, index);
>
>}
>
>
>...Rest of native methods
>
>
> *}*
>
>
> The Helper.getArrayValue method maps to a native function I define outside of 
> GWT. I have been trying to track down an error that
>
> only happened in SDM. When I called the get method, I would get the following 
> error:
>
>
>
> *ArrayTest.java:14Uncaught ReferenceError: S$c_g$ is not defined*
>
>
> On a side note, tracking down these kind of problems is a real pain given 
> that all the function names are obfuscated in SDM.
>
> I tried -XmethodNameDisplayMode ABBREVIATED. However, this only works for 
> methods defined in my modules. Is there another
>
> way to turn off obfuscation?
>
>
> Anyway, it turns out the problem is the following line I had in may gwt.xml 
> file
>
>
> 
>
>
> I had this to strip out cast checking from my final production compile. If I 
> remove this, it works fine.
>
>
>
> --
> 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/26f49d6c-a5fc-4dbe-9f9e-840be96a2f1c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

['Goktug Gokdogan' via GWT Contributors]

I think creating a new project is a good opportunity to start bundling
things out of GWT-SDK as agreed on in the initial roadmap.

On Thu, Apr 28, 2016 at 12:27 AM, Thomas Broyer  wrote:

> No need to create a new project; that can live in GWT proper BUT will only
> be supported by community members (i.e. not Google)
>
> --
> 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/ad848b18-5451-4b7f-9c8f-bb58b86a9b81%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: JsInterop is pruning non readed properties

['Goktug Gokdogan' via GWT Contributors]

No, some "shared" libraries uses non-native JsType and passing the flag
stopping from being pruned for the majority of the apps who doesn't care.

On Fri, Apr 15, 2016 at 6:13 AM, Paul Stockley  wrote:

> So are you saying they are using just JsType=native interfaces and the
> export flag is stopping these from being pruned?
>
>
> On Wednesday, April 13, 2016 at 11:55:58 AM UTC-4, Goktug Gokdogan wrote:
>>
>> Unfortunately, that is not true. A lot of people just need to deal with
>> native types without any need for exporting their own types to JavaScript
>> and shared libraries will start accumulating unnecessary code for all of
>> them if it is enabled by default. We have already seen this Google.
>> Actually more proper solution is to have "--generateJsInteropExports
>> " and let every app choose their own subset but I don't
>> have time to implement it and took the shortcut for the
>> "--generateJsInteropExports " case.
>>
>> On Wed, Apr 13, 2016 at 6:16 AM, Paul Stockley 
>> wrote:
>>
>>> I agree that if you disable exports you can run into the same problem.
>>> However, I would guess most GWT users would have no reason to turn it off
>>> and in that case it would be consistent. It seems more an optimization for
>>> a use case most people won't have.
>>>
>>>
>>> On Tuesday, April 12, 2016 at 12:51:12 PM UTC-4, Goktug Gokdogan wrote:

 Changing the default will not solve the SDM vs Prod problem (i.e. what
 if I disabled it?). The default is sub-optimal but helps in the grand
 scheme of things (There is a comment thread in the Doc discussing why the
 default is chosen in the current way).

 SDM already doesn't export members to Global object if the flag is not
 enabled. IIRC, it will also prune some unused Object instance members but
 that's not aggressive for performance reasons but also not enough since you
 might have a reference from Java code. I'm open to any suggestions.

 On Tue, Apr 12, 2016 at 9:10 AM, Paul Stockley 
 wrote:

> I think this flag in its current form is evil. If you forget it your
> code will work in SDM and not in production. I would recommend one of the
> following:
>
> 1) Have export on by default and have a flag to turn it off
> 2) or have SDM prune the non-exported classes from the code.
>
>
> On Tuesday, April 12, 2016 at 11:48:11 AM UTC-4, Ignacio Baca
> Moreno-Torres wrote:
>>
>> Compiled using 2.8.0-SNAPSHOT and without -generateJsInteropExports.
>> With -generateJsInteropExport works! (i.e.: Foo.bar field is not
>> pruned)
>>
>> On Tuesday, April 12, 2016 at 3:57:10 PM UTC+2, Ignacio Baca
>> Moreno-Torres wrote:
>>>
>>> This code:
>>> public class Client implements EntryPoint {
>>> Console log = Browser.getWindow().getConsole();
>>>
>>> @Override public void onModuleLoad() {
>>> Foo foo = new Foo();
>>> foo.bar = 666;
>>> log.log(foo);
>>> }
>>>
>>> @JsType public static class Foo {
>>> public int bar;
>>> }
>>> }
>>>
>>>
>>> Generate this js:
>>> function $onModuleLoad(this$static){
>>>   var foo;
>>>   foo = new Client$Foo;
>>>   $log(this$static.log_0, foo);
>>> }
>>>
>>>
>>> I.e.: the Foo.bar var is pruned. This makes this common case (IMHO)
>>> fail silently (an empty object is sent to the server):
>>>
>>> Foo f = new Foo(); f.bar=666; request.send(f);
>>>
>>> This can be fixed using isNative=true, which might be ok, but the
>>> important thing is that this code fails silently which is really 
>>> annoying.
>>> Thanks.
>>>
>>> --
> You received this message because you are subscribed to the Google
> Groups "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
> google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/a8fed9ee-8137-478d-92e7-1fe5ba1a7409%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

 --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/7ff73ac6-fbcc-47ad-8878-874b00191912%40googlegroups.com
>>> 

Re: [gwt-contrib] Re: JsInterop is pruning non readed properties

['Goktug Gokdogan' via GWT Contributors]

Unfortunately, that is not true. A lot of people just need to deal with
native types without any need for exporting their own types to JavaScript
and shared libraries will start accumulating unnecessary code for all of
them if it is enabled by default. We have already seen this Google.
Actually more proper solution is to have "--generateJsInteropExports
" and let every app choose their own subset but I don't
have time to implement it and took the shortcut for the
"--generateJsInteropExports " case.

On Wed, Apr 13, 2016 at 6:16 AM, Paul Stockley  wrote:

> I agree that if you disable exports you can run into the same problem.
> However, I would guess most GWT users would have no reason to turn it off
> and in that case it would be consistent. It seems more an optimization for
> a use case most people won't have.
>
>
> On Tuesday, April 12, 2016 at 12:51:12 PM UTC-4, Goktug Gokdogan wrote:
>>
>> Changing the default will not solve the SDM vs Prod problem (i.e. what if
>> I disabled it?). The default is sub-optimal but helps in the grand scheme
>> of things (There is a comment thread in the Doc discussing why the default
>> is chosen in the current way).
>>
>> SDM already doesn't export members to Global object if the flag is not
>> enabled. IIRC, it will also prune some unused Object instance members but
>> that's not aggressive for performance reasons but also not enough since you
>> might have a reference from Java code. I'm open to any suggestions.
>>
>> On Tue, Apr 12, 2016 at 9:10 AM, Paul Stockley 
>> wrote:
>>
>>> I think this flag in its current form is evil. If you forget it your
>>> code will work in SDM and not in production. I would recommend one of the
>>> following:
>>>
>>> 1) Have export on by default and have a flag to turn it off
>>> 2) or have SDM prune the non-exported classes from the code.
>>>
>>>
>>> On Tuesday, April 12, 2016 at 11:48:11 AM UTC-4, Ignacio Baca
>>> Moreno-Torres wrote:

 Compiled using 2.8.0-SNAPSHOT and without -generateJsInteropExports.
 With -generateJsInteropExport works! (i.e.: Foo.bar field is not pruned)

 On Tuesday, April 12, 2016 at 3:57:10 PM UTC+2, Ignacio Baca
 Moreno-Torres wrote:
>
> This code:
> public class Client implements EntryPoint {
> Console log = Browser.getWindow().getConsole();
>
> @Override public void onModuleLoad() {
> Foo foo = new Foo();
> foo.bar = 666;
> log.log(foo);
> }
>
> @JsType public static class Foo {
> public int bar;
> }
> }
>
>
> Generate this js:
> function $onModuleLoad(this$static){
>   var foo;
>   foo = new Client$Foo;
>   $log(this$static.log_0, foo);
> }
>
>
> I.e.: the Foo.bar var is pruned. This makes this common case (IMHO)
> fail silently (an empty object is sent to the server):
>
> Foo f = new Foo(); f.bar=666; request.send(f);
>
> This can be fixed using isNative=true, which might be ok, but the
> important thing is that this code fails silently which is really annoying.
> Thanks.
>
> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/a8fed9ee-8137-478d-92e7-1fe5ba1a7409%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/7ff73ac6-fbcc-47ad-8878-874b00191912%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: JsInterop is pruning non readed properties

['Goktug Gokdogan' via GWT Contributors]

Changing the default will not solve the SDM vs Prod problem (i.e. what if I
disabled it?). The default is sub-optimal but helps in the grand scheme of
things (There is a comment thread in the Doc discussing why the default is
chosen in the current way).

SDM already doesn't export members to Global object if the flag is not
enabled. IIRC, it will also prune some unused Object instance members but
that's not aggressive for performance reasons but also not enough since you
might have a reference from Java code. I'm open to any suggestions.

On Tue, Apr 12, 2016 at 9:10 AM, Paul Stockley  wrote:

> I think this flag in its current form is evil. If you forget it your code
> will work in SDM and not in production. I would recommend one of the
> following:
>
> 1) Have export on by default and have a flag to turn it off
> 2) or have SDM prune the non-exported classes from the code.
>
>
> On Tuesday, April 12, 2016 at 11:48:11 AM UTC-4, Ignacio Baca
> Moreno-Torres wrote:
>>
>> Compiled using 2.8.0-SNAPSHOT and without -generateJsInteropExports.
>> With -generateJsInteropExport works! (i.e.: Foo.bar field is not pruned)
>>
>> On Tuesday, April 12, 2016 at 3:57:10 PM UTC+2, Ignacio Baca
>> Moreno-Torres wrote:
>>>
>>> This code:
>>> public class Client implements EntryPoint {
>>> Console log = Browser.getWindow().getConsole();
>>>
>>> @Override public void onModuleLoad() {
>>> Foo foo = new Foo();
>>> foo.bar = 666;
>>> log.log(foo);
>>> }
>>>
>>> @JsType public static class Foo {
>>> public int bar;
>>> }
>>> }
>>>
>>>
>>> Generate this js:
>>> function $onModuleLoad(this$static){
>>>   var foo;
>>>   foo = new Client$Foo;
>>>   $log(this$static.log_0, foo);
>>> }
>>>
>>>
>>> I.e.: the Foo.bar var is pruned. This makes this common case (IMHO)
>>> fail silently (an empty object is sent to the server):
>>>
>>> Foo f = new Foo(); f.bar=666; request.send(f);
>>>
>>> This can be fixed using isNative=true, which might be ok, but the
>>> important thing is that this code fails silently which is really annoying.
>>> Thanks.
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/a8fed9ee-8137-478d-92e7-1fe5ba1a7409%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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