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
, 2013 4:43:13 PM UTC-5, John A. Tamplin wrote:
On Sat, Mar 16, 2013 at 5:30 PM, Colin Alworth nilo...@gmail.comjavascript:
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
On Thu, Mar 21, 2013 at 9:24 PM, Stephen Haberman
step...@exigencecorp.comwrote:
Also we can use this as an opportunity to provide a compatibility
layer across different vendors and/or different widget systems.
I suppose, technically yes. That is more complex than what I really had
in
Colin Alworth has posted comments on this change.
Change subject: Use JSON.parse() instead of eval() to deserialize rpc
callback payload
..
Patch Set 1:
(1 comment)
The ServerSerializationStreamWriter will also need
Colin Alworth has posted comments on this change.
Change subject: Add hasClassName method in com.google.gwt.dom.client.Element
..
Patch Set 3: Code-Review-1
As an idea, looks good, but remember that JSOs are a particularly
What are we looking at having in these interfaces? The discussion that
Goktug and I had a few months ago got stalled around the concept that these
interfaces were trying to both be a) implementation independent but also b)
rich enough to be useful. Doing both is hard/meaningless.
To pick an
Slight follow up to both Stephen's comments here and my own prev post - If
the interfaces are for existing, standard, built-in GWT widgets, type 2
makes a lot more sense, whereas for type 1, we really seem to need a
general, ideal button that can be replaced by any implementation (with
possibly
Colin Alworth has posted comments on this change.
Change subject: Add hasClassName method in com.google.gwt.dom.client.Element
..
Patch Set 6: Code-Review+1
Nope, we can work with it - a wrapper isn't really an option, since
Colin Alworth has posted comments on this change.
Change subject: Add hasClassName method in com.google.gwt.dom.client.Element
..
Patch Set 6:
Thanks Goktug - one of the distinct advantages of extending Element is that
we
Colin Alworth has posted comments on this change.
Change subject: Add interfaces for widgets.
..
Patch Set 6:
(4 comments)
File user/src/com/google/gwt/dom/client
Colin Alworth has uploaded a new change for review.
https://gwt-review.googlesource.com/3361
Change subject: Ensure clinits get called for JSO instance methods.
..
Ensure clinits get called for JSO instance methods
Colin Alworth has posted comments on this change.
Change subject: Ensure clinits get called for JSO instance methods.
..
Patch Set 1:
Afraid not, this is the exact same patch we looked at - only difference was
that I pulled
: 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
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Colin Alworth has posted comments on this change.
Change subject: Ensure clinits get called for JSO instance methods.
..
Patch Set 2:
(2 comments)
File user/test/com
Colin Alworth has posted comments on this change.
Change subject: Ensure clinits get called for JSO instance methods.
..
Patch Set 2:
(1 comment)
File dev/core/src/com
Colin Alworth has posted comments on this change.
Change subject: Add interfaces for widgets.
..
Patch Set 8:
What is the thinking for the remaining 10%-ish of widgets - all of the cell
widgets (except CellPanel), remaining
Nice writeup. Comments/questions (since comments seem disabled in the docs):
* @Entry looks great - there has been some discussion in IRC about some
way to do this for easier library wrapping code, but every direction we
looked at with JSOs ended up with a little more cruft than we really
I got a tweet from you asking for a donation (or rather a 'partner', which
apparently means 'money'), but couldn't frame a useful response in 140
chars, so since this thread is coming back, I thought to do so here
instead.
What license are you offering these code samples under - if it isn't
Shortly after 2.5.1, the Benchmark classes were removed from GWT
(https://gwt.googlesource.com/gwt/+/39eb6001a037fd8b6580a73a2540e6e9c04e54c2
and
https://gwt.googlesource.com/gwt/+/00c7ce43df3a629b7302ab902a07431db7224e2b)
- what are folks using for low-level performance testing these days?
I'd be interested in helping with either approach. The phloc-css project
looks interesting if we are only trying to add support for newer CSS
features, while integration with Closure Stylesheets seems geared more
toward extending the CssResource featureset. Much of the existing
functionality
for support.
On Tue, Aug 27, 2013 at 3:24 AM, Thomas Broyer
t.br...@gmail.comjavascript:
wrote:
On Tuesday, August 27, 2013 1:42:35 AM UTC+2, Colin Alworth wrote:
I'd be interested in helping with either approach. The phloc-css
project looks interesting if we are only trying to add
I've got to second Thomas on this point - adding a new user.agent is very
non-trivial at least without an overhaul of CssResource generation. In GXT
3 we took the route of providing our own PropertyProviderGenerator and
adding a few new user agents (ie7, ie10 for a start), but quickly found
that
an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
commit 6969765b5b60731f12ce529bbc6f730922b7e817
Author: Colin Alworth niloc...@gmail.com
Date: Tue Sep 24 18:29:13 2013 -0500
Initial work on supporting
plugins. However, I believe Firefox 24 will be an ESR
release so I think it's worth rebuilding that version.
On Tue, Sep 24, 2013 at 4:31 PM, Colin Alworth nilo...@gmail.comjavascript:
wrote:
I spent a little time this weekend learning how to build firefox plugins,
and a little time spilled
it
can install an onunload handler. It does preserve the old one but it still
seems kind of fragile to install one in the devmode.js. I wonder if there's
some way to detect the unload event in C++?
- Brian
On Tue, Sep 24, 2013 at 5:25 PM, Colin Alworth nilo...@gmail.comjavascript:
wrote
Its never too late - I don't know how far Julien has gotten, but I've been
distracted by other work, as well as trying to nail down conceptually where
GSS meets ClientBundle.
For my part, SASS or LESS are a major step down from what we already have -
the purpose of GWT in general is to let you
It looks like a recent commit that removed some deprecated methods may not
have gone far enough, as there is still code that makes use of those
methods - the
https://gwt.googlesource.com/gwt/+/f9630059081921b195ee4f7014e1a78c4b570f79
commit dropped several methods from Tree and TreeItem, but
According to the the gwt-site git repo (at
https://gwt.googlesource.com/gwt-site/+/master/src/main/site/javadoc/latest),
the package-list file is present, but it can't be downloaded from
http://www.gwtproject.org/javadoc/latest/package-list. It *is* still
available from
Just wandered by https://gwt-review.googlesource.com/#/c/1040/ and noticed
that with this change, any downstream generator/linker using the static
helper methods in Name will no longer build across 2.5.1 to 2.6.0. With the
other discussions going on about JRE and browser support, perhaps we
I end up debugging IE in dev mode on a regular basis as well, though in a
VM, through to my host OS's Eclipse or IntelliJ debugger. It is
significantly slower than running the IDE and browser on the same OS, but
it does let you set up your env once and debug multiple OSes whenever you
like.
On
Patrick, looking at these, only two appear to have code reviews, and both
are in the pre-git system. Gerrit, the current system, needs a CLA before
it allows changes, to make sure that there are no copyright/licensing
issues with contributions, and makes history/change management a little
Tentative patch up at https://gwt-review.googlesource.com/5063 - can
someone sanity check it for me? It looks like step 4 (now step 3) should
have previously been pointing to step 3 (now step 2), so is now more
correct.
On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote:
Thanks
If only *all* of my changes were that easy to make...
On Tuesday, October 22, 2013 8:15:12 AM UTC-5, Andrés Testi wrote:
Thanks Colin! I'm glad to see the power of the community in action :-)
- Andrés Testi
El lunes, 21 de octubre de 2013 19:59:53 UTC-3, Colin Alworth escribió:
Tentative
Amazingly, it still works great in the IE11 preview too! Only gotcha is
that the missing plugin page thinks you are running firefox, so you need to
manually grab the right copy of the IE plugin.
On Tuesday, October 22, 2013 12:58:57 PM UTC-5, Brian Slesinsky wrote:
I expect that by next
I've just put up a patch that seems to resolve a current issue in deploying
snapshots to a maven repository: https://gwt-review.googlesource.com/5192
The basis of the problem requiring this patch is that maven (at least maven
3, possibly not maven 2) expects unique snapshots, and that each call
I can't reproduce this, we're also running ant clean elemental dist on our
teamcity build. We're also running ubuntu 12, python 2.7.3. Last confirmed
building as of 0d6a865556ca56840114e8397a1f2be522e83361 (current HEAD).
On Monday, October 28, 2013 5:43:04 AM UTC-5, Jens wrote:
I just tried
Good thought, I tried that too to confirm that teamcity wasn't setting
anything funny. Still passed, not sure what is up.
Other details that may or may not help:
$ java -version
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10)
Java HotSpot(TM) Server VM (build
It looks like while I can get maven from the command line to get along with
that repo, IntelliJ isn't having it - it is getting confused by the fact
that the latest gwt-user snapshot 2.6.0-20131105.081128-3 only has a
sources jar and a pom, no actual jar with compiled code in it. The -1 jar
is
...@google.com wrote:
Thanks for testing, Colin! I'll try another push tonight using your
scripts.
On Tue, Nov 5, 2013 at 5:14 PM, Colin Alworth niloc...@gmail.com wrote:
It looks like while I can get maven from the command line to get along
with that repo, IntelliJ isn't having it - it is getting
/MojoExecutionException
Error while deploying, ignore errors? (y/N):
I'm going to root cause what's going on, but maybe you have an idea
what's going on?
On Wed, Nov 6, 2013 at 1:49 PM, Colin Alworth niloc...@gmail.comwrote:
Just moved to eclipse to verify a possible issue with the snapshot
(nope, bug
. Snapshots are the
other way around, you are allowed to update snapshots, as well as remove
stale ones.
On the plus side, the -SNAPSHOT build looks to be working great from my
testing.
On Wed, Nov 6, 2013 at 7:07 PM, Matthew Dempsky mdemp...@google.com wrote:
On Wed, Nov 6, 2013 at 4:54 PM, Colin
-2.6.0-rc1.zip
(Next up the Maven 2.6.0-rc1 artifacts.)
On Wed, Nov 6, 2013 at 5:07 PM, Matthew Dempsky mdemp...@google.comwrote:
On Wed, Nov 6, 2013 at 4:54 PM, Colin Alworth niloc...@gmail.com wrote:
My vote is 2.6.0-SNAPSHOT and 2.6.0-rc1, in case we need a bug fix
release... Being
I'm not yet convinced that this isn't either a) a workspace issue or b) a
decision the community reached and I missed, but I figured I should stick
it out there and see if someone can correct me.
I've just brought our project up to date with GWT 2.6.0-rc1 from maven, and
I can verify that the
-500-9148
On Fri, Nov 8, 2013 at 3:31 PM, Colin Alworth nilo...@gmail.comjavascript:
wrote:
I'm not yet convinced that this isn't either a) a workspace issue or b) a
decision the community reached and I missed, but I figured I should stick
it out there and see if someone can correct me
, at 17:47, Colin Alworth niloc...@gmail.com wrote:
Thanks Roberto, I'll give that a shot. I normally work with Java 7, but we
want our code to work with anyone who chooses to use Java 6 as well - and I
surmised that GWT had the same goal.
Would it make sense to consider a warning indicating
There is a workaround - I'm on my phone now, but I posted it in the bug
report. Essentially you can tell the plugin to not worry about invalid
SDKs, and either mark then as merely errors, or just ignore it entirely.
With that set, we've noticed no other I'll effects so far.
On Nov 17, 2013 12:29
Just to confirm, the plan is to set this in master as well as releases/2.6,
and this will go out in 2.6.0-rc2?
--
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
What's the current thinking on removing ImageResource.isStandalone from
2.6.0 final, as in the https://gwt-review.googlesource.com/#/c/5504/ review?
It isn't in GWT 2.5.x, and isn't in master, but is present in both
2.6.0-rc1 and 2. If it was an oversight to add this the first time around,
I'm still running into trouble with the major version of the compiled
classes being 51, so I'm unable to gwt 2.6.0-rc3 to work under jdk 1.6. As
before, I was able to confirm that the actual .class files are compiled
correctly, but yet I get fatal errors in attempting to run dev mode.
Testing
(and in that case
probably is consistent that the version is 51.0).
I build from scratch in my laptop (only has java 1.6) and builds and tests
run fine. Is there a specific application that you are trying to build?
On Thu, Dec 5, 2013 at 9:23 PM, Colin Alworth nilo...@gmail.comjavascript:
wrote
:
It seems that we need to build the release with -sourceLevel 6 for it to
work with Java 6.
On Thu, Dec 5, 2013 at 10:43 PM, Colin Alworth nilo...@gmail.comjavascript:
wrote:
Sorry for being unclear - I'm building/testing an application that makes
use of GWT while still on Java6, not building
This system property isn't listed when either dev mode or the compiler runs
because it is a system property, not a program arg. It should be provided
with the other VM args when you start Java. These aren't listed as part of
the normal properties, but are documented here:
Another thought: Christian Sedilek, Dan Kurka, and myself can also be found
pretty frequently in ##gwt on irc.freenode.net for a more informal
discussion - I'd love to see more steering committee members hang out
there, even if just idling most of the time, and chatting once in a while.
Something funny has happened to the dont-reload-the-page code on
gwtproject.org, but I'm not seeing any obvious commit that should have done
this.
Steps to repro:
1) visit http://gwtproject.org/, or any *top level* document
2) observe that any link you hover looks to be correct, and visiting
The concern I've heard expressed during in-person discussions about how to
do this is that a written document of answers 'feels' more real and
concrete than a group of people answer questions live, since they clearly
have no chance to vet their answers from their own organization or with
each
Another set of dangerous code to look for would be any SafeHtmlUtils or
SafeHtmlBuilder (and their uri/style conterparts) call that should take
'constant' or 'trusted' but instead takes untrusted user data. Custom
implementions of SafeHtml should also be treated as suspect.
These all fall
For JSON, you'd have go pretty far out of your way to get attacked, like
loading something untrusted via JSONP, or manually parsing your own json
with eval (rather than any of the safe built-in tools), or, ya know,
forgetting to run SSL and having someone intercept your server
communication.
If you know enough to start writing generators, it almost certainly is not
a concern - you are probably also careful with which GWT version you are
using as well as which gwt-m-p version. A problem can occur if more than
one version of gwt-dev is present on the classpath, such as a mistakenly
Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, but
I've also seen this trying to understand the general compiler changes that
are happening in trunk gwt - is the CompilerContext really an essential
part of ModuleDefLoader in general? From what I can see it is tracked as a
:
On Mon, Feb 10, 2014 at 2:57 PM, Colin Alworth nilo...@gmail.comjavascript:
wrote:
Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by,
but I've also seen this trying to understand the general compiler changes
that are happening in trunk gwt - is the CompilerContext really
In CrossSiteIframeTemplate.js this is handled by assigning
__MODULE_FUNC__.__softPermutationId to 0 to begin with, and then only
change that value if : was present in the permutation string. I'm not
seeing any other js files that init __softPermutationId to 0, and only
permutations.js assigns
Only note to add here is that the AngularJS project does require a CLA also
(see https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#cla)
- it looks like they either have a bot which complains about missing CLAs
on file (and so some associated between username and real name), or a
This seems to be a pretty quiet discussion so far, with mostly Zied
responding to himself and Thomas’s one initial reply, but it is a holiday
weekend here in the US, so that might be contributing to the lack of
additional responses. I haven’t had the chance to even look at the initial
proposal
I've just opened https://gwt-review.googlesource.com/7780 to make it
possible to specify a fallback for any/all useragents that don't match one
of the built-in rules, via a rule like:
set-property-fallback name=user.agent value=webkit/
This example rule treats any unknown useragent as if
Sorry, that first line should say 'safari' (or any other valid user.agent
value), not 'webkit'. Wishful thinking perhaps...
set-property-fallback name=user.agent value=*safari*/
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe
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
AutoBeanFactorySource also made it in there) - does that
seem like a reasonable step?
On Mon, Jun 9, 2014 at 6:22 PM, John A. Tamplin j...@jaet.org wrote:
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
:
On Tuesday, June 10, 2014 12:33:40 AM UTC+2, Colin Alworth 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
I’m trying to bring https://gwt-review.googlesource.com/#/c/3361/ up to
date, and after rebasing and fixing a few whitespace nits I tried to run
the tests by they failed. Concerned that I had broken something I backed
off to current master, and ran tests again. First I did a clean dist-dev in
With some help from Jens Nehlmeier over in ##gwt, it looks like there are
two distinct issues preventing the build from passing presently The first
is that the class ImmediateCompileFails does in fact cause problems with
compiling - the simplest fix was to tell the compile.tests target to leave
Sounds great, but is there a reason that we're now starting at IE9+ and not
IE10+, thus giving us typed arrays, web workers, web sockets, etc? I only
ask because the kind of case where you are giving up User (and Widget, RPC,
Timer, and other fairly high-level apis) seems to suggest that you
PotentialElement seems to be one of those ghost features that was never
finished, or at least never correctly documented, so might as well be half
done:
EXPERIMENTAL and subject to change. Do not use this in production code.
We've never used it, and I've only encouraged people to stay away from
, Goktug Gokdogan wrote:
On Mon, Jun 30, 2014 at 8:46 PM, Colin Alworth nilo...@gmail.com
javascript: wrote:
Sounds great, but is there a reason that we're now starting at IE9+ and
not IE10+, thus giving us typed arrays, web workers, web sockets, etc? I
only ask because the kind of case
I think Alain's use case is a legit one, and the SmartGWT product probably
also lives in that world to an extent - let the user write Java that mostly
interacts with JS libraries, and let them worry about which browser is
running, but compile the code to run anywhere. I can't speak to their
'older
For what its worth, we use a slightly different snapshot url:
https://oss.sonatype.org/content/repositories/google-snapshots/. This
appears to only contain snapshots instead of releases and snapshots.
The /google/ url for whatever reason has a newer md5 and sha1 for the
maven-metadata.xml file,
As I'm sure everyone is aware, IE11 is making the navigator.useragent
property significantly more useless than it already was, by having IE11
identify as 'Trident' rather than 'MSIE', and adding 'iPhone', 'Webkit',
'Android' and a few other obviously garbage strings.
Check out
Its possible that we can get away without an explicit way to add this (like
classic Dev Mode has done so far), but -src makes multi-project development
so much saner. No longer do you need to depend on your IDE to do the Right
Thing (i.e. use *that* project as a jar from local maven repo, but
The 'test runner' in this case is just the name of a regular module file,
which happens to be used for running lots of tests, most of which look like
EntryPoints. Nothing too magic going on here, and I've gotten this error by
running modules for more 'normal' gwt apps as well, typically when I
I also can reproduce this - when style is set to PRETTY, 4 of the 17
permutations starts off with the PRETTY setup code (from the linker?), then
moves on to have all obfuscated (and sorted, etc) JS from the compilation
process:
var $wnd = $wnd || window.parent;
var __gwtModuleFunction =
It looks like changes to a few rebind rules are generating some new logspam
when any GWT app compiles. Specifically, I'm seeing FocusImpl and
LayoutImpl, though its possible there are others I haven't seen yet. From
the dynatable example we can see the FocusImpl spam:
gwtc:
[java]
sounds good to me. Please add a comment to the
binding; it might probably be bound to something else but not tested.
On Wed, Oct 1, 2014 at 9:39 PM, Colin Alworth niloc...@gmail.com wrote:
It looks like changes to a few rebind rules are generating some new
logspam when any GWT app compiles
https://code.google.com/p/google-web-toolkit/issues/detail?id=8716 is still
open (and is a regression over GWT 2.6 and previous). Is this a reasonable
item to get fixed?
On Wednesday, October 1, 2014 2:23:43 PM UTC-5, Brian Slesinsky wrote:
- Make sure sample apps work with DevMode
I've just submitted a shallow removal of IE6 specific code in
https://gwt-review.googlesource.com/#/c/9513/ - this patch starts with all
.gwt.xml files that mention the user.agent value ie6 and removes those
property checks, along with any classes *only* referenced from those rebind
rules. Far
Sorry for the thread necromancy, but aside from
https://groups.google.com/d/topic/google-web-toolkit-contributors/90PSQ7wKHtI/discussion
this was the only relevant existing conversation I could find on the topic.
In GWT 2.6 user.client.Element was finally deprecated, though done in a way
to
will
break, I promise (Splittable.removeReified, removed logger classes breaking
.gwt.xml, required resource tags causing warnings, etc).
On Wednesday, October 8, 2014 4:15:10 AM UTC-5, Thomas Broyer wrote:
On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote:
Sorry
On Wednesday, October 8, 2014 5:16:18 PM UTC-5, Thomas Broyer wrote:
On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth nilo...@gmail.com
javascript: wrote:
Not quite. Anything that continues to return user.client.Element can only
be overridden to return user.client.Element or a subclass
, Thomas Broyer t.bro...@gmail.com wrote:
On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth niloc...@gmail.com
wrote:
Not quite. Anything that continues to return user.client.Element can
only be overridden to return user.client.Element or a subclass.
Ha, didn't thought about subclassing w
It is also possible that there is a stale copy of .java resources on your
classpath, such as in target/classes/ for a maven project - we've seen that
get in the way as well. Make sure that either target/classes/ isn't on your
classpath, or that it doesn't have another (stale) copy of whatever you
I don't recall if inherited modules are loaded more than once - in other
words, if one of the higher up modules (like BaseGWT) already inherited
BaseBrowsers, then a later module added ie10 via extend-property, it might
not be possible to re-inherit BaseBrowsers and have it re-set user.agent
down
Are you planning on being at either GWT.create event? I know several people
(including myself) who will be there and would be happy to help.
Otherwise, there are several contributors in ##gwt on irc.freenode.net who
would be able to help with this process.
On Mon Jan 19 2015 at 4:44:01 AM
Its not that 3k is huge, its that it would be (to a developer, accustomed
to GWT's policies) massively larger than normally expected for built-in
methods. Just ran SOYC on a project (OBF but not closure), and the largest
java.lang.String method is 466 bytes, greater than twice the size of the
next
I'd be strongly in favor of a StringFormat class - this could be
library-ized easily, letting someone opt in to even having it in their
project, or call it.
Since we're changing the API (though I assume keeping the 'format string'
language), you could take other steps to ensure small complied
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
Getting offtopic, but there is absolutely no requirement that JSO methods
are public. See dom.client.Element for several examples of private methods.
On Mon, Mar 30, 2015 at 10:27 PM James Nelson ja...@wetheinter.net wrote:
Ok, great. Thanks for the heads up. I was pretty sure that Strings
There is a document outlining which maintainers exist for various parts of
GWT, designed to suggest an initial reviewer or reviewers for a new
patch/bugfix/feature.
https://docs.google.com/document/d/1vyncxfuujIJ3L-PBLNM68tfeXRFZ4qDdnWEodblmvRg/edit
This list is in the top (stickied) post in
Without GC, I think its going to be a bit of a non-starter - the same
issues that apply to compiling to asm.js apply here too. I've heard a few
ideas floated around to just compile specific methods to asm.js, and those
same ideas seem that they could work, but the really hard part is isolating
Paul, do keep in mind that the latest in git (and the 2.8.0-SNAPSHOT in
maven) is fairly stable. Some projects (for example, everything that Google
makes) live off of trunk, and many projects upgrade to a snapshot, test
that things are sane, and then 'pin' that build internally to keep running
As this isn't a NPE (or a type error, which I think is the JS equivalent),
the we're missing a step here. You are seeing an UmbrellaException thrown,
which means not that the handlermanager or event wiring broke, but that
your own handler threw the exception (i.e. the 'TypeError' described in the
If I could be permitted to slight restate what Julien just said: We will
make a note of it, as we have done in the past, such as when the default
moved from java6 to java7:
http://www.gwtproject.org/release-notes.html#Release_Notes_2_6_0_RC1. That
being said, we of course welcome any community
Sorry, I hadn't understood that your primary interest was in release dates,
but though it was more for compatibility with upstream or related tools on
release. That said, I think that the list of downloads at
https://code.google.com/p/google-web-toolkit/downloads/list may prove
useful for
1 - 100 of 247 matches
Mail list logo
