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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

Re: [gwt-contrib] GWT Java7 support

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

[gwt-contrib] GWT Java7 support

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [gwt-contrib] Update on J2CL

tug 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: >>

Re: [gwt-contrib] Update on J2CL

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

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

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

Re: [gwt-contrib] Union types hack

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

Re: [gwt-contrib] Update on J2CL

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 sin

[gwt-contrib] Update on J2CL

*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

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

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

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

r 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

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

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

Re: [gwt-contrib] The elusive J2CL

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

Re: [gwt-contrib] The elusive J2CL

> 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

Re: [gwt-contrib] The elusive J2CL

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.

Re: [gwt-contrib] JUnit tests without Generators

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

Re: [gwt-contrib] JUnit tests without Generators

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

Re: [gwt-contrib] JUnit tests without Generators

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

Re: [gwt-contrib] JUnit tests without Generators

+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

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

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

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

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

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

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

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

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

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

*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); >

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

@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

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

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

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

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,

Re: [gwt-contrib] GWT 2.8.2 release

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

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

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

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

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

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

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

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

read_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

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

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

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

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

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

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

Re: [gwt-contrib] Re: Java 9

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

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

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.

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

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

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

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,

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [gwt-contrib] Re: Utils

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:

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

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

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

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

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

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

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

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

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

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 >

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

gt;> 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

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

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.

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

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

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

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

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

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

Re: [gwt-contrib] Experimental release of Elemental2

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

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

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

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

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

Re: [gwt-contrib] Experimental release of Elemental2

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

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

LButtonElement 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-we

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

  1   2   3   >