Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?
On Wed, May 24, 2017 at 1:14 AM, Learner Evermore < learner.everm...@gmail.com> wrote: > ... continuing the above - there is more. Let's now come back to the > analysis part. Yes, it is possible to do the "whole-world analysis" outside > the compiler. But what perspective should the analysis take? It is > irrelevant if it cannot reduce the number of possible classes - we don't > want all of Java runtime library in there, for example. We need to discover > which parts are needed from the code that *could* be executed. GWT > determines this based on entry points and other configuration in the > *.gwt.xml files **and** what it finds in the compilation classpath, as > configured, including its own version of the standard library. So, the > pre-compilation analysis tool would have to configured exactly the same and > process exactly the same configuration as the GWT compilation step. This > would have to evolve in lockstep with GWT. It would also be doing the same > processing and analysis that GWT already has to do - at least the step of > deciding which bits of code to convert to JavaScript before any further > optimization. > My point is simply if the Java->JS compiler is moving to separate compilation, having hooks in it cannot help you if the things you want require whole-world analysis. If the reachability analysis is done at a later "linking" stage, then clearly that cannot be available at the compilation stage. So I think what you want is fundamentally incompatible with the separate compilation direction. That means that either GWT3 is not for you or you will have to build an external tool that basically does much of what the existing GWT compiler does now to get what you want. -- John A. Tamplin -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X-4sYX9-_rYTsQhB%2B1O%2Bc44iKyeJTGO84f7rakCmBkitQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?
On Tue, May 23, 2017 at 8:24 PM, Learner Evermore < learner.everm...@gmail.com> wrote: > And again, I for one, am not calling for GWT RPC to be resurrected in 3.0. > I don't need it. But I do need the complete serialization instead of the > half-baked, mostly-incapable external frameworks > needing-a-ton-of-extra-code-and-still-can't-do-it in existence today. And > I can even code that to work much faster than GWT RPC did (I do stuff like > that all the time) but it isn't possible without dedicated hooks within > J2CL. > Why is that so? Can't you do your own whole-world analysis pass independently of the compiler if that is what you want to do? It does not seem possible to have whole-world analysis in the compiler (hooks or not) if the goal is to enable separate compilation at the Java layer. So, if that is important to you, it must necessarily be outside the compiler. -- John A. Tamplin -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X8PsyPWaL3hHFjbMq5Xgve-7up6QWwX3xbr1jrVMWqhoQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] GWT and Bazel
On Fri, Apr 3, 2015 at 6:00 PM, Erik Kuefler ekuef...@gmail.com wrote: Is Google planning on releasing GWT rules for Bazel http://bazel.io/ any time soon, or is there anyone external who's working on putting together some general-purpose rules? I've hacked together a couple for my use cases that might be reasonable starting points if not, though there's still a lot that would need to be cleaned up for them to work more generally. I'm not sure why they didn't release them, since their are certainly BUILD rules in Google's internal system for GWT. Maybe they will come in a later update. -- John A. Tamplin -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X81MFP9mQ3ZJ%2BYg07%2BvkSrr2C3t3tqoVGntqMYrr9Zvqw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Java8 emulation
On Wed, Mar 25, 2015 at 11:33 AM, Colin Alworth niloc...@gmail.com wrote: The trick seems to be that it is not going to be possible to add Java8 emul code without actually using Java8 - while lambdas can be avoided, defender methods cannot. If you need to provide a new interface like Consumer, the supersource *must* have the `default` method(s), or it won't actually be Consumer. If it were just those types, it would be possible to move them into their own module so developers would need to inherit's the Java8 module to get access to them, but the Collection interface itself needs to be changed to add `default StreamE stream()`, plus the implementation, or else all implementors of Collection (and Set and List) need to have an implementation added. Even then, Stream would need to be emulated, which references Consumer, so we can't have it be a separate module... ...or am I over-complicating matters? Well, certainly there are things which will require further support in GWT and in the build, but things like adding j.u.Optional can be done without that. -- John A. Tamplin -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X_k%2BwvoH_a_YquYcxY-uzbL%3DdANNn5eGZZJUombafbKBA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Java8 emulation
On Wed, Mar 25, 2015 at 11:16 AM, Jens jens.nehlme...@gmail.com wrote: whats the current situation of adding Java8 emulations to GWT? I would like to fix the current emulation of @FunctionalInterface (wrong package and missing imports), add java.util.Optional[Int|Long|Double] emulation and like to see java.util.function interfaces in trunk committed. That would allow us to further work on stream API emulation which would be nice to have in GWT 2.8, right? Just having Java8 syntax support seems a little weak to me for a new release. Adding new classes should be pretty straightforward. Currently my patch for java.util.function can not be verified by Jenkins because it runs the presubmit task with sourceLevel 1.7 (and Java7 I think). So I assume that the next GWT release should be compatible to Java7. Does this mean that any emulation of Java8 APIs should be done using Java7 syntax ( = no lambdas in emulation code) ? What about default methods in emulated code when people use JDK 7 with GWT? That would be my vote - we don't want to force people to use Java8 just yet. -- John A. Tamplin -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X-xtnTX_xXPPr4M9AsFP_qNQHZU_9k_VJP5o4ZjLYknWw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] SafeHtml on the server/vm
On Mon, Jun 9, 2014 at 6:33 PM, Colin Alworth niloc...@gmail.com wrote: Currently SafeHtml co live in gwt-user, though they are for the most part listed in a shared package, implying that a server can use them. However, gwt-user.jar also includes javax packages as well as hibernate, w3c, etc, so can't reasonably be imported to a server which already uses any of those packages (i.e. any servlet container). Is this an oversight in the publicly packaged GWT and is SafeHtml used by teams that package differently, or instead is this package not actually intended for server use, but instead just compile-time tasks where gwt-user is on the classpath like compiling or linking? I'm doing some work on a non-servlet server which hasn't so far seen concrete issues with gwt-user.jar, and having SafeHtml seemed to be an easy way to get server generated HTML from code that is shared with the client. This use case *appears* to be implied from the package name, but presently isn't possible for the majority of GWT backends. Ideas on why it is the way it is? Thoughts on how to make it available to the server (without giving it yet another jar a la requestfactory-server)? Interest in a contributed SafeHtmlTemplates implementation for JVM? Yes, SafeHtml is intended to be usable on the server. There have been various discussions about splitting up gwt-user into parts for client-only, shared (and perhaps server-only), but that wasn't ever done. Mostly, putting gwt-user last on the classpath on your server won't cause any issues, though at least one JVM used to be unhappy with native methods without corresponding binaries. -- John A. Tamplin -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X8CHkCjQK1CvGRxwS9H279BKpnZ%3DjeYwuVgqZtj6JJD3w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: who discusses the next features and adopts feature requests?
A more general answer is that in any community project, whoever cares about a feature the most is the one that designs it, convinces others it is worth including, and implements it. Just because something has a lot of votes doesn't automatically mean it will get built -- someone has to be interested enough to make it happen. This was the case even when it was a Google project, but is especially true now that it is fully owned by the community. -- John A. Tamplin -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X-MhbBfYZG7nHHWhG%3DOPhBBU3Cc6FaBV5q374vjV9f0Vg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Emma or JaCoCo support needs some attention
On Tue, May 20, 2014 at 1:12 PM, David david.no...@gmail.com wrote: No I did not try that one. I tried GWT Mockito which looked promising and I actually managed to test a few widgets until someone added CssResources and other GWT features and then GWTMockito just exploded with a generic error that I should try disabling the classloading cache. I am using GIN and I never do a GWT.create directly (GIN does that for you). That helps a lot in testing the higher level classes like Activities. But it does not really help with widgets. (We have some customisations on top of the DataGrid and CellTable and it does not look possible to automate the testing of those. It isn't clear how much you can do widget tests on the server anyway -- the only way I see it would be useful is widgets that clearly delineate the view from the rest of it, and allow you to test the model/controller. If you are talking about testing your own code, then likewise you don't test the view on the server. -- John A. Tamplin -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X9yC%2BSbkdPWwQL6aazdKLDhm3cdHwmUB%2BcZf03vAyKrqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Changes in monthly GWT contributor hangout
On Tue, Apr 22, 2014 at 12:12 PM, Bhaskar Janakiraman bjanakira...@google.com wrote: I didn't see any further requests for discussion, so I'm canceling this month's contributor hangout. For me, doing it during work hours is hard. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] support for JSR 310 / java.time created
On Mon, Nov 25, 2013 at 7:01 PM, Jörg Hohwiller joerg.hohwil...@googlemail.com wrote: Hi there, I posted in GWT community on g+ about my *JSR 310* backport I created and my super-sourced GWT code. Stephen Habermann posted: Wow, 13000 passing tests is amazing. Great work! You should post about your progress on the gwt-contrib list (I am still unsure about when to post to groups and when g+) So here I am. You can find all my work and changes from here: https://github.com/m-m-m/mmm/issues/83 I am looking forward for your feedback and discussion. It will be my pleasure to contribute my work to the GWT project. However, I am not clear about the permissions required from the original authors of threeten since I simply forked their codebase and keept their headers and copyrights in my project. For GWT this has to be transferred and I assume we would need permissions from Stephen Colebourne, Michael Santos and all the others. The BSD-licensed parts shouldn't be any problem to import, but you have a few files with Oracle licenses which aren't going to work. Also, the GWT i18n code will need to be updated to support this as well. There are a few things which are going to be very hard to support As Jens mentioned, ZoneRulesProvider needs an async API so it can fetch the necessary data from a server, so we can't provide a compatible API. We can provide a GWT-specific version (under a different package), so shared code can deal with ZoneRules/etc but getting them will be different in client vs server code. Have you looked at generated code size? There are also a few places where it appears to rely on overflow behavior, which isn't guaranteed in GWT as an int is actually represented by a JS Number under the hood. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: support for JSR 310 / java.time created
On Tue, Nov 26, 2013 at 4:35 AM, Jens jens.nehlme...@gmail.com wrote: Also if you copy the code from Java 8 (which might or might not be the same as the latest JSR 310 code) there should not be any permission issues as it's part of the JRE. I do not believe this is correct - I am pretty sure Oracle's license is incompatible with Apache2 by design. In general GWT does not use any JRE code from Oracle, and instead uses code from Harmony or implements it from scratch. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: support for JSR 310 / java.time created
On Tue, Nov 26, 2013 at 7:47 AM, Jens jens.nehlme...@gmail.com wrote: I do not believe this is correct - I am pretty sure Oracle's license is incompatible with Apache2 by design. In general GWT does not use any JRE code from Oracle, and instead uses code from Harmony or implements it from scratch. Interesting. Glad I am not a lawyer but I am just curious how GWT deals with code that is so easy that you can not implement it differently than Oracle when super sourcing it. Removing/changing JavaDoc is probably not enough to justify changing the license header from x to Google? For example take Cloneable, ClassCastException and similar simple classes/interfaces. IANAL, but my understanding is the API is public so you can always reimplement the API - you just can't use their copyrighted code to do so. The simplicity of the implementation doesn't matter, it is whether you used their source or not. If there is only one reasonable way to implement something, it is harder to show that you copied their code, but if it is 1000 lines of complex code the odds that it would be essentially the same if you didn't copy it are very slim. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] String concatenation
On Wed, Oct 30, 2013 at 4:26 PM, Brian Slesinsky skybr...@google.comwrote: Not a compiler expert, but I wouldn't be surprised since in the AST it will be represented as a binary tree of JBinaryOperation nodes and the visitors walk the tree recursively. So balancing the tree should result in a smaller stack. Right, the issue is that a long run of concatenation resulted in a degenerate tree like concat(a,concat(b,concat(c,...))) and you could blow out the stack on a recursive traversal. I remember discussions about special-casing string concatenation (it seemed unlikely to affect other operators), either into a balanced tree or simply a multi-arg concat operator. I don't know if anything was ever done. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Question about the source: how does GWT builds *.translatable.*, *.emul.*, etc. packages?
On Tue, Oct 22, 2013 at 12:11 PM, Thomas Broyer t.bro...@gmail.com wrote: As far as modularization is concerned, we'd like to have dependencies always in the same direction: rebind-client-shared-server (or rebind-client-server-shared, depending on modules) so we can make a client artifact depending on a server artifact, or a client and server artifacts both depending on a shared artifact (but with no dependency between client and server). In some cases, we'll split packages into distinct artifacts (there are cycles at the package level, but not when looking only at the classes); e.g. c.g.g.user.client (Window, Timer, etc.) c.g.g.resources and c.g.g.junit to have a package not depending on I18N and other things, and another one (or several) with additional dependencies. Why would it be acceptable to have shared code depend on server code? -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Non-client apis and breaking changes
On Fri, Oct 18, 2013 at 5:10 AM, Thomas Broyer t.bro...@gmail.com wrote: This is what the c.g.g.util is for AFAICT, with c.g.g.util.tools.shared being for things usable on server-side (included in gwt-servlet); and as a rule of thumb any class not listed in the javadocs we generate should be considered private. I disagree with that -- I think unless the package includes impl or the name or Javadoc clearly indicates it is an implementation class, any public class should be considered public. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Implement subpixels to support IE10
On Tue, Oct 15, 2013 at 11:13 AM, Matthew Dempsky mdemp...@google.comwrote:
I've been thinking about how we'd cope with this in Google's code base,
and I think we could handle a change-return-type-to-double change
reasonably gracefully. I'd probably tackle it as (glossing over some
logistics):
1. Expose static int toInt32(double x) and probably a static int
toInt32(int x) { return x; } methods in some appropriate utility class.
2. Write an error-prone https://code.google.com/p/error-prone/ check
to warn when elem.getFoo() is used somewhere that a double value wouldn't
be accepted, and recommend using toInt32().
You could make this completely foolproof by introducing an extra step - add
a new wrapper type GwtInt which behaves just like Integer except it isn't
autoboxed. Then have toInt32(GwtInt), and fix all the compile errors to
include that call. Then replace GwtInt with double everywhere.
Now, that is a bit more complicated in a codebase the size of Google's, as
you will have lots of people making changes while this is going on, but as
long as you post about what is going on when they get compile errors they
can do it themselves.
3. Convert all calls to elem.getFoo() into toInt32(elem.getFoo()).
4. Once all warnings have been fixed, we can merge the patch.
5. Turn off the error-prone check.
My only concern at that point would be third-party GWT libraries. If we
exposed the toInt32() method(s) in GWT 2.6 and kept them at least for 3.0,
then it would be possible for GWT libraries to be compatible with GWT 2.6
and 3.0 by using (e.g.) GWT.toInt32(). So that might be worthwhile for us
to consider for 2.6.
Third-party libraries are always going to have hard times supporting
multiple GWT versions. I don't think this issue will be harder than any of
the others they will have to deal with.
--
John A. Tamplin
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Implement subpixels to support IE10
On Tue, Oct 15, 2013 at 11:51 AM, Matthew Dempsky mdemp...@google.comwrote: On Tue, Oct 15, 2013 at 8:18 AM, John A. Tamplin j...@jaet.org wrote: You could make this completely foolproof by introducing an extra step - add a new wrapper type GwtInt which behaves just like Integer except it isn't autoboxed. Then have toInt32(GwtInt), and fix all the compile errors to include that call. Then replace GwtInt with double everywhere. That begs the question though, doesn't it? :) The steps I outlined are how I'd cope with the return type changing from int to double without ever introducing compile errors and without needing to submit any global cleanup changelists. Adding a GwtInt intermediary step means needing to instead cope with converting the return type from int to GwtInt and then again from GwtInt to double, which each seem as hard if not harder than the original problem. No, because you can use foolproof automated refactoring tools. Anyway, just a suggestion if you wanted to replace the error-prone step with two foolproof steps. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
On Tue, Sep 24, 2013 at 10:37 AM, Thomas Broyer t.bro...@gmail.com wrote: It means two things: - replacing our hard-to-maintain Ant-based build (and Maven has the best IDE tooling among build tools) Yeah, I guess that is why I spent half of yesterday getting a build to work in IntelliJ when it worked running from the command line. I have had similar issues with Eclipse before. Maven is great when it works, but you are just SOL when it doesn't. You resort to deleting your .m2/repository, re-importing maven in your IDE, deleting your IDE project and recreating it, etc and (hopefully) it just starts working again and you have superstitions about what actually fixed it (so asking others for advice you get totally different suggestions for how to fix it, none of which actually fix it by themselves). That is before you even get into all the useless work that Maven does, such as downloading stuff to find out there is no work to do. On the contrary, I have never once had an issue with ant, so I have no idea why people say Ant is hard to maintain. YMMV of course. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Thoughts on dropwizard framework as a backend for GWT
On Wed, Aug 28, 2013 at 4:59 AM, Thomas Broyer t.bro...@gmail.com wrote: I like what Square did with Retrofit http://square.github.io/retrofit/, which looks a lot like Errai's JAX-RS. The net advantage of Errai's JAX-RS is that you can simply implement your interface on the server-side and have the annotations inherited from it. AFAICT this is the same as Resteasy's proxy framework: http://docs.jboss.org/resteasy/docs/3.0.2.Final/userguide/html/RESTEasy_Client_Framework.html, so your client interface could be shared by your GWT client, Android client (or anything running in a JVM) and server resource (whether Resteasy or Jersey). Errai's approach to asynchronous calls feels like an ugly hack too: they absolutely wanted to be able to use the exact same interface everywhere, when an async interface could be automatically generated from the synchronous one (e.g. using annotation processors so it works in any IDE and outside IDEs too). Compare that, for example, to gwt-jsonrpc from Gerrit, where everything looks asynchronous (and the server-side could possibly be *made* asynchronous with servlets 3). The problem with all of them (Retrofit, JAX-RS, Errai) is how to configure them (almost everything in Errai shouts “unoptimizable output” though; Errai puts the focus on the developer's productivity when GWT is about optimized JS), particularly how you configure such things like interceptors to inject headers or process error responses (e.g. to handle authentication; probably something similar to the RequestTransport of RequestFactory, or the RpcRequestBuilder of GWT-RPC) and marshallers/unmarshallers; and make that configuration GWT friendly. Maybe we should wait for the GWT.create() changes. Using Retrofit has a similar issue to GWT-RPC -- you want your server-side interface to be synchronous, but your client-side interface to be async. So, I don't see a lot of benefit of being able to use the same interface on the client and server because you don't actually want that. We could certainly have a GWT-RPC-like generator that works with an arbitrary REST API using sync and async interfaces, and we could keep the GWT-specific bits out of the sync interface so that code could easily be shared (even though the generator would just verify that they are compatible). All of these libraries that weren't written with GWT in mind also have the problem of it having a bunch of GWT-incompatible stuff in the jar. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Thoughts on dropwizard framework as a backend for GWT
On Wed, Aug 28, 2013 at 6:04 AM, Thomas Broyer t.bro...@gmail.com wrote: Did I say that?! I see Retrofit as client-only (which I believe it is). That said, I don't think you necessarily want the server-side to be synchronous (it could actually be handy to be asynchronous) Many of the annotations in JAX-RS really only make sense on the server. For example, annotating a parameter with @CookieParam makes little sense on the client. Sure, you could have it set the cookie prior to making the call, but presumably you are using @CookieParam because it is a persistent cookie across calls. @DefaultValue doesn't make any sense on the client, since you have the parameter in the interface so it must be supplied. So, I don't see a lot of benefit of being able to use the same interface on the client and server because you don't actually want that. We could certainly have a GWT-RPC-like generator that works with an arbitrary REST API using sync and async interfaces, and we could keep the GWT-specific bits out of the sync interface so that code could easily be shared (even though the generator would just verify that they are compatible). The problem with not sharing any code is that you have 2 things (at least) to update and maintain in sync. When one can be generated from the other, or both can be generated from a definition in whatever format (e.g. Protocol Buffer), then that's not a problem though. The problem with GWT-RPC is that we don't have anything to generate the async interface form the sync one (the gwt-maven-plugin has some –broken– support, as does the Google Plugin for Eclipse, and possibly the GWT support in IntelliJ and/or NetBeans; but an annotation processor would Just Work™ –OK, most of the time, it kind of sucks in Eclipse– and would work everywhere). I think this could work (you might have an issue figuring out void vs Request returns though). Personally, I don't find writing an Async interface that painful, and I would rather generate it once if I were going to rather than run APT. If you are using protos, you already have a codegen step to deal with anyway. gwt-jsonrpc IMO adopted the most sensible approach without need of a generator: async-everywhere (on the server-side, you don't return the response, instead you give it to the callback; I believe this has to happen synchronously though). I still don't think you want the exact same interface on the client and server - for example, @CookieParams and @DefaultValue as mentioned above. There's also no reason to replicate all those annotations on the client interface -- just referencing the server interface should be enough if it exists (you could probably support arbitrary JAX-RS-like annotations, just matching the annotations without regard to their package). If I am just writing the client side to a third-party REST API, I would rather just write the client-side interface and be done with it, rather than writing the server interface and generating the client. Finally, if you only have one server implementation, having to write an interface for it seems a waste anyway -- just write the server class directly with its annotations, and write a separate async interface for clients (which could be generated). If the client doesn't have something GWT-specific in it, it becomes hard to trigger the right GWT generator for it. You could always make a useless subinterface that inherits from a marker interface to get that, but it is a pain. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Gwt benchmarks without Benchmark
On Mon, Aug 26, 2013 at 1:47 PM, Colin Alworth niloc...@gmail.com wrote: Shortly after 2.5.1, the Benchmark classes were removed from GWT ( https://gwt.googlesource.com/gwt/+/39eb6001a037fd8b6580a73a2540e6e9c04e54c2and https://gwt.googlesource.com/gwt/+/00c7ce43df3a629b7302ab902a07431db7224e2b) - what are folks using for low-level performance testing these days? I'm wrapping up a changeset to emit JS TypedArrays when int[], double[], etc are used in code, and while I can see that some projects clearly improve with this, others seem to take a hit (specifically in rapidly allocating arrays that have a short lifetime). I'd like to record some numbers to paint this picture without rolling my own benchmark/gwtPerf tool, but I'm not quite clear on the current state of this sort of metrics. From the comment that originally deprecated the Benchmark class: This didn't get enough adaption externally or internally. The way it's implemented requires special support from GWTTestCase infrastructure. Also, we are not going have an environment to automate benchmarks written on this any time soon. If there is enough demand later, parts of this code can be resurrected to build a new benchmark system. Thoughts? I argued against removing it at the time, since I found it useful for JRE work in particular. I'm not sure what sort of demand would be required to get it reinstated, but it would probably mean someone taking ownership of it. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Removing GWT sample apps from gwt.google.com/samples/?
On Thu, Aug 22, 2013 at 5:30 PM, Matthew Dempsky mdemp...@google.comwrote: Currently, gwt.google.com/samples/ hosts a bunch of sample apps linked from http://www.gwtproject.org/examples.html. However, it's kind of a pain for us to continue maintaining the custom server that hosts these apps, so we'd like to either move them elsewhere (e.g., App Engine) or just remove them completely. Any thoughts/recommendations on how to proceed? There's actually quite a few more sample apps hosted than the three linked above (e.g., http://gwt.google.com/samples/Hello/Hello.html), but I suspect Showcase, DynaTable, and Mail are the only ones people actually know about / visit. It seems like ideally we create an App Engine app that hosts those three sample apps (or worst case create three App Engine apps, one for each), and then I can map them to samples.gwtproject.org or wherever. They were on GAE at one point -- I don't remember why they were moved though. We definitely need to keep Showcase up and running, but I don't care so much about the rest. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)
On Wed, Aug 21, 2013 at 11:34 AM, Stephen Haberman step...@exigencecorp.com wrote: AFAIK, historically most of the optimizations around incremental compiles have always required going back to building ResourceOracle, TypeOracle from scratch, but speeding it up with caching. The problem is let's say you change file A. How do you know what all needs to be updated in TypeOracle? I am sure you can keep track of it, but it will require keeping much more data than is currently kept so you can incrementally update TypeOracle's data structures. For example, let's say you remove an interface from a class. Even if you walk down the inheritance tree, you can't just remove that interface, because some other ancestor might have implemented it. The same sort of thing goes in many other places. Note that TypeOracle memory requirements has been a problem in the past for large internal apps. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Possible GWT.create() Improvements (link)
On Mon, Aug 12, 2013 at 2:29 AM, Goktug Gokdogan gok...@google.com wrote: An example use-case would be implementing String.format when the format string is a compile-time constant. I had a proof of concept mostly working for this, but it was going to require more surgery to the compiler than I was willing to do at the time. I didn't fully understand the example but it sounds like it requires way more than today's deferred binding so I'm not sure it is a good use case with replace-with/generate-with and static selectors. Perhaps it should be better done with something like evaluate-with instead. Actually, evaluate-with sounds interesting - I'll think about it :) I thought we were talking about potential improvements to GWT.create, so it doesn't have to be something that can be done with today's implementation. Similar motivations were behind some proposals RayC made years ago as well. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Thoughts on dropwizard framework as a backend for GWT
On Sun, Aug 11, 2013 at 2:21 PM, Rafiq Ahamed ra...@eitworks.com wrote: Dear Folks, Any thoughts on DropWizard framework (http://dropwizard.codahale.com/) as a backend for GWT. RESTFUL webservices is the way to go and I feel GWT RPC is an Anti-Pattern. GWT RPC was never intended to be the solution to all problems. It is easy to use and allows you to send entire object graphs without much effort. Of course, you get versioning issues and you can send entire object graphs without much effort. You can already use JSON easily now if you prefer, and protos with a bit more effort. REST vs other options is really more about the server anyway. And also, what about integrating ApacheCouchDB or ApacheSolr (Json style Schema less 4.4 version) as a backend for GWT so that the application can be developed rapidly. This is the approach I have taken for one of my new project. GWT has generally been server-agnostic, so I would expect any server-side integration with a specific framework would be a separate project. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Possible GWT.create() Improvements (link)
On Mon, Aug 12, 2013 at 1:13 AM, Goktug Gokdogan gok...@google.com wrote: Even though the current form is pretty flexible and you can mix and match the two, it doesn't mean it makes sense to do so. I'm having hard time thinking about out a good use case that would make a single complex mix and match more appealing than having a separate group of class replacements and a codegen (AFAIK, there is not even single example in the GWT-SDK itself). Actually separating the two can result in something much more usefulpowerful [*]. An example use-case would be implementing String.format when the format string is a compile-time constant. I had a proof of concept mostly working for this, but it was going to require more surgery to the compiler than I was willing to do at the time. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Possible GWT.create() Improvements (link)
On Fri, Aug 9, 2013 at 7:16 PM, Goktug Gokdogan gok...@google.com wrote: I think in the long-run we should separate the two concepts that is being tackled by GWT.create today. First purpose is the class replacement, especially used by permutations. I think this one should not have anything to do with GWT.create. We can do any class replacement in compiler without requiring a call to GWT.create. This is similar to super-sourcing and can be solved similar and perhaps together. I don't see how it is similar to super-sourcing, as you need to dynamically select which class goes on there. For example, think about implementing GWT.create(SomeLocalizableSubclass). There are hundreds of locales, and different classes are going to have different implementations so you have to make the substitution decision for each one of them separately. Are you proposing to hook new Foo and substituting the class? Where does the compiler get the knowledge to know which class to substitute? I don't think you want to build all the knowledge of the ClientBundle generator into the compiler, for example. Second purpose is for triggering generators and what most of the proposal are about. As Roberto and perhaps others have been bringing up, it is best to follow regular java code generation practices in GWT. That means for the long-term we can mostly rely on AnnotationProcessors. There are many advantages of that: 1. Not GWT only - continue sharing code with server (JRE), client(GWT) and mobile(Android). You can use shared.GWT.create today in all those environments. 2. IDE support: IDE can trigger codegen (esp. for debugging) My experience with this has been pretty poor, and running GWT with -gen is at least as useful. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Possible GWT.create() Improvements (link)
On Sat, Aug 10, 2013 at 2:18 PM, Brian Slesinsky skybr...@google.comwrote: 2. IDE support: IDE can trigger codegen (esp. for debugging) My experience with this has been pretty poor, and running GWT with -gen is at least as useful. Also, Super Dev Mode gives you access to all the generated code. You can either use the browser's debugger with SourceMaps turned on (which also allows you to set breakpoints in generated code), or you can browse the source code directly on the codeserver. It would be nice if we somehow got this working with an IDE, though. I am saying my experience with IDE integration of code generation, whether protoc, APT, etc, has been pretty poor. For example, at work I have taken to running protoc outside the IDE and reimporting it, rather than putting up with the IDE integration. Ie, exactly what I can do with GWT today. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Possible GWT.create() Improvements (link)
On Sat, Aug 10, 2013 at 4:42 PM, Brian Slesinsky skybr...@google.comwrote: Now that I understand it (hopefully), I think Ray's proposal is a good way to define new API's by writing Java wrappers that configure generated objects at runtime. Adding parameters to GWT.create() calls seems somewhat orthogonal as a way to pass arguments to generators at compile time. As often happens with language extensions, when you put them together, things get more complicated but also more expressive; if GWT.create() takes extra arguments then these should also be literals that you can accept in a user-defined create method. It doesn't have to all be literals -- you could imagine that the generator would be able to accept them as constructor arguments for the generated class. Of course, specifying which can be expressions and which must be literals (or things the compiler can compute at compile time, perhaps even inlining calls to get to the literal), and doing that in such a way to get good feedback to the developer isn't trivial. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] JavaScriptObject hasOwnProperty(String)
On Wed, Jul 31, 2013 at 11:03 AM, Patrick Tucker tucker...@gmail.comwrote:
I there any particular reason hasOwnProperty is not in JavaScriptObject?
There are a lot of things that would have made sense to put in JSO
originally (or likewise on Js*), but adding it after the fact breaks anyone
who added a method of that name, as they have to be final.
The best we could do is put a static method that you pass in a JSO and the
key.
It is used throughout GWT and from what I have seen the following would be
the best implementation:
public native boolean hasOwnProperty(String key) /*-{
// In Firefox, jsObject.hasOwnProperty(key) requires a primitive string
key = String(key);
return (this.hasOwnProperty(key)) ? true : false;
}-*/;
Some of the calls, in GWT, cast the key to a string and some don't. Seems
like a standard implementation that is used would be a better plan.
I agree a shared implementation rather than multiple copies would be an
improvement.
--
John A. Tamplin
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
On Wed, Jul 17, 2013 at 4:56 PM, Alex Epshteyn alexander.epsht...@gmail.com wrote: I would like to announce that I have finally solved what I always thought to be GWT's greatest weakness: its lack of debugging information for client-side exceptions in production. With my patch, your deployed app will be able to report stack traces like this: com.google.gwt.core.client.JavaScriptException: (TypeError) : a is null com.google.gwt.dom.client.DOMImplMozilla.$getBodyOffsetLeft(DOMImplMozilla.java:145) com.google.gwt.user.client.ui.PopupPanel.$setPopupPosition(Document.java:1287) com.google.gwt.user.client.ui.PopupPanel.setPopupPosition(PopupPanel.java:884) com.google.gwt.user.client.ui.PopupPanel.PopupPanel(PopupPanel.java:453) com.typeracer.commons.client.widgets.EnhancedPopup.EnhancedPopup(EnhancedPopup.java:32) com.typeracer.commons.client.widgets.PopupWithIcon.PopupWithIcon(PopupWithFocusableTextBox.java:28) com.typeracer.main.client.controller.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.java:55) com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:50) etc... :-) instead of the current state of affairs that looks like this: lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName: http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html stack: @ http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 Rub@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 dSb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 tA@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 Xmb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289 etc... :-( So, something like this has been used at least internally for quite a long time -- what exactly did you have to change in StackTraceDeobfuscator? -- John A. Tamplin -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
On Wed, Jul 17, 2013 at 4:56 PM, Alex Epshteyn alexander.epsht...@gmail.com wrote: I would like to announce that I have finally solved what I always thought to be GWT's greatest weakness: its lack of debugging information for client-side exceptions in production. With my patch, your deployed app will be able to report stack traces like this: com.google.gwt.core.client.JavaScriptException: (TypeError) : a is null com.google.gwt.dom.client.DOMImplMozilla.$getBodyOffsetLeft(DOMImplMozilla.java:145) com.google.gwt.user.client.ui.PopupPanel.$setPopupPosition(Document.java:1287) com.google.gwt.user.client.ui.PopupPanel.setPopupPosition(PopupPanel.java:884) com.google.gwt.user.client.ui.PopupPanel.PopupPanel(PopupPanel.java:453) com.typeracer.commons.client.widgets.EnhancedPopup.EnhancedPopup(EnhancedPopup.java:32) com.typeracer.commons.client.widgets.PopupWithIcon.PopupWithIcon(PopupWithFocusableTextBox.java:28) com.typeracer.main.client.controller.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.java:55) com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:50) etc... :-) instead of the current state of affairs that looks like this: lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName: http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html stack: @ http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 Rub@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 dSb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 tA@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 Xmb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289 etc... :-( So, something like this has been used at least internally for quite a long time -- what exactly did you have to change in StackTraceDeobfuscator? -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add NavigableSet, NavigableMap to GWT and retrofit TreeMap a...
John A. Tamplin has posted comments on this change.
Change subject: Add NavigableSet, NavigableMap to GWT and retrofit TreeMap
and TreeSet to implement it.
..
Patch Set 2: Code-Review-1
(10 comments)
Generally good, but a number of nits and the big one is we need a bunch of
tests to cover the new functionality (and a couple of bits of changed
functionality -- if the new way is correct, we should have had failing
tests, so we need to add them).
File user/super/com/google/gwt/emul/java/util/AbstractNavigableMap.java
Line 400: abstract IteratorEntryK, V descendingEntryIterator();
Javadoc for what implementing classes are expected to provide for these
abstract methods.
File user/super/com/google/gwt/emul/java/util/NavigableMap.java
Line 2: * Copyright 2012 Google Inc.
2013
Line 25: Map.EntryK, V ceilingEntry(K key);
Javadoc for methods
File user/super/com/google/gwt/emul/java/util/NavigableSet.java
Line 2: * Copyright 2012 Google Inc.
2013
Line 24: E ceiling(E e);
Javadoc for methods
File user/super/com/google/gwt/emul/java/util/TreeMap.java
Line 596
Why delete this line?
Line 84: private boolean inRange(SubMapType type, K key,
The line break seems weird here and elsewhere -- is this formatted with the
standard GWT formatter?
Line 194: if (toInclusive ? (compare 0) : (compare = 0)) {
Maybe compare 0 || (toInclusive compare == 0) would save a comparison
in most cases?
Likewise below.
Line 487: return null;
Is null the proper return here? Previously we were throwing NSE. Either
way, there should probably be a test that verifies the correct result.
Line 545: return null;
Likewise here.
--
To view, visit https://gwt-review.googlesource.com/3650
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I2800b2b54b06a7ef255e01ad44b11909d878362a
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Thomas Broyer t.bro...@gmail.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add Object.clone as throwing implementation
John A. Tamplin has posted comments on this change. Change subject: Add Object.clone as throwing implementation .. Patch Set 2: Code-Review+1 (1 comment) File user/super/com/google/gwt/emul/java/lang/Object.java Line 87: throw new CloneNotSupportedException(GWT does not implement Object.clone()); If we are saying clone is never supported, should this be final? If it is intended that some classes could implement clone themselves, then the message should reflect that. It would be theoretically possible to support clone when compiled to JS, but it would be highly GWT and class-specific. -- To view, visit https://gwt-review.googlesource.com/3616 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ie89b7874953e1d6378fa2a5cb19beb3c34689218 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add Object.clone as throwing implementation
John A. Tamplin has posted comments on this change. Change subject: Add Object.clone as throwing implementation .. Patch Set 4: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/3616 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ie89b7874953e1d6378fa2a5cb19beb3c34689218 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types
John A. Tamplin has posted comments on this change. Change subject: adding compare for several number types .. Patch Set 12: Code-Review+2 The intent wasn't to make it more readable, but to give a slight performance optimization on the assumption that most comparisons don't involve NaNs. -- To view, visit https://gwt-review.googlesource.com/3180 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246 Gerrit-PatchSet: 12 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
On Thu, Jun 13, 2013 at 3:18 AM, David david.no...@gmail.com wrote:
Forgot to mention this code-snippet I found in the BigInteger class:
/**
* The magnitude of this big integer. This array is in little endian
order and
* each digit is a 32-bit unsigned integer. For example: {@code 13} is
* represented as [ 13 ] {@code -13} is represented as [ 13 ] {@code2^32 +
* 13} is represented as [ 13, 1 ] {@code 2^64 + 13} is represented as
[ 13,
* 0, 1 ] {@code 2^31} is represented as [ Integer.MIN_VALUE ] The
magnitude
* array may be longer than strictly necessary, which results in
additional
* trailing zeros.
*
* pTODO(jat): consider changing to 24-bit integers for better
performance
* in browsers.
*/
transient int digits[];
Always nice to have TODO's in code that are not done :-) Who is jat ?
So where else should TODO's go? Clearly this is something that was
intended for future exploration - would you prefer there be nothing there
at all?
--
John A. Tamplin
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote: The lazy parsing would only happen during deserialisation in the client. I think it is safe to assume that a BigInteger created through toString on the server will not result in a parse exception in the client code - or are there known incompatibilities ? I don't want that the regular constructor of BigInteger( String ) or BigInteger( String, int) would behave differently than before. Not even in the client when those BigInts are created in the client. That's why I was asking about the possibility to have different serialisers on client and server side. As the why, well currently the custom field serializer converts the BigInteger to a String, the client side needs to parse the string and convert it to an int array, which involves multiple substring, Integer.parseInt and multiply and add operations. Somehow IE8 has a problem with this. IE9 and other browsers are more efficient, but still that is a lot of CPU operations that can be avoided in my use case. In my particular use case they used BigInteger to represent a key in the database (oracle uses sequence numbers that are bigger than what can be represented with long). That might have not been the best idea, but those decisions have been made a long time ago, when I was not around. On the server side there is a usage of equals and compareTo happening, which would be hard to implement without a BigInteger, so there is logic in the choice. They obviously don't want to have an extra layer of objects to avoid the BigInteger in the GWT client since a lot of code is independent of client or server, this would hinder code sharing between the tiers. On the client side these id's are only send forth and back between client and server, no operation is ever performed, so making the custom field serialiser and the BigInteger cooperate gives a big performance improvement. They only operation needed on the client-side is equals, which can also be optimized to do a String comparison when bother have not been parsed after RPC. I'm beginning to think such a change does not belong in GWT. In your example, wouldn't you be better served by only sending strings to the client rather than BigDecimals, if they client never does anything with them but send them back? I think it is going to be pretty rare in normal situations that you instantiate a BigDecimal but never actually use it in the client, so it seems the special-case hack for your use-case should be performed in your code instead. Too often people want to send things to the client that really don't belong there, and that includes particular representations of it. I know DTOs are extra work over just shipping your regular objects over the wire and GWT RPC makes that easy, but in many cases it is the wrong thing to do. Think about if you were building a proto for the communication -- would you send the data in the current form? If not, you shouldn't be sending it that way via RPC just because it is easy to do so. BTW, I thought Oracle sequence numbers did fit in long (aren't they int64?) -- at least all the JDBC code I see for manipulating them stores them in a Java long. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
On Thu, Jun 13, 2013 at 3:03 PM, David david.no...@gmail.com wrote: Well, if I don't have support for this patch then I better stop working on it. I can understand that this is not seen as a priority for GWT. Worst case I just replace the BigInteger/BigDecimal class in the project itself, that is basically what I did right now. I'm just one person and I'm not even on the steering committee, so you shouldn't take my opinion as gospel. To summarize, I don't think there is any value in having lazy initialization of BigInteger in GWT since it doesn't strike me as an important use-case that you would instantiate a lot of them but never use them, but it might be worth looking at performance on IE8 to see if it can be improved (which might fix your problem in a more generally useful way). Changing the application is not feasible, that will be too much work, we are talking about many thousands of dependencies in a huge codebase where BigIntegers and BigDecimals are used - while handling this optimisation on the RPC level can be done in just a few lines of code. You can also maintain a local fork of GWT if you think that is easier. In many cases we send large lists of objects that contain BigInteger, BigDecimals but only a few will actually be interacted with. So in that case we only need to convert the Strings to BigInteger (or BigDecimal) when really needed. Well, if you are sending lots of stuff to the client that isn't actually used on the client, that seems an obvious avenue for optimization. Again, just because you can easily ship it to the client doesn't mean you should. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.
John A. Tamplin has posted comments on this change. Change subject: Ensure clinits get called for JSO instance methods. .. Patch Set 2: Code-Review+2 -- To view, visit https://gwt-review.googlesource.com/3361 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types -Byte.compare -...
John A. Tamplin has posted comments on this change. Change subject: adding compare for several number types -Byte.compare -Short.compare -Integer.compare -Long.compare -Float.compare (Double already exists) fixes issue 7998 .. Patch Set 11: That was because you left else return 0 before the NaN checks. You would have to move that branch to the end, below the NaN checks to re-order them. BTW, since GWT treats floats and doubles the same, should we just have Float.compareTo delegate to Double.compareTo? Less code to be different, and it should get completely inlined. -- To view, visit https://gwt-review.googlesource.com/3180 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246 Gerrit-PatchSet: 11 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.
John A. Tamplin has posted comments on this change. Change subject: Ensure clinits get called for JSO instance methods. .. Patch Set 1: This seems a lot less than what you showed me at the Meet-up -- what did you change? Also needs tests. -- To view, visit https://gwt-review.googlesource.com/3361 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.
John A. Tamplin has posted comments on this change. Change subject: Ensure clinits get called for JSO instance methods. .. Patch Set 1: I think simply having a JSO with static initializers that don't work without this patch would be sufficient. I think your current fix is clearer than making it appear to be a static impl. -- To view, visit https://gwt-review.googlesource.com/3361 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
Have we evaluated why it is so slow on ie8? It might be easier to fix that. The one thing it does is heavy use of StringBuffers so that could be where the issue is. On Jun 12, 2013 8:09 PM, Brian Slesinsky skybr...@google.com wrote: Lazy parsing can be a performance win, but it also complicates the API in the case of a parse error. Have you thought about how to report errors when they happen later? It might less confusing to solve this using a separate LazyBigDecimal class. People can declare fields of this type in their data transfer objects when they're concerned about performance. On Tue, Jun 11, 2013 at 1:56 AM, stuckagain david.no...@gmail.com wrote: Hi, I am working on a fix for this issue: https://code.google.com/p/google-web-toolkit/issues/detail?id=8083 I am avoiding converting from string to the internal format of BigInteger because it has a big performance impact on IE8 when sending it over RPC. It performs much better in IE9 and other browsers, but still I want to optimize this since this is having a major impact in an application I am working on (And I saw some other people in the banking industry having similar issues with BigDecimal). In many cases this data is never modified in the client, so I am delaying the actual parsing of the String to the internal format of BigInteger. Is it feasible to have custom field serializers depending on running in the client or server ? The question I am asking is because I don't want to break the BigInteger(String) constructor that will throw exceptions when you feed it a non parseable string. so my solution would be to use a static method or custom constructor for BigInteger when deserializing on the client. But this method is not available in the real java.math.BigInteger class. So is it possible to have different client and server serializers/deserializer code for RPC ? David -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types -Byte.compare -...
John A. Tamplin has posted comments on this change. Change subject: adding compare for several number types -Byte.compare -Short.compare -Integer.compare -Long.compare -Float.compare (Double already exists) fixes issue 7998 .. Patch Set 11: Code-Review+2 -- To view, visit https://gwt-review.googlesource.com/3180 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246 Gerrit-PatchSet: 11 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] code review policy
I've been assuming I can give +2 for the parts of the code I am most familiar with. On Jun 9, 2013 11:12 PM, Stephen Haberman step...@exigencecorp.com wrote: Hey, I wasn't quite sure, so figured I would ask: what's our policy on who can give +2s? Is it any committer? I assume so, but perhaps out of tradition, I've been assuming Googlers would give +2s. Well, and even if we are/have moved past the Google-only phase of GWT, for now/awhile they will still have the most knowledge about the codebase (perhaps sans Thomas). - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types -Byte.compare -...
John A. Tamplin has posted comments on this change.
Change subject: adding compare for several number types -Byte.compare
-Short.compare -Integer.compare -Long.compare -Float.compare (Double
already exists) fixes issue 7998
..
Patch Set 9: -Code-Review
(4 comments)
File user/super/com/google/gwt/emul/java/lang/Float.java
Line 37: if (isNaN(x)) {
You have to make sure those comparisons behave as desired when one or both
operands are NaNs.
File user/super/com/google/gwt/emul/java/lang/Integer.java
Line 61: return signum(x - y);
The spec of the Javadoc doesn't care, so anyone that writes code that
depends on implementation details, whether our own JRE emulation or
different JVMs, deserves whatever pain they get.
File user/test/com/google/gwt/emultest/java/lang/FloatTest.java
Line 81: }
Floating point varies significantly across all browsers. At least when I
was working on it, Safari JSCore steals bits from floats for tag values, so
there are some values that aren't representable there and you get different
roundoff than other engines.
I don't believe you can type -0 in JS, but there are other ways to
generate them. I seem to recall code in Dan's float-to-int bytes tests
that generated them.
File user/test/com/google/gwt/emultest/java/lang/IntegerTest.java
Line 120: assertEquals(0, Integer.compare(1, 1));
We already say in the JRE compatibility doc that we don't handle integer
overflows. However, people aren't going to think of a comparison as an
integer overflow case, so if we can handle it cheaply we should.
After MAX_VALUE - MIN_VALUE overflows, what happens after the result is
coerced to an int? If we can't deal with the overflow after the fact, we
would need to check for overflow before doing the comparison.
Or, maybe that is why we didn't use subtraction in the first place.
--
To view, visit https://gwt-review.googlesource.com/3180
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246
Gerrit-PatchSet: 9
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate java.util.Objects
John A. Tamplin has posted comments on this change. Change subject: Emulate java.util.Objects .. Patch Set 8: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/3184 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I15a10e7c52eb39baac2c22b9f6596ad0a5c1c599 Gerrit-PatchSet: 8 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Ray Cromwell cromwell...@gmail.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] serializing final fields
On Wed, Jun 5, 2013 at 10:46 PM, Stephen Haberman step...@exigencecorp.comwrote: I don't have a good idea about what could break I believe nothing would break--it's that final fields that were previously not going over the wire would now go over the wire. So, I guess technically that is a change in semantics--so it wouldn't be like oh, your GWT app fails to compile, more like you were doing *what* with that field...that doesn't work anymore. Or we're exposing a value over the wire that previously the developer knowingly made final so that it would not (seems pretty odd though...). Yes, that is what we were worried about -- particularly that some Google internal app was putting some sensitive data in final fields and previous scrutiny didn't uncover it because it didn't go over the wire. Then, making final fields serializable would essentially be a leak of sensitive information. I think we will at least want a flag to turn it on and off. It might be temporary just to land the patch; not sure if it should survive until the 2.6 release. Okay, well, technically a flag for that already exists in the patch--I suppose we could land it as is and then hope to maybe remove it by 2.6 or there after. I was just hoping to simplify it. I'll plan to move it over to gerrit then... Does having the flag really make it that much more complicated? -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate java.util.Objects
John A. Tamplin has posted comments on this change. Change subject: Emulate java.util.Objects .. Patch Set 7: (2 comments) LGTM with a couple of nits. File user/super/com/google/gwt/emul/java/util/Objects.java Line 2: * Copyright 2008 Google Inc. Copyright date is wrong again. File user/test/com/google/gwt/emultest/java/util/ObjectsTest.java Line 2: * Copyright 2008 Google Inc. Copyright date. -- To view, visit https://gwt-review.googlesource.com/3184 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I15a10e7c52eb39baac2c22b9f6596ad0a5c1c599 Gerrit-PatchSet: 7 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Ray Cromwell cromwell...@gmail.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Ensures integer pixel values and adds getters for subpixel v...
John A. Tamplin has posted comments on this change. Change subject: Ensures integer pixel values and adds getters for subpixel values .. Patch Set 2: @Stephen - when you say you reproduced it, do you mean you reproduced the subpixel problem or the problem of |0 not having the intended effect? If you are doing solely integer math with doubles, as would be the case with GWT-generated code, there can be no roundoff. Yes, if you add floats together to get something that should be an integer, it generally won't be because of the imprecise nature of floating point. I don't think it is a problem that 8.* winds up as 8. -- To view, visit https://gwt-review.googlesource.com/3090 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I27e98f0ad3c1c236b2d85d24f197719fa4cd352a Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: John Ahlroos j...@vaadin.com Gerrit-Reviewer: Artur Signell ar...@vaadin.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Jens Nehlmeier jens.nehlme...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: John Ahlroos j...@vaadin.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate java.util.Objects
John A. Tamplin has posted comments on this change. Change subject: Emulate java.util.Objects .. Patch Set 4: Code-Review+1 (2 comments) LGTM with minor nits File user/super/com/google/gwt/emul/java/util/Objects.java Line 2: * Copyright 2008 Google Inc. 2013 File user/test/com/google/gwt/emultest/java/util/ObjectsTest.java Line 2: * Copyright 2008 Google Inc. 2013 -- To view, visit https://gwt-review.googlesource.com/3184 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I15a10e7c52eb39baac2c22b9f6596ad0a5c1c599 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Ray Cromwell cromwell...@gmail.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate Boolean.compare(boolean,boolean), Character.compare(...
John A. Tamplin has posted comments on this change. Change subject: Emulate Boolean.compare(boolean,boolean), Character.compare(char,char) .. Patch Set 5: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/3183 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I00df601b33cb5e270be45819c1ad54ae9c955869 Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate java.util.Objects
John A. Tamplin has posted comments on this change. Change subject: Emulate java.util.Objects .. Patch Set 5: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/3184 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I15a10e7c52eb39baac2c22b9f6596ad0a5c1c599 Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Ray Cromwell cromwell...@gmail.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate java.util.Objects
John A. Tamplin has posted comments on this change. Change subject: Emulate java.util.Objects .. Patch Set 5: I think that is no reason to hold this up -- we can use the same license, and then change all of them at once. -- To view, visit https://gwt-review.googlesource.com/3184 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I15a10e7c52eb39baac2c22b9f6596ad0a5c1c599 Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Ray Cromwell cromwell...@gmail.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate java.util.Objects
John A. Tamplin has posted comments on this change. Change subject: Emulate java.util.Objects .. Patch Set 6: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/3184 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I15a10e7c52eb39baac2c22b9f6596ad0a5c1c599 Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Ray Cromwell cromwell...@gmail.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate Boolean.compare(boolean,boolean), Character.compare(...
John A. Tamplin has posted comments on this change. Change subject: Emulate Boolean.compare(boolean,boolean), Character.compare(char,char) .. Patch Set 5: I originally suggested signup in Integer.compare because it was recreating that functionality, and the previous versions used 0/1/-1. Since the spec doesn't require specific values, I am fine just using subtraction -- however, we need to make sure that coercion works as expected and we handle overflow cases properly (for example, Integer.compare(2^31, -2^31)). -- To view, visit https://gwt-review.googlesource.com/3183 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I00df601b33cb5e270be45819c1ad54ae9c955869 Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate Boolean.compare(boolean,boolean), Character.compare(...
John A. Tamplin has posted comments on this change. Change subject: Emulate Boolean.compare(boolean,boolean), Character.compare(char,char) .. Patch Set 6: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/3183 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I00df601b33cb5e270be45819c1ad54ae9c955869 Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding Integer.compare to emulation
John A. Tamplin has posted comments on this change. Change subject: Adding Integer.compare to emulation .. Patch Set 2: Code-Review-2 -- To view, visit https://gwt-review.googlesource.com/3180 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding Integer.compare to emulation
John A. Tamplin has posted comments on this change. Change subject: Adding Integer.compare to emulation .. Patch Set 2: Code-Review-1 (1 comment) File user/super/com/google/gwt/emul/java/lang/Integer.java Line 61: return (x y) ? -1 : ((x == y) ? 0 : 1); Fixes the typo, but my other comments still apply. -- To view, visit https://gwt-review.googlesource.com/3180 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding Integer.compare to emulation
John A. Tamplin has posted comments on this change.
Change subject: Adding Integer.compare to emulation
..
Patch Set 2: -Code-Review
I also agree about adding similar functionality in the other wrapper types.
I am nervous about having partial support for JDK 1.7 additions -- if
someone changes their source level to 1.7 and codes against a 1.7 JDK they
are likely to run into all sorts of things that don't work yet. However,
we want to get there before long and this is pretty innocuous, so I am fine
adding these now.
The main thing is adding a test that would have caught your first typo
version, and I would prefer to see them written as:
static int compare(int x, int y) {
return signum(x - y);
}
just to have less duplication and take advantage of improvements in signum
to avoid branching if we ever use the bit-shifting trick from Hacker's
Delight:
http://www.informit.com/articles/article.aspx?p=1959565seqNum=8
--
To view, visit https://gwt-review.googlesource.com/3180
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types -Byte.compare -...
John A. Tamplin has posted comments on this change.
Change subject: adding compare for several number types -Byte.compare
-Short.compare -Integer.compare -Long.compare -Float.compare (Double
already exists) fixes issue 7998
..
Patch Set 7: Code-Review+1
(7 comments)
LGTM with minor changes
File user/super/com/google/gwt/emul/java/lang/Byte.java
Line 36: public static int compare(byte x, byte y) {
Same question as short - could we use Integer.signum here?
Line 100: return Byte.compare(value, b.value);
I noticed you didn't make this change in other places -- you probably
should, particularly in Float where compareTo doesn't handle NaNs the same
way as compare.
File user/super/com/google/gwt/emul/java/lang/Float.java
Line 37: if (isNaN(x)) {
Is there a bug for this, or did you just notice the behavior wan't correct
before?
Line 46:
Trailing spaces
File user/super/com/google/gwt/emul/java/lang/Short.java
Line 37: return (x y) ? -1 : ((x == y) ? 0 : 1);
Couldn't you use Integer.signum here? Or do coercion rules make that less
efficient or inaccurate?
File user/test/com/google/gwt/emultest/java/lang/FloatTest.java
Line 55: public void testCompare() {
It doesn't look like we have Float.compareTo under test. Should we
duplicate this method and test that as well?
Line 59:
Trailing spaces
--
To view, visit https://gwt-review.googlesource.com/3180
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246
Gerrit-PatchSet: 7
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types -Byte.compare -...
John A. Tamplin has posted comments on this change. Change subject: adding compare for several number types -Byte.compare -Short.compare -Integer.compare -Long.compare -Float.compare (Double already exists) fixes issue 7998 .. Patch Set 8: Code-Review+2 (2 comments) LGTM with a couple of nits. File user/super/com/google/gwt/emul/java/lang/Byte.java Line 100: return Byte.compare(value, b.value); Byte. is unnecessary, right? (Eclipse with the GWT-recommended settings should be warning you about this). File user/test/com/google/gwt/emultest/java/lang/FloatTest.java Line 66: Trailing spaces. -- To view, visit https://gwt-review.googlesource.com/3180 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246 Gerrit-PatchSet: 8 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate Boolean.compare(boolean,boolean), Character.compare(...
John A. Tamplin has posted comments on this change.
Change subject: Emulate Boolean.compare(boolean,boolean),
Character.compare(char,char)
..
Patch Set 2: Code-Review+1
(1 comment)
File user/test/com/google/gwt/emultest/java/lang/BooleanTest.java
Line 62: public void testCompare() {
Have we decided we don't care about method order any more? I know it has
been proposed, but I didn't think anything was agreed.
--
To view, visit https://gwt-review.googlesource.com/3183
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I00df601b33cb5e270be45819c1ad54ae9c955869
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-HasComments: Yes
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types -Byte.compare -...
John A. Tamplin has posted comments on this change. Change subject: adding compare for several number types -Byte.compare -Short.compare -Integer.compare -Long.compare -Float.compare (Double already exists) fixes issue 7998 .. Patch Set 9: Code-Review+2 -- To view, visit https://gwt-review.googlesource.com/3180 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246 Gerrit-PatchSet: 9 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Emulate java.util.Objects
John A. Tamplin has posted comments on this change. Change subject: Emulate java.util.Objects .. Patch Set 3: Code-Review-1 (1 comment) Need tests as well. File user/super/com/google/gwt/emul/java/util/Objects.java Line 32: return Arrays.deepEquals0(a, b); This doesn't handle non-array objects, right? -- To view, visit https://gwt-review.googlesource.com/3184 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I15a10e7c52eb39baac2c22b9f6596ad0a5c1c599 Gerrit-PatchSet: 3 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Ensures integer pixel values and adds getters for subpixel v...
John A. Tamplin has posted comments on this change. Change subject: Ensures integer pixel values and adds getters for subpixel values .. Patch Set 1: (1 comment) File user/src/com/google/gwt/dom/client/DOMImpl.java Line 196: return (int) getSubpixelAbsoluteLeft(elem) | 0; The pyjamas issue linked doesn't exist, and I think many more things would be broken if |0 didn't work. Math.ceil would be much slower and take up more space. In some places, we also use ~~x to coerce to int. -- To view, visit https://gwt-review.googlesource.com/3090 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I27e98f0ad3c1c236b2d85d24f197719fa4cd352a Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: John Ahlroos j...@vaadin.com Gerrit-Reviewer: Artur Signell ar...@vaadin.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Jens Nehlmeier jens.nehlme...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types -Byte.compare -...
John A. Tamplin has posted comments on this change. Change subject: adding compare for several number types -Byte.compare -Short.compare -Integer.compare -Long.compare -Float.compare (Double already exists) fixes issue 7998 .. Patch Set 9: -Code-Review (1 comment) File user/super/com/google/gwt/emul/java/lang/Integer.java Line 61: return signum(x - y); That is a change from before, but from the Javadoc it should be fine. However, I worry about overflow conditions, such as compare(2^31, -2^31) -- To view, visit https://gwt-review.googlesource.com/3180 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246 Gerrit-PatchSet: 9 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: adding compare for several number types -Byte.compare -...
John A. Tamplin has posted comments on this change. Change subject: adding compare for several number types -Byte.compare -Short.compare -Integer.compare -Long.compare -Float.compare (Double already exists) fixes issue 7998 .. Patch Set 9: Code-Review+2 Didn't expect it to remove my previous score. -- To view, visit https://gwt-review.googlesource.com/3180 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib33c93ff0fb3f7e4b93994a29d6e2a65898be246 Gerrit-PatchSet: 9 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Removing support for old browsers
On Thu, May 30, 2013 at 2:19 PM, Jens jens.nehlme...@gmail.com wrote: How would soft permutations work if you have browser version specific JS hacks/workarounds implemented during JJS compilation? If you have a workaround for IE6 and a different one for IE7 and you can't mix both, then you are probably in trouble, aren't you? I don't know if that's just a theoretical question or if this case actually exists in todays JJS compiler. I was just wondering about it as I always thought that soft permutations only work well for deferred binding and hard permutations can have the potential to be compiled totally different by the compiler. Soft perms work exactly the way hard perms do, the only difference is there both implementations are included and a runtime check instantiates the right one. For example, GWT.create(Foo.class) will normally get replaced with new FooIE6() or new FooStandard() at compile time for corresponding permutations. Soft perms do something similar to this (it is actually much more complicated for efficiency, but the end result is similar): getProperty(user-agent).equals(ie6) ? new FooIE6() : new FooStandard() If you have a workaround that is different between IE6 and IE7, you already have a problem since those are in the same permutation, so you already have to be doing a runtime check. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] GWT Coding Style Update
On Thu, May 30, 2013 at 9:22 PM, Goktug Gokdogan gok...@google.com wrote: We currently have a coding style guide for GWT-SDK here: https://developers.google.com/web-toolkit/makinggwtbetter#codestyle The guide has some enforcements like static/non-static + alphabetical ordering. Alphabetical ordering is as good as no ordering in many cases and these rules are already broken in many places. I propose following Guava and many other java libs and just enforce logical ordering during code reviews (which is also internal recommendation at Google). One good approach for logical order is to group related public APIs and then slot in other methods and nested-classes to keep them close to the related context. This usually helps to follow the code with less jumps around the class. Anyway, I know this can quickly turn into a bikeshed discussion so please try to resist the urge to oppose unless you have a big concern =) I have worked in the GWT codebase for years, and in others that didn't have as strict style/order guidelines, and I have to say I *greatly* prefer working in the current code. Even with IDEs letting you find members more easily, I still really miss having ordered method names when I work in code that doesn't have it. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] GWT Coding Style Update
On Thu, May 30, 2013 at 10:22 PM, Goktug Gokdogan gok...@google.com wrote: At the end I guess this comes to personal preferences. If you personally prefer the static/non-static + alphabetical ordering, IDE can show it to you with a simple keystroke (Ctrl+O in Eclipse) but it can't do the reverse. So what is the rationale behind this proposal? GWT has operated the way it is for many years. What problems has it caused? Are we no longer running ant checkstyle in the submit queue? -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] GWT Coding Style Update
On Thu, May 30, 2013 at 11:13 PM, Goktug Gokdogan gok...@google.com wrote: It is currently inconsistent, it is not enforced, Why was it stopped being enforced? It used to run :ant_tests (IIRC) that ran checkstyle, and TAP definitely caught style violations. We never had any trouble accepting internal contributions when I was there, as it would get caught in the submit queue. most of GWT contributions are coming from Googlers who are not aware that GWT has different rules than all other Google3 code. Moving code from Google3 to GWT requires re-sorting. Why is that any different than any other third-party product? Plus one of the first rules is to follow the style of the code around your change, regardless of whether that matches the style guide. If you change the name of a function, you need to move the code to a new random location and on the review you can't see what really changed in the function or even if it has changed. I don't care much about internal stuff much but seeing an API in alphabetical order is as good as any other random order for the end users of the SDK. These are the similar reasons why none of other high profile libs (Guava, Guice, Dagger and JDK itself) enforce such rules. I still prefer the way it is, and I think having one order (I don't particularly care what that is) that is deterministic is better than anything else, because the others always devolve into random orders as people don't bother trying to organize it since it is already disorganized, and it isn't brought up in reviews because there isn't any definitive answer anyway. Likewise for formatting rules. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adds support for lower case encoding names to String
John A. Tamplin has posted comments on this change. Change subject: Adds support for lower case encoding names to String .. Patch Set 2: If you are going for the regex, you probably want to create the pattern once and reuse it rather than creating a new pattern every time. Also, doesn't the pattern need to be anchored? I don't care much either way -- I can't imagine that looking up a character set is going to be very common. -- To view, visit https://gwt-review.googlesource.com/3000 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ie9532ba1e7e6e863093727e354f7f3174229c2ab Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Honza Rameš rame...@gmail.com Gerrit-Reviewer: Honza Rameš rame...@gmail.com Gerrit-Reviewer: James Nelson ja...@wetheinter.net Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: fix mismatch in Double/Float.isInfinite between dev / produc...
John A. Tamplin has posted comments on this change. Change subject: fix mismatch in Double/Float.isInfinite between dev / production .. Patch Set 1: Code-Review+2 -- To view, visit https://gwt-review.googlesource.com/2250 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I6e7a891ff1339a64f3d9aaa57978fac6b23fdb64 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka kurka.dan...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Doing migrations one step at a time
On Mon, May 27, 2013 at 4:40 AM, stuckagain david.no...@gmail.com wrote: Decisions on browser support seems to be mostly driven by Google statistics ... but many GWT apps are running outside of the internet. The apps that I am maintaining and developing run in a banking environment, where the browser usage statistics are a lot different - IE8 is the king, Chrome is nearly non existant and FireFox is growing. Most banks are very reluctant to switch browsers because they have a lot of software strictly qualified to a specific version and Windows does not allow co-instalation of multiple versions of IE. (Chrome and FireFox is a differetn discussion, but most banks do not use those right now). Banking is still one of the bigger markets of software development, so somehow I hope you want to consider supporting IE8 in some form in the near future. I guess until 2014 seems like a reasonable timerange. for us, but certainly not faster. At the GWT meetup, there wasn't really consensus on anything regarding IE8 other than not before 3.0 next May. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: FileUpload failed to initialize internal state
John A. Tamplin has posted comments on this change. Change subject: FileUpload failed to initialize internal state .. Patch Set 1: Code-Review+2 -- To view, visit https://gwt-review.googlesource.com/2981 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I74ccb2617bb301aeaf0845e5c43f724d6247b3ca Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Generator, get method body
On Fri, May 24, 2013 at 6:33 AM, Roberto Lublinerman rlu...@google.comwrote: ASTParser should be in eclipse-jdt-core, although there seems to be different AST representation, GWT uses the one in org.eclipse.jdt.internal.compiler.ast whereas the ASTParser works in org.eclipse.jdt.core.dom. JDT has a very thick api to support the eclipse editor and some simple tasks might become overly complex. I wonder if the approach you have taken using a much smaller and simpler parser is not actually better. When I needed to parse the source to get parameter names from interface methods (which aren't included in the bytecode), I used CodeSnippetParsingUtil in JDT and it seemed straightforward enough. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Doing migrations one step at a time
On Fri, May 24, 2013 at 8:53 PM, Thomas Broyer t.bro...@gmail.com wrote: BTW, disabling the IE6/7 permutation is only a matter of set-property name=user.agent value=ie8,ie9,gecko1_8,safari,opera/ right? Removing support would start by removing the ie6 permutation and then cleaning up the code by removing now-unused code, and finally possibly clean up further by refactoring some code that was used in both ie6 and ie8 to better take advantage that it'd now only be running in IE8. Yes, and maybe we should go ahead and do that immediately -- leave all the support for ie6/7 in place, but just don't build it by default. If anyone is running from trunk and needs it, they simple add it back with an extend-property. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Generator, get method body
On Thu, May 23, 2013 at 5:28 PM, Manuel Carrasco Moñino man...@apache.orgwrote: What I'm doing is a generator for presentations. Given a java class with my example methods, create a set of html slides. The generator reads the javadoc and the body of the method, and put them in a hash table into the generated class. Then in client side I can use this info to insert the code and wording in my slides using gwtquery. That sounds a lot like what Showcase does -- maybe this will help: https://code.google.com/p/google-web-toolkit/source/browse/trunk/samples/showcase/src/com/google/gwt/sample/showcase/generator/ShowcaseGenerator.java -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Generator, get method body
On Thu, May 23, 2013 at 7:56 PM, Manuel Carrasco Moñino man...@apache.orgwrote: The ShowcaseGenerator, is actually reading the content of the source files and generating .html files, but I want to extract method bodies and their javadoc so what I need an AST. So my question is more about how to use the gwt ast from a generator. The GWT AST is not available to generators, so you will have to build your own -- you can use JDT as that is included with GWT. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Do you guys need help in translation, Arabic language specifically?
On Tue, May 14, 2013 at 2:13 AM, Mohammad Al-Quraian m4des...@gmail.comwrote: I want to try and help improve GWT, and I was wondering if that is possible. I noticed for instance in the Simple Pager, the words are still in English even when the selected locale is Arabic. That particular example seems to be a case where no translations were ever done at all. We did get the Showcase messages professionally translated (into Arabic and others), but it would certainly be helpful to have translations for the Simple Pager widget built into GWT. You would need to create SimplePager_ImageButtonsConstants_locale.properties files in the same directory, with lines like: fastForward=translation ... The file should be UTF8-encoded. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Removes the static book keeping in the Timer class.
John A. Tamplin has posted comments on this change. Change subject: Removes the static book keeping in the Timer class. .. Patch Set 1: Code-Review+1 My recollection is that the close hook was required to avoid memory leaks in IE. Please make sure removing this doesn't cause a leak in IE8+ (since we will deprecate IE6-7 before trunk gets released again). -- To view, visit https://gwt-review.googlesource.com/2851 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Idf6a9c81a5654bc2eb736a2b4ef81d5cf0517728 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: ValueListBox should implement HasEnabled (6112) (issue1832803)
On Fri, May 17, 2013 at 6:11 AM, Patrick Tucker tucker...@gmail.com wrote: I would be more than happy to but I can't seem to get gwt-dev, gwt-servlet, gwt-user,... under master to work when I check them out in eclipse. Eclipse tells me the source folders do not exist when they do. I'm not familiar with GIT so I'm at a loss. Did you setup Eclipse correctly, as documented in eclipse/README.txt? -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Removes JavaScriptException dependency from c.g.gwt.core.sha...
John A. Tamplin has posted comments on this change. Change subject: Removes JavaScriptException dependency from c.g.gwt.core.shared. .. Patch Set 1: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/2840 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib610bb27cefb3d405e2126417008f4134743e723 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-HasComments: No -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Don't call toString() on plain Java arrays
John A. Tamplin has posted comments on this change. Change subject: Don't call toString() on plain Java arrays .. Patch Set 1: Code-Review+2 (1 comment) File user/test/com/google/gwt/dev/jjs/test/JsoTest.java Line 410: s.getClass(); I'm kind of surprised that getClass wouldn't get optimized out anyway, since it gets replaced with a field reference, but I think this should be fine since the test would be failing if the cast/getClass call get optimized away. -- To view, visit https://gwt-review.googlesource.com/2771 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I2e90cf1442d126efe8d7ec866204f20c5e4cf3e9 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Introduces a common SerializableThrowable as public API.
John A. Tamplin has posted comments on this change. Change subject: Introduces a common SerializableThrowable as public API. .. Patch Set 5: JavaScriptException is in the client package and contains JSNI, so it cannot be used on the server (some JVMs will immediately give a link exception if you classload a class with native methods and it can't find the native library for the class). While currently we leak a ton of client classes to the server and it mostly works for most people if you don't reference the wrong thing, that isn't a good solution and we have been working at removing such references -- we shouldn't add more. It really needs to be a hard rule that no class in shared ever references any class in client (or server). -- To view, visit https://gwt-review.googlesource.com/2160 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I98ae52858d87b6ac4a0c844464b25540be454942 Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Introduces a common SerializableThrowable as public API.
John A. Tamplin has posted comments on this change.
Change subject: Introduces a common SerializableThrowable as public API.
..
Patch Set 5:
(1 comment)
Yes, I know there are many cases now. But adding more takes us further
from the goal and adds more places to get tripped up.
File user/src/com/google/gwt/core/shared/SerializableThrowable.java
Line 150: } catch (JavaScriptException e) {
This will definitely classload JavaScriptException.
--
To view, visit https://gwt-review.googlesource.com/2160
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I98ae52858d87b6ac4a0c844464b25540be454942
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Introduces a common SerializableThrowable as public API.
John A. Tamplin has posted comments on this change. Change subject: Introduces a common SerializableThrowable as public API. .. Patch Set 5: Or more likely, SerializableThrowable shouldn't be in shared anyway. -- To view, visit https://gwt-review.googlesource.com/2160 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I98ae52858d87b6ac4a0c844464b25540be454942 Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: GWT bug fix: Fix parsing of currency formats in com.google.g...
John A. Tamplin has posted comments on this change. Change subject: GWT bug fix: Fix parsing of currency formats in com.google.gwt.i18n.client.NumberFormat for formats with postfix currency symbols. .. Patch Set 2: Code-Review+1 -- To view, visit https://gwt-review.googlesource.com/2560 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib85a29257bbfd6e12499a6c4a0123192d5d5acab Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Simon Hofer sho...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Simon Hofer sho...@google.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: future of jvm dev mode
On Mon, Apr 15, 2013 at 8:48 PM, Ray Cromwell cromwell...@google.comwrote: Another downside of DevMode maintenance is all the hacks needed in the codebase around isScript()/@GwtScriptOnly and other magic JVM stuff. Many of those hacks are there for both performance and debugging (ie, where the JS version is a more complicated implementation to get decent performance when compiled to JS), and not all of them are just because of slow boundary crossings. So, I suspect by doing away with them you would simply make everything slower. There are still lingering bugs in HostedModeClassRewriter around SingleJsoImpls and generics. I agree that there is nothing that works as smoothly and JVM roundtripping, and even if an incremental SDM mode could have equal or superior reload performance, there is still the issue of IDE integration. On the other hand, for debugging integration with JS, and using GWT code in contexts like Chrome extensions, SDM is a lot nicer. It's also way nicer for stuff like games, where the invocation overhead becomes large for stuff like canvas and webgl. So it sounds like they each have their place. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Removes api-checker reference JARs from the source tree.
John A. Tamplin has posted comments on this change. Change subject: Removes api-checker reference JARs from the source tree. .. Patch Set 1: Yes, and many places don't allow build systems unfettered access to the internet, such as at Square. So moving them to some external system greatly complicates getting builds working, as you have to arrange to fetch them manually and update an internal mirror, and then manually point at that mirror instead. -- To view, visit https://gwt-review.googlesource.com/2500 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I3d5a585fb57cfd959504109df35279b3c9c56879 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Thomas Broyer t.bro...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: future of jvm dev mode
On Sat, Apr 6, 2013 at 2:05 PM, Stephen Haberman stephen.haber...@gmail.com wrote: For me it would be totally fine to have a plugin for FF15 and then for FF20 and the next for FF25 which would reduce your maintaining work. Same for Chrome. I hold off on updating FF as well, but I believe a lot of users got antsy about oh noes! the latest FF isn't supported, GWT is deadz! before Brian got on top of the FF plugin process. FF clearly wants to get rid of all binary plugins, yet they also have no interest in exposing the sort of hooks we would need to use pure-JS plugins. Chrome has some issues, but with the fork of WebKit, perhaps the identity and performance issues can be addressed -- at least part of the reluctance about doing anything more came from the convoluted path from JS code to V8. I know it takes a lot of effort to keep the FF plugins up to date (I did it for a while myself), but I think that cost is less than the cost of losing a usable DevMode. Totally agreed. I think that should be our goal--getting to GWT to the point where it can integrate sexily with today's/tomorrow's web developer tool chain (JS debuggers, etc.). I think the problem is that the technology to make SuperDevMode even close to as useful as debugging in the JVM doesn't exist yet, and it's not clear when it will exist. I have no problem working towards that goal, but in the meantime you can't be talking about ditching what works great now. SDM is nice, but it still feels like the limited experience of debugging a JS app rather than having the tools available for debugging in the JVM. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Avoid implicit inter-dependencies between DOM, History, Wind...
John A. Tamplin has posted comments on this change. Change subject: Avoid implicit inter-dependencies between DOM, History, Window and Widgets through BaseListenerWrapper by moving things to where they're used. .. Patch Set 6: Code-Review+1 Still have the same question about prefixing something that should already be in scope. Also, looks like you uploaded another patch just as I finished reviewing the earlier one, but I couldn't see any obvious changes. Is there a way to see the delta between two patches in gerrit? -- To view, visit https://gwt-review.googlesource.com/1241 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I44ea5f26c96716879b2a23331cafc26a63644e89 Gerrit-PatchSet: 6 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Thomas Broyer t.bro...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] gwtmauve: java emulation / compatibility test kit in GWT
On Thu, Mar 21, 2013 at 9:16 PM, Sebastián Gurin sebastigu...@gmail.comwrote: I think this can be really interesting to those looking to find GWT jre emulation bugs. I myself just discovered some of them listed on http://gwtmauve.googlecode.com/svn/trunk/gwtmauve/readme.txt (rich conclusions of this project results can be taken from these bugs) Well, I hope this can be useful to those who want to find and fix GWT bugs and also to know which parts of the GWT JRE emulation are more broken in production mode. Use it as you like. Had to release it under gpl3 for respecting mauve sources license. Comments and ideas are most welcome. Regards Thanks, this is useful. Note that clone isn't supported (it can't be supported in general in JS), and generally you shouldn't expect the same exceptions to be thrown where doing so is inefficient -- see https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsCompatibility. For example, Java String is directly mapped to a JS string, so the only way to give the same IOOB exceptions would be to add checks around every index/substring/etc operation. Likewise for many NPEs. That explains a large chunk of them. Some of the others, such as Character.toTitleCase, are because they can't be implemented properly and shouldn't really be used anyway (in many cases, the title case of a character should be multiple characters). BigInteger is itself a slow emulation in JS, so I am not surprised that isProbablyPrime is extremely slow on a large number. The others, such as the missing Collections.rotate and bugs in Arrays.fill, Collections.copy, and String.compareTo are good catches and should have issues filed. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Change in gwt[master]: Updates ICU4J from 4.4.2 to 50.1.1
On Mon, Mar 18, 2013 at 5:30 PM, n.giamou...@gmail.com wrote: Any updates on this? Just did a pull and the jar is still missing. When you say a pull, did you mean svn up? gwt/tools is still managed under svn, and I picked it up just a couple of days ago when I synced. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Avoid implicit inter-dependencies between DOM, History, Wind...
John A. Tamplin has posted comments on this change. Change subject: Avoid implicit inter-dependencies between DOM, History, Window and Widgets through BaseListenerWrapper by moving things to where they're used. .. Patch Set 4: Code-Review+1 (4 comments) I would still prefer to just remove the stuff we said we were going to remove in 2.0. If anybody is still using it, they have certainly had plenty of notice. File user/src/com/google/gwt/user/client/BaseListenerWrapper.java Line 37: * @deprecated will be removed in GWT 2.0 with the handler listeners themselves If we aren't going to remove this now, we should update the comment to when we will remove it. File user/src/com/google/gwt/user/client/DOM.java Line 79: DOM.NativePreview.add(preview); Does DOM. need to be included here? File user/src/com/google/gwt/user/client/History.java Line 116: History.WrapHistory.add(listener); Likewise. File user/src/com/google/gwt/user/client/ui/ListenerWrapper.java Line 94: * @param T listener type Likewise. -- To view, visit https://gwt-review.googlesource.com/1241 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I44ea5f26c96716879b2a23331cafc26a63644e89 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Thomas Broyer t.bro...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-HasComments: Yes -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Move Base64Utils to com.google.gwt.util.tools.shared
John A. Tamplin has posted comments on this change. Change subject: Move Base64Utils to com.google.gwt.util.tools.shared .. Patch Set 3: Code-Review+1 (1 comment) I'm not sure I understand where this will wind up eventually, but other than not having a suite that covers it anymore this change shouldn't break anything. File user/test/com/google/gwt/user/RpcJreSuite.java Line 68 So there won't be a suite that covers this test now? -- To view, visit https://gwt-review.googlesource.com/1200 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Id7d11a11bd9d454b8ed8a2b39d3ca302ae0623d6 Gerrit-PatchSet: 3 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Thomas Broyer t.bro...@gmail.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-HasComments: Yes -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
On Sat, Mar 16, 2013 at 3:09 PM, Daniel Kurka kurka.dan...@gmail.comwrote: I am a little confused about some issues I encountered on the issue tracker and need some help. This one is about a static field on a JSO: https://code.google.com/p/google-web-toolkit/issues/detail?id=8060 From the docs: Overlay types cannot have instance fields. The fields would have no place to live in web mode. Programmers should instead make an explicit wrapper class and put the fields there. JavaScriptObjects are created in JavaScriptCode (this is why they need a at least protected constructor). Do we have a clinit for JSOs or am I assuming correctly that this is a misuse of a JSO? JSOs can't have clinits, since generally they are created by pure JS code, and in particular it is likely code outside of GWT's control. You conceivably could allow default-initialized static fields (which would basically just be namespaced globals), but I'm not sure what the point is. I suppose you could also allow static finals that are just compile-time constants (hoisting initializers to always happen has been discussed, but could potentially execute expensive code at startup), but I think it is better to leave it out than to have only partial support. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
On Sat, Mar 16, 2013 at 5:30 PM, Colin Alworth niloc...@gmail.com wrote: The problem with this answer is that the failure is silent and surprising for Java developers, and that the optimizations can make it even more so. If I recall correctly, calling a static method in the same type from an instance method is not enough to get the static initializer called - an optimization prunes the clinit. I have a patch that restores clinits from instance methods, but I'm out of reach of it at the moment. I haven't made a code review yet in the interest of adding tests for this case. I don't see how you can add clinits on a JSO -- the point is it is a plain JS object under the hood (ignoring all the magic to make it work in DevMode). If you call a method or access a field from pure JS, how can it know to call the clinit? If we do decide that cl units should be pruned, we should stop cutting them from other newly 'static' methods - at least in that case bit must be a bug. If not that, then emit a warning? I'm fine with making it an error. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
