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
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
(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.
>
>
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
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
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
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.
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
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
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
.
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
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
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
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
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
-- 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
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:
>>
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
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
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
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
*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
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
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
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
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.
&
, 2018 at 2:21 PM Nándor Előd Fekete <nandor.fek...@gmail.com>
> 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
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.
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 n
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-
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
+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
; 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.
>&
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
+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.
>
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
*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 <gok...@google.com> wrote:
> @Harald:
> JsPropertMap obj.set("key0", "value");
> obj.set(
@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
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
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,
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
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
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 w
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
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
>
> 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 &
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
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 expect
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
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.
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:
>
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,
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
ay 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 rele
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
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
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
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
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);
> }
>
>
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
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
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
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
+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,
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
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
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:
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
I think you misinterpreted "overhead to make it available outside".
On Tue, Oct 11, 2016 at 6:38 PM, Alex White <alexwhite3...@gmail.com> wrote:
> On Wednesday, October 12, 2016 at 9:59:40 AM UTC+10, Goktug Gokdogan wrote:
>>
>> Elemental 2 is based on a generator
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
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
, 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 <go
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
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.
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
>&
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
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
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.
>
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
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
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
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
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
. 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:
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
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
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
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
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
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
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 <gok...@google.com> wrote:
>
>
> On Mon, May 9, 2016 at 12:52 PM, Jens <jens.nehlme...@gmail.com> wrote:
>
>> Hm ok, I
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
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
> 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 Sto
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
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
>
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
e=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 expo
; 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 threa
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 - 100 of 713 matches
Mail list logo