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

[Stephen Haberman]

I'll try to keep it short...

> When I’m trying to find out why my presentation layer DOM element didn’t
> receive some DOM attribute as result of computation, this is bug in the
> presentation layer, which was abstracted together with browser in your
> approach
>
Yes, you can assert/debug against presentation-layer/DOM element values
with a Tessell-style approach very easily, as that's the whole point
(asserting that when user does X on DOM element Y, then the DOM looks like
Z).

Tessell (or similar) does not replace/remove the presentation layer, it
just decouples it from the browser, by replacing the C++/whatever DOM impl
(that you only get if you boot up Chrome or FF or PhantomJS or what not)
with a pure-Java DOM(-ish) impl.

I want to develop/debug the app which looks like html app, not generic app!
>
Tessell (or other "modern GWT") apps are just HTML apps, they do not use
the generic UI widgets like the Qt/mobile things you mention; see the
todomvc example which looks like every other todomvc impl. It's all
markup + CSS just like Angular/Ember/etc.

the size of test code (excluding declaration and syntax lines) is 5-6
> lines, whereas logic being tested is 3 lines
>
Unit tests in Tessell projects are unusually small/simple from what I've
seen (primarily due to using stubs, they don't have a lot of the repetitive
when/when/when setup that comes with mocks), but if you're using a "unit
tests add too much code to maintain" line of thought, then you're probably
not going to be writing tests anyway. Which probably explains why you need
such a great debugging experience. :-D

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/CANnRKuWq2HmwSTDJBPwbOq1-4Osg8vdswW60sZqYqO%3DngVzx3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Stephen Haberman]

> This community needs more people *doing* stuff.

Agreed (although I'm calling the kettle black here).

I think historically GWT was really hard to contribute to; as you said, it
was a single toolkit, and had a lot of complexity in it (non-trivial
optimizations, non-trivial old browser support, etc.).

My hope is that the just-a-transpiler approach of j2cl will also make it
easier for a community to spring up around it. (And for separate small
communities to spring up around whatever j2cl-based RPC, j2cl-based UI,
j2c-based etc. libraries and frameworks come along.)

- Stephen





On Sun, Jan 15, 2017 at 8:51 AM Ivan Markov  wrote:

>
> Thank you, GWT people, for spending your time answering my thoughts.
>
>
> To summarize (and TLDR), these were responses in the thread:
>
>
> Ivan Markov: We should improve javascript-side debugging to match DevMode.
>
> Jens: Google is busy doing other things, so no hope with gwtromium.
>
> Jens: Change your attitude towards SuperDevMode. Also, DevMode was not so
> cool.
>
> Arnaud: Don’t believe what I said in article! // thanks Arnaud, I’m better
> now ;)
>
> Arnaud: TCP via localhost is fast enough
>
> Thomas Broyer: Even moving towards Typescript in GWT architecture, there’s
> still big value of Java as language due to code reuse.
>
> Thomas Broyer: js-java glue that was related to codeserver for DevMode is
> already in rotten state.
>
> Stephen Haberman: Abstract away browser and debug in JVM without browser.
>
>
> I will respond here in one message to each of these points:
>
>
> Ivan Markov and Jens, there’s a lot more to JVM debugging that stepping
> and seeing the source. This is "drop frame", hot code reload, evaluate Java
> expression (before deciding whether I should step into or over function
> “verifyCondition(x1.var1, x2.var2)” I evaluate it in expression evaluator
> first to check whether it’s valid – not working with java code in front of
> me in IDE, when JS being evaluated). Also: breakpoint skip count and
> specified exception breakpoint; field access breakpoint; something else
> obvious so much that I even can’t specially recall. I code in java since
> long ago, and these features are just common tools for me, hardwired into
> the muscles, and this makes SuperDevMode looking like a toy. Last time I
> checked, source maps do not map even variables names (not mentioning
> scopes), and, knowing the pace of its development, I don’t give much hope
> to that. Integration of JS debugging into IDEs can't help much with all
> this. Saying all above, I see your (and similar people) favorable attitude
> towards SuperDevMode coming from both low expectations [1] of what good
> debugging is and maybe (sorry!) from excessive self-convincing that
> SuperDevMode is super, due to apparent lack of alternative (which I try to
> change by idea of gwtromium).
>
>
> [1] I’m aware of two opposing attitudes toward debugging, best illustrated
> by systems-level embedded programmers which usually can afford only
> printf() and must put most effort in writing code that works correct in
> first place (this influences their thought process and attitude even after
> they move to upper levels), as opposed to high-level programmers which can
> literally edit-and-continue most of their time.
>
>
>
> I openly admitted that the current GWT debugging experience sucks so I'll
> pass on your Java-debugging-is-so-much-better eye opener.
> As for GWT "no longer stretching the limits"... while I sympathize your
> emotions, the battle is lost. A single toolkit can't possibly keep up with
> all the innovation on the JavaScript front, so they either need to have a
> very good jsinterop + lightning fast transpiler (ASAP!!), or Java in the
> browser will die.
>
> Now to the concrete topic of GWT debugging:
> Unfortunately, Google seems to have other priorities right now so we are
> on our own for anything besides the core compiler (cough, transpiler).
> So as Jens said - screaming out loud won't help. If you really want to
> make a difference - invest your time, swim against the current and
> prototype the gwtromium thing (or help improve the sourcemap debugger - a
> lost of what you mention about native Java debugging is possible to
> implement with enhancements to the sourcemap debugger).
> This community needs more people *doing* stuff.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT 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-t

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

[Stephen Haberman]

FWIW my answer to "I want a really awesome debugging experience" is that
you shouldn't be doing any debugging in the browser in the first place,
e.g. whether it's old-school DevMode or SuperDevMode or Typescript etc.

This is what Tessell allowed (apologies for the self-promotion, although I
am mentioning it less as "you should go use it" and more as "no really this
approach is technically possible and works well") by stubbing out the DOM
with pure-Java equivalents.

Granted, you're now running against an abstraction level, so without a
browser (e.g. in a pure Java unit test) you can't do any pixel calcs or
intimate rendering logic, but the majority of your app shouldn't be doing
that anyway (or any at all since most munge-pixels-with-JS can be done by
adding/removing CSS classes these days).

With Tessell (or whatever Tessell equivalent), you can get to the point
where 95% of your development time is in pure Java unit tests, running your
presenters, your views, whatever, as regular Eclipse-is-none-the-wiser
JUnit tests, and making sure "yeah, the DOM 'looks' like I think it should"
(where 'look' is not you-see-it-with-your-eyes, but
the-markup-matches-what-I-want) . Then the final 5% of your development
time is popping open the browser, and tada it will all magically work.

If it doesn't, yeah sure, you spend ~5-10 minutes in
SuperDevMode/sourcemaps figuring out why, but then as soon as you reproduce
it, you usually can reproduce it in a pure-Java unit test against your DOM
abstractions, and you're back to an amazingly quick TDD cycle; no
sourcemaps, no browser debugger, no waiting for DevMode or SuperDevMode to
load.

So, that is my answer to "I really want old-school DevMode": you should put
the right abstractions in place to where your app is not coupled to the
browser in the first place. If you're coupled to the browser, you've
already lost IMO.

(Granted, if you've already got a large codebase that is not written
against this sort of abstraction, it's not going to be easy to move, so
this is probably not very helpful to you.)

- Stephen







On Fri, Jan 13, 2017 at 6:52 AM CodeLess  wrote:

> IMHO @Ivan's second suggested approach would be a perfect solution: 
> "implementing
> Java watch expressions and conditional breakpoints in Eclipse SDBG".
> Hopefully this will be possible to realize and hopefully gwt
> contributors/maintainers will be willing to cooperate with @Ivan about this
> idea.
>
>
>
> On Fri, Jan 13, 2017 at 12:36 PM, Thomas Broyer 
> wrote:
>
>
>
> On Thursday, January 12, 2017 at 10:43:57 PM UTC+1, sannysan...@gmail.com
> wrote:
>
> Hello, GWT people.
>
> 
>
> GWT got its popularity because it allowed DevMode in the browser (run java
> in VM in browser, manipulate DOM, use your IDE!). In fact, the GWT project
> appeared as clever hack on hack on hack to stretch limits of possible, to
> be ahead of its time, and that was cool. Nobody did that before. Now GWT
> turns into much like... i don't know, more like typescript compiler. No,
> really, with announcements like those "Let’s examine
> 
> the parts of GWT doomed to extinction: generators, Widgets, GWT-RPC,
> UiBinder …" it's just another typescript. Typescript also looks like
> Java! Its transpiler is and will always be faster than GWT. There's no
> reason for GWT to be anymore.
>
>
> You're right, GWT turns more and more into a TypeScript/Dart-like, with
> one major difference: the input is Java.
> This means it can run in a JVM, i.e. be shared with your server-side code
> and/or your Android native app, and possibly transpiled to ObjectiveC for
> use on iOS (which is exactly what Google does: sharing 70% of code between
> all versions of Inbox, sharing Google Sheets formulas' parsing –and
> execution?– between client and server –and Android?–, etc.)
> With Dart or TypeScript you need to bring a DartVM or JS Engine to run the
> code.
> And that's without talking about the tooling you get with Java too, that
> has to be rebuilt for all those newer languages (linting, refactoring, code
> generation by analyzing the AST –annotation processing– etc.)
>
>
> And there's no GWT events, reddit comments on its announcement are like
> 
> "oh, it's still alive?".
>
> So while GWT is essentially already dead for me with removal of DevMode (I
> understand this removal happens because of browsers architectural changes,
> not because the idea failed), I still think about various workarounds.
>
> 
>
> I remember, in GWT 1.0 special mozilla-based internal browser was shipped
> with GWT. It was long before GWT DevMode plugins for all browsers. And
> nobody thought it's bad option, although it didn't support SVG which was
> already in firefox, canvas, etc. It was the way to go. IT WAS the cool part.
>
> With 

Re: [gwt-contrib] Re: Future direction for common JS api's

[Stephen Haberman]

Interesting; I had not seen JSweet before.

The javac -> TypeScript -> JS approach is surprisingly parallel (albeit
with different selections) to J2CL's ecj -> closure -> JS.

- Stephen



On Wed, May 18, 2016 at 8:50 AM Jens  wrote:

> Given that Elemental 2 is developed behind closed doors, I would guess it
> can take TypeScript definition files and/or some IDL input to generate JS
> APIs for GWT / J2CL. That should cover nearly all Web APIs.
> IMHO TypeScript definition files would be preferred because there are tons
> of them on https://github.com/DefinitelyTyped/DefinitelyTyped for all
> kinds of JS libraries and Web APIs. It also has a definition for the Fetch
> API:
> https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/whatwg-fetch
>
>
> It would be a shame if Elemental 2 would not understand them to generate
> APIs. These files are basically what JSweet uses to generate their Candies (
> http://www.jsweet.org/candies-releases/). But even if Elemental 2 only
> takes IDL input or html5index.org as input it should cover all standard
> web APIs.
>
> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/c72a2088-bc6a-4836-9312-518ec56507cd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: Generator and Linker maintenance and changes

[Stephen Haberman]

I agree with Thomas and Daniel that it's good to avoid putting more
"official" work into the generators, and encouraging people to move off.

But I think I agree more with Colin and Jens that, one way or another,
people are using generators today, and will be using them for awhile (e.g.
if they purposefully choose to stay on a GWT 2.8-based lineage), and it
seems unfair to deny them improvements that they themselves want to make to
the generators.

So, if Colin has a few patches waiting in the wings, or if people wander in
with "hey, I made this incremental improvement to a generator", it seems
"un-open source" to say "sorry, you should be doing something else".

I base my opinion mostly on the healthiest open source project I've ever
seen: Apache Spark, where (at least in the early days), the committers were
extremely wiling to accept patches about whatever itch you wanted to
scratch (although still with tests/quality/etc.). (Granted, they were
technically trying to win political points by "having as many contributors
as Hadoop", but even if that was their core goal, the side affect of a
healthy community was pretty nice.)

So, that's my only "post every 6 months" $0.02: if people have itches with
the current generators, let them scratch it. That is what open source is
about, IMO.

- Stephen



On Tue, May 3, 2016 at 3:40 PM Paul Stockley  wrote:

> I don't think migrating away from Generators to APT means you are forced
> to move off 2.8. In fact, I was hoping to move incrementally as each
> subsystem is migrated to become APT based. Then in the future, our code
> base would be close to moving to J2CL. In a couple of months or so I was
> planning on starting some prototyping, probably around replacing UiBinder
> and Resources.
>
>
> On Tuesday, May 3, 2016 at 6:13:17 AM UTC-4, Daniel Kurka wrote:
>
>> Hi all,
>>
>> thanks for Colin for writing this up.
>> To me this discussion is not so much about the particular feature
>> (enhancing generators), but rather about us making smart choices.
>> We are already struggling to get 2.8 out the door (and making sure it
>> will work with the next version of Guava). So I'd rather be lighten the
>> work load and remove things that do not need to be done
>> I also feel that further enhancing generators dilutes the message we have
>> been giving for the past year: *Do not use generators anymore, use APTs.*
>>
>> I am also worried about possible problems that we will uncover once we
>> allow these things to go into generators.
>> With the exception of GWT RPC all generators should be easily portable to
>> an APT. I would love to see work being put into that direction rather than
>> updating a system we are all not happy with.
>>
>> -Daniel
>>
>>
>> On Tue, May 3, 2016 at 11:59 AM Jens  wrote:
>>
>>>

- add new features to existing generators / linkers


>>> I think to some extend some new features should also be fine if they are
>>> related to Java 8. For example I could see GWT-RPC being improved to better
>>> support lambda/method references in the future.
>>>
>>> -- J.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/1898a4b0-3eff-4e53-8aba-19e1851a646f%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/ff572616-6851-464d-8b9c-4bfa8df031e7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Stephen Haberman]

Hi Goktug,

That's all true, thanks for providing a counter data point. You're right,
the JsInterop design docs/etc. were all out in the open from day 1, which I
thought was pretty exiting.

I definitely can't take any credit for providing useful feedback, but I
enjoyed seeing the thoughts and process from the community.

So, apologies for the sweeping statement.

- Stephen



On Fri, Nov 20, 2015 at 11:58 AM, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Singular is not a Google project and not being developed internally. It is
> Daniel's personal project and as fas as I know it is already in the open
> source.
>
> We don't have anything to share for Elemental yet. We are talking with
> other teams, thinking about alternatives etc. Also when we release, it will
> not be part of GWT-SDK so there is going be extra work to move the
> development outside; which doesn't make sense at this stage.
>
> The big things we recently developed for GWT, JsInterop and SuperDevMode
> and they were all open source from day one.
>
> On Fri, Nov 20, 2015 at 5:34 AM, Stephen Haberman <
> stephen.haber...@gmail.com> wrote:
>
>> > Meanwhile I will revive my own generator project.
>>
>> I'll take the opportunity to hop on a soapbox, but the "closed
>> source/eventually open source" model is a curious trend that I think I've
>> only seen in the GWT community (are their other examples?)...
>>
>> Musing, it probably stems from Google setting the example with GWT
>> itself, where historically a lot happened internally before being mirrored
>> externally, but it happens a bit for non-Google-GWT projects as well, like
>> the repackaging of GPE, which was closed during initial development
>> (although the result is great, and I really appreciate it), Singular, which
>> is still closed during initial development, now Elemental2. I dunno, I
>> find it curious.
>>
>> E.g. with Singular, it's like it's being developed like the next Apple
>> phone; we have to be secret about it, not say anything, so we can have an
>> awesome keynote where we surprise the world with how awesome it is.
>>
>> Granted, I'm sure those keynotes are very fun, but I guess I don't
>> understand, wtf, why not just open source things from day 1? IMO the best
>> case scenario, and most likely, is that you're going to attract early
>> adopters who will a) give you feedback to validate approaches/etc and b)
>> give you free work by tracking down bugs and committing patches.
>>
>> Keeping things closed source "until they're ready", IMO, stifles the
>> potential contributor/committer pool that's needed for the long term health
>> of an open source project.
>>
>> I suppose the risk is people writing a 100k LOC production app on a
>> pre-1.0 project, and then they bitch about changes...but hopefully lots of
>> disclaimers and 0.x release points would help mitigate that...
>>
>> Anyway, that is my soapbox. Or one of them, I guess. :-P Of course, we're
>> all getting this work for free, so everyone is free to do what they please,
>> and I will be very excited and thankful for both Elemental2/Singular when
>> they are available to us.
>>
>> So please don't read this as "bah, that is dumb", but just as "gentle
>> nudge towards open sourcing sooner, if that's okay, thanks!". :-)
>>
>> - Stephen
>>
>>
>>
>> On Fri, Nov 20, 2015 at 6:14 AM, Rene Hangstrup Møller <
>> rhmol...@gmail.com> wrote:
>>
>>> Thanks for the update.
>>> Looking forward to seeing what you have been cooking up.
>>> Meanwhile I will revive my own generator project.
>>>
>>> /Rene
>>>
>>> Den fredag den 20. november 2015 kl. 11.05.44 UTC+1 skrev Julien Dramaix:
>>>>
>>>> It's a bit too early to answer to this question with absolute certainty
>>>> but I don't think I can guarantee the full backward compatibility with the
>>>> first version of elemental.
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT 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/98a1cb61-aafa

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

[Stephen Haberman]

> Meanwhile I will revive my own generator project.

I'll take the opportunity to hop on a soapbox, but the "closed
source/eventually open source" model is a curious trend that I think I've
only seen in the GWT community (are their other examples?)...

Musing, it probably stems from Google setting the example with GWT itself,
where historically a lot happened internally before being mirrored
externally, but it happens a bit for non-Google-GWT projects as well, like
the repackaging of GPE, which was closed during initial development
(although the result is great, and I really appreciate it), Singular, which
is still closed during initial development, now Elemental2. I dunno, I find
it curious.

E.g. with Singular, it's like it's being developed like the next Apple
phone; we have to be secret about it, not say anything, so we can have an
awesome keynote where we surprise the world with how awesome it is.

Granted, I'm sure those keynotes are very fun, but I guess I don't
understand, wtf, why not just open source things from day 1? IMO the best
case scenario, and most likely, is that you're going to attract early
adopters who will a) give you feedback to validate approaches/etc and b)
give you free work by tracking down bugs and committing patches.

Keeping things closed source "until they're ready", IMO, stifles the
potential contributor/committer pool that's needed for the long term health
of an open source project.

I suppose the risk is people writing a 100k LOC production app on a pre-1.0
project, and then they bitch about changes...but hopefully lots of
disclaimers and 0.x release points would help mitigate that...

Anyway, that is my soapbox. Or one of them, I guess. :-P Of course, we're
all getting this work for free, so everyone is free to do what they please,
and I will be very excited and thankful for both Elemental2/Singular when
they are available to us.

So please don't read this as "bah, that is dumb", but just as "gentle nudge
towards open sourcing sooner, if that's okay, thanks!". :-)

- Stephen



On Fri, Nov 20, 2015 at 6:14 AM, Rene Hangstrup Møller 
wrote:

> Thanks for the update.
> Looking forward to seeing what you have been cooking up.
> Meanwhile I will revive my own generator project.
>
> /Rene
>
> Den fredag den 20. november 2015 kl. 11.05.44 UTC+1 skrev Julien Dramaix:
>>
>> It's a bit too early to answer to this question with absolute certainty
>> but I don't think I can guarantee the full backward compatibility with the
>> first version of elemental.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT 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/98a1cb61-aafa-4c80-9c0d-f1a1d4e6bd1d%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

[gwt-contrib] uibinder/safehtml disagreement on xlink:href attribute

[Stephen Haberman]

I'm attempting to use icons in an svg file in a ui.xml file like:



But with a variable, so:



However, because of the xlink namespace (which the browser requires,
AFAICT), UiBinder and SafeHtml end up disagreeing on whether this is a
SafeUri-requiring attribute.

E.g. here is the UiBinder logic, which ignores namespace because it uses
local name:

https://github.com/gwtproject/gwt/blob/master/user/src/com/google/gwt/uibinder/elementparsers/HtmlInterpreter.java#L48

And here is the SafeHtml logic, which does looks at namespace+attribute due
to the underlying jsilver implementation:

https://github.com/gwtproject/gwt/blob/master/user/src/com/google/gwt/safehtml/rebind/SafeHtmlTemplatesImplMethodCreator.java#L301

https://code.google.com/p/jsilver/source/browse/trunk/src/com/google/streamhtmlparser/impl/HtmlParserImpl.java#237

So, it ends up failing because UiBinder generated SafeUri, but SafeHtml
says "this attribute shouldn't be a SafeUri, did you SafeHtml or String".

I'm wondering how to make them agree...while in this scenario it is true
that xlink:href is a URI, so UiBinder was right, in theory there could be
other namespaces where that is not the case, and the heuristic of "any
attribute named href is a uri, regardless of namespace" could be wrong.

Any great ideas?

...I suppose the other option is to just turn off safe html templates for
now.

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/CANnRKuWxgJQeuutcu8PGmFzufA4ZrCZxu60_KbUAsJxobGHbgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

[Stephen Haberman]

> I guess I will be trying UiBinder with GQuery and not rely on Widget for
> my project. The UiBinder might disappear, but we are using mostly plain
> HTML and Bootstrap styles. So we are only interested in binding events. The
> UiBinder templates will be easy to migrate later on.
>

FWIW this is what we're doing, with a small variation:

Use UiBinder, use regular CSS styling (bootstrap/etc.), but only very
minimal/core widgets, like TextBox (just an input tag), HTMLPanel, and
ListBox (select tag).

My theory/hope is that porting away from UiBinder + TextBox/ListBox to some
other templating language + "basically a text box, basically a select box"
replacements should not be too painful.

So, yes, it's still using widgets, but it's not the full slate of layout
panels, trees, cells, etc. that would be much harder to port.

That said...if you could get away with widget-less UiBinder? That's
interesting. I've not really tried that. E.g. just use an  instead of "gwt:TextBox" at all. That sounds like a good
idea to me...

- Stephen




>
> Any idea what is going on with Singular ? Is it also abandoned or will it
> finally appear after GWT 2.8 is final ?
>
>
> On Mon, Nov 16, 2015 at 12:10 PM, Alain Ekambi 
> wrote:
>
>> Well the hope is that someone will step in and port existing js libraries
>> to gwt 3 or create new one ? See vaadin sencha etc .. We will def port our
>> ext js wrapper to gwt3
>> On 16 Nov 2015 11:29, "Robert Stone"  wrote:
>>
>>>
>>>
>>> On Sunday, 15 November 2015 15:37:29 UTC, Stephen Haberman wrote:
>>>>
>>>>
>>>> My worry about "just pick a mainstream JS framework and use it via
>>>> JSInterop" is that if you're a) coupled to a JS environment for unit
>>>> testing and b) interfacing with a framework that is inherently
>>>> dynamic/untyped, what's the benefit of using GWT in the first place?
>>>>
>>>
>>>
>>> And this for me sums up GWTs main issues going forward. The benefit
>>> before was that existing Java devs could use GWT to work on all the layers
>>> of an application. GWT 3 will force (not a bad thing) Java devs to use
>>> JavaScript for their views and will also force them to deal with
>>> integrating JS and Java code. At this point, you have to ask 'Why bother
>>> with Java/GWT at all' - switch the full application to pure JS.
>>>
>>> For existing large projects, switching to GWT 3 is almost a non-starter
>>> as there will be far too much existing view code to convert over so they
>>> will have to stick with the GWT 2 stream and hope that it remains well
>>> supported. This is the situation my company face with one of our products.
>>>
>>> So GWT 3 is not ideal for new projects and doesn't help with existing
>>> projects. Where is it's market?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT 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/342561ff-64da-4e7a-aec4-6e9b84846f09%40googlegroups.com
>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/342561ff-64da-4e7a-aec4-6e9b84846f09%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGw%3D_ty7rjFQmUZhYv95aQBj8KgwSKcGk0nEyUkdTd4upBNtdA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGw%3D_ty7rjFQmUZhYv95aQBj8KgwSKcGk0nEyUkdTd4upBNtdA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-con

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

[Stephen Haberman]

>
> The important thing is to keep an open mind, not trying to force JS
> frameworks into our current best practices, and willingness to be inspired
> by the best practices of the chosen JS framework.
>
> Our best practices has emerged from the constraints of GWT, and those
> constraints has just changed.
>

Good points. :-)

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/CANnRKuUVrcwg%3Dx%3DFo5BE1Pk79Dk8bmQmDbvj-KMPXegJUmwT5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

[Stephen Haberman]

This is an interesting question (what to use for a greenfield GWT
project)...


> UiBinder: Would need a rewrite to use APT. I guess no one has looked into
> it yet. One main issue is that APT won't get triggered when updating
> resources (*.ui.xml)
>

Yeah, I would probably skip APT and just use an old-school "invoke it
before you run javac" code generator for ui.xml files (and hooked into
run-on-save with an Eclipse builder).

Given how egregiously statically typed UiBinder files are (in a good way),
ideally you wouldn't need much/any reflection/type oracle-type information
(which is where being in an APT environment is nice).

I might eventually prototype something like this, for migrating our
Tessell-based app off widgets...

So the absolute safest solution is to use JsInterop + any JavaScript
> framework. If that framework uses HTML templates then you still have that
> UiBinder feeling. You are not required to use Angular, but its a nice fit.
> The next best solution is probably GQuery and/or Elemento but you should
> expect some refactor work.
>

Yeah. The conundrum for me is that I'm addicted to the pure-JVM unit
testing/debugging that MVP gives you.

So, I guess you could still do MVP, with a view interface, and then have
the view implementation use Angular/JSInterop? That would be
interesting...not sure how it'd work in practice though, as it seems like
none of the watch/scope/etc. logic that you see in Angular controllers
would work in a pure-JVM unit test?

My worry about "just pick a mainstream JS framework and use it via
JSInterop" is that if you're a) coupled to a JS environment for unit
testing and b) interfacing with a framework that is inherently
dynamic/untyped, what's the benefit of using GWT in the first place?

Perhaps this is a naive question, and some GWT+JSInterop+JS framework
examples would (already?) show that you can leverage static typing enough
to make GWT worthwhile in a traditionally non-GWT/JS framework.

It will be interesting to see what Singular looks like. Personally, I think
there is definitely a space to be filled for a next-gen/J2CL-compatible GWT
framework, but I think it'll be ~6-12 months before we really know if a
solid choice materializes. And hopefully we'll have a few choices by then
as well.

Granted, that is not great advice for what to do right now...

- Stephen




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

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

Re: [gwt-contrib] Re: Stop calling it GWT 3.0

[Stephen Haberman]

>
> https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
>

Thanks!

I feel dumb, as the gwt-contrib posts were going under the Forums tab in my
gmail account, and so I missed the original email/thread go buy. I only
stumbled across this thread later via the web.

I'll start catching up on the videos.

So saying "GWT 2.x is here to stay" really would depend on someone
> maintaining it:
>

That is a good point.


> But I think we should just stop speculating, wait a bit for Google to
> continue their experiment with j2cl and have a clearer view of how they
> want to migrate their existing apps, and then see which features Google
> would like to port themselves (because they need them anyway) and which
> ones they'd "abandon", and whether they'll be replaced or not.
>

That's also very reasonable. Sounds fun!

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/CANnRKuWXhvbo5MaVpVDkoEwidYWyzkB-HrtKYWuQ-ux86gCZYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Stop calling it GWT 3.0

[Stephen Haberman]

Sounds like I'm late to party; I missed the 2015 meetup videos, does 
someone have a link? (That will teach me to not login to G+ very 
often...well played, Google...)

Not that my opinion matters very much (vs. the GWT team who's doing all the 
actual work), but I'll +100 any plans for large/breaking changes/rewrite 
for GWT 3.0/j2cl.

Everyone that is concerned about backwards compatibility, you can stay on 
GWT 2.x. What we need is foundations for a GWT that will be awesome 5 years 
from now. For the next generation of applications. That's who we need to be 
worried about.

Yes, that means pain/being left out for the current generation of 
applications, but that's how technology works. GWT 2.x will not suddenly be 
taken off Maven central. Plenty of enterprise applications rely on 
older/mature technology, e.g. jars/projects that aren't pushing out new 
releases every 2 months with amazing new features. That's fine. If it's too 
expensive to switch, then don't.

Sounds like a great opportunity for other companies to step-in and provide 
enterprise support for 2.x as well. Google has never been interested in 
that game anyway.

Someone mentioned early access to j2cl for framework authors to start 
porting; I'd throw my hat into that ring. It would be interesting to see 
what Tessell looks like with it.

Tessell very heavily uses UiBinder to drive its MVP codegen, so I'll have 
to either port Tessell to the next-generation of templates, or (more 
likely) port UiBinder to j2cl (using APT/something; maybe not 100% 
backwards compatible, but at least something that is not "throw away all 
your templates and start from scratch").

- Stephen


On Saturday, June 13, 2015 at 4:03:08 AM UTC-5, Paul Robinson wrote:
>
> The GWT Meetup 2015 videos are very interesting.
>
>
> I can see why the proposals for GWT 3.0 have been made. However, we should 
> be clear about the fact that GWT 3.0 is not just going to break a few 
> little things that can easily be fixed, but break things to the point that 
> it's a completely different product and there will be lots of GWT 
> applications that will never be ported to the new system.
>
>
> It will be confusing to all GWT users to continue to use the name GWT 3.0. 
> It would be much better to use a new name for the new system and treat it 
> as what it is: a new idea about how Java can be used to build modern web 
> applications.
>
>
> The situation we have now is that GWT will end at 2.8 and a new thing, 
> that is currently vapourware, will be coming that people are expected to 
> use. There's going to be a lot of confusion and those using GWT now, as 
> well as those that will use the new thing when it does exist, will all be 
> served much better if everybody stops calling the new thing "GWT".
>
>
> Paul
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/afebe594-679a-4ff6-b270-3cb0861986fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] stack trace on master calling List.sort

[Stephen Haberman]

Sorry for the cheap bug report, but on GWT master, the innocent looking:

final List f = newArrayList();
f.sort((a, b) -> a.compareTo(b));

Will result in a compiler NPE:

Caused by: java.lang.NullPointerException
at com.google.gwt.dev.jjs.ast.JMethod.getJsniSignature(JMethod.java:518)
at 
com.google.gwt.dev.jjs.impl.ControlFlowRecorder.computeName(ControlFlowRecorder.java:49)
at 
com.google.gwt.dev.jjs.impl.ControlFlowRecorder.processMethodCall(ControlFlowRecorder.java:197)
at 
com.google.gwt.dev.jjs.impl.ControlFlowRecorder.visit(ControlFlowRecorder.java:151)
at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:248)
at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127)

I get the root cause is that List.sort is a new JDK8 method that is not
implemented, which is fine, I’ll use Collections.sort and everything is
fine, but I was just surprised to see the compiler actually stack trace vs.
fail with a nicer compiler error.

Feel free to ignore this if this really is expected/unavoidable; admittedly
I don’t know what the previous behavior was in this situation of a
super-sourced class missing a method.

- Stephen
​

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/CANnRKuV2_m9%3DVap4oHHJuo5jtsA5_20exya0yHx%3DvAvtePFtrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] status of lambdas

[Stephen Haberman]

> Lambdas work fine in master.

Great! Thanks!

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20150427170059.7e5195c2%40sh9.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] status of lambdas

[Stephen Haberman]

Just curious, but what is the state of lambdas on master?
Probably works? Known broken in some hairy boundary cases? Being
used in production?

Thanks,
Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20150424200256.684f2d7d%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Incremental compiler refreshes triggered by IDE touching files

[Stephen Haberman]

Hi James,

This seemed like a pretty interesting thread. Do you still
suspect it's an issue?

I remember turning on the right logging ~6-12 months ago to see
files get incrementally compiled/etc. with SDM first came out,
but it's been awhile...

I use Eclipse, so if you can refresh my memory with some steps to
reproduce this, I'll see if it's happening on my end.

Thanks,
Stephen


On Wed, 15 Apr 2015 19:04:12 -0700 (PDT)
James Nelson  wrote:

> Whilst digging around trying to make some stuff go faster, I
> noticed something odd... I was getting a bunch of extra types
> getting marked stale at the beginning of a recompile, and at
> work, recompiles triggered even when no changes were made to
> Gwt-related files.
> 
> So, a little debugging and I noticed that we're computing the
> initial stale types using timestamps.  And, my IDE (yes, sigh,
> eclipse) is actually touching the files even when I'm not
> explicitly saving them.  This causes these types to look stale
> despite there being no changes.
> 
> When I close my IDE and manually edit a file via text editor,
> there are no longer extraneous files being marked stale.
> 
> It is understandable to use timestamps when recalculating stale
> types after a rebind, but for the initial staleness check in
> UnifyAst, I think paying a little extra for file hashes instead
> of time stamps might save a lot of extra time recompiling files
> that did not actually change.  If we want to save some wall
> time, we could calculate all the initial file hashes in a
> background thread on the initial compile (or store them as we
> load them), and then only look at the hashes if there is a
> timestamp difference.  This would let us use timestamps as a
> heuristic for checking hashes.
> 
> I'm not sure if IntelliJ has better respect for touching files
> than eclipse, but it seems like a pretty common use case for a
> file to get touched without changing. 
> 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20150423091130.0856026f%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

[Stephen Haberman]

I'm attempting to follow along. No real input, other than I did
not realize the (perhaps obvious) nuance of JS interop handling
both importing (e.g. wrapping DOM and existing libraries) and
exporting. And how callbacks are both-ish. Huh.

- Stephen


On Wed, 22 Apr 2015 21:34:27 -0700
"'Goktug Gokdogan' via GWT Contributors"
 wrote:

> On Wed, Apr 22, 2015 at 3:06 AM, Jens
>  wrote:
> 
> > - exports vs. export is a bit misleading. One must be used
> > with
> >>> interfaces/classes the other with methods. That issue only
> >>> exists because @Js alone has no real meaning.
> >>>
> >>
> >> Mostly agreed though @Js alone has meaning. As there are no
> >> exports, the methods can be pruned. This difference will be
> >> more significant when we change the output style to be more
> >> idiomatic javascript and have a closer integration with
> >> Closure compiler in the future.
> >>
> >
> > Yeah ok probably bad wording from my side. @Js is equivalent
> > to @JsImport.
> >
> > What I wanted to express is that the export flag is kind of
> > bad because its a "marker" and the act of marking something
> > for export should already be covered by applying the
> > corresponding annotation. So if you would have @JsExport then
> > applying @JsExport automatically means that it is marked for
> > export. You don't need that boolean flag then. You would end
> > up with @JsExport(STATIC_MEMBERS) for types and @JsExport for
> > members which seems more straight forward (yes I know
> > @JsExport(STATIC_MEMBERS) applied to a member seems strange
> > but you would have the same issue with @Js).
> >
> > Also see next inline answer.
> >
> >
> IIUC, even if we go with the Option 1, you are arguing JsExport
> should be separate than JsType. I disagree with that. With the
> new semantics, JsExport requires JsType; that is better to be
> explicit; when it is explicit JsExport alone doesn't have a
> meaning. 'marking' on top of JsType seems better to me as an
> attribute in JsType but I'll think more about that.
> 
> 
> >
> >
> >
> >> - You have to type more because it is always annotation name
> >> + property +
> >>> value if you can't stick with the default "@Js".
> >>>
> >>
> >> I'm assuming you are comparing Option 1 and Option 2 (see my
> >> recent email). Based on that I'm not sure which part you are
> >> referring. Can you give an example?
> >>
> >
> > I think what bugs me most are the boolean properties that are
> > used as "markers", e.g.
> >
> > @Js(property = true)
> > @JsProperty
> >
> > @Js(export = true, property = true)
> > @JsExport @JsProperty
> >
> > @Js(export = false)
> > @Js(ignore = true)
> > @JsIgnore
> >
> > It simply reads better without these flags. It is not so much
> > an "issue" for more complex examples, e.g.
> >
> > @Js(exports = ALL, namespace = GLOBAL, name = "Foo")
> > @JsExport(ALL) @JsNamespace(GLOBAL) @JsName("Foo")
> >
> >
> I think this comes to more of aesthetics and personal
> preferences. Multiple annotations easily convert into an
> annotation hell where you can easily hit 3 annotations for
> members; and I can even come up with cases where you need even
> 4: @JsExport @JsNamepace("...") @JsName("..") @JsProperty
> 
> Also single @JsIgnore doesn't have the same level of
> expressibility as setting export and ignore independently. Also
> then you have the problem when you apply JsIgnore on top of
> JsName or JsProperty.
> 
> 
> >
> >
> >
> >> - Can't see a good use case for splitting exports in ALL,
> >>> INSTANCE_MEMBERS and STATIC_MEMBERS. When I want to export
> >>> a class I want to export its public API.
> >>>
> >>>
> >> Yes, that was my assumption as well and that's how I
> >> started. But looking at real life code inside Google,
> >> especially in places where the code is shared by different
> >> platforms, I see people choosing to only export instance
> >> members or static members. I will need to re-evaluate this
> >> after we migrate all Google code to new annotations.
> >>
> >
> > Interesting. Wondering why that is the case. Given that it is
> > just a shortcut to avoid lots of @Js(ignore=true) or
> > @Js(export = true) annotations it is not so much of an issue.
> > However I am wondering if the shared Java code would end up
> > better if we enforce the "all public API will be exported
> > unless you opt out using @JsIgnore" route. For example a
> > developer would then have created a static factory class and
> > then choose to export that factory or not.
> >
> > But I guess we'll just trust the guys with the real world
> > code and if you think its a good idea to have these shortcuts
> > then fine.
> >
> >
> >
> >>
> >>> Personally what describes JsInterop best is the alternative
> >>> using the import/export concepts. So I would stick with:
> >>>
> >>> Import/Export types:
> >>>
> >>> @JsImport: can only be applied on interfaces.
> >>> @JsExport: always exports all public API in a given scope
> >>> (package, class, method). So no ALL, INSTANCE_MEMBER,
> >>> STATIC_MEMBER distinction.

Re: [gwt-contrib] Re: How to get the full StackTrace when using SuperDevMode in GWT 2.7?

[Stephen Haberman]

> I use the latest trunk and also SDM with incremental compile. @Goktug
> could you please provide a sample project where obfuscation works
> which has the correct configuration?

FWIW I'm using a snapshot of GWT master from ~last week, SDM, Chrome
40.0.2214.28, and when I set a breakpoint in FooPresenter.java (which
does pull up via the Control-O shortcut), the call stack is:

en_g$
pn_g$
qn_g$
yJo_g$


Oh right. 

So, Michael, in 2.7 release, SDM was outputting pretty names. However,
in master (e.g. post-2.7), after commit 676ca7532bd1387, the JS
function names are obfuscated again.

However, per Goktug, the idea is that, in Chrome/FF/and Safari
soon-ish, the browser should use source maps to show the right names.

I'm not entirely sure that's working for me in the Chrome debugger
right now, but it makes sense. (It says "Please wait a bit. source map
is being loaded!" but it's not loading...)

Ah, okay, AFAICT it was because I had the debugger paused in a place
that was fired on page load, so the sourcemaps hadn't had a chance to
load yet, and the breakpoint was blocking that from happening...

Nice. Now it basically works. I see in the call stack, on the right
side, the sourcemapped location of each function (e.g. Ur_g$ is
FooPresenter.java).

Chrome seems to lock up for a bit while loading the sourcemap file. But
looking pretty nice.

Anyway, Michael, Gotkug is saying that if you have a browser like
Safari/Mobile Safari that isn't picking up the sourcemaps to show nicer
function names, you should revert to GWT 2.7 final. Or they may
possibly add a "still use pretty names" override if Safari doesn't get
around to showing the nicer, sourcemapped function names.

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141209102726.0ab0315f%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: two errors in master

[Stephen Haberman]

Wow, that's great, Jens! Thanks for digging in to this.

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141203143114.5fb10e1d%40sh10.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: two errors in master

[Stephen Haberman]

> So I think we really have a GWT issue. 

Great detective work, Jens.

I agree, it looks like these type parameters only cause confusion to
the GWT compiler, and not to regular the Java/Eclipse compilers.

Given that GWT embeds JDT, I wonder if it's a bug in the version of JDT
we're currently using? Just guessing, but it looks like there is a
3.11.0 version that I might try as a knee jerk/couldn't hurt first step:

https://repo.eclipse.org/index.html#nexus-search;quick~jdt

(Curious that there are multiple 3.10.0/3.11.0 artifacts in that repo,
but with different date suffixes.)

- Stephen


-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141202170418.391c9a6e%40sh10.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: two errors in master

[Stephen Haberman]

> Maybe I'll go try and build a 1.8 version of Guava and see if the
> issue is in Guava itself? Not sure.

I was pretty surprised to find that Guava doesn't compile for 1.8:

https://github.com/google/guava/issues/1738

But not at all for the reason/compile errors I was getting (which were
related to, mostly AFAICT, Predicates.and method missing).

The Guava issue is pretty old and doesn't seem very active. Kind of
disturbing, although I understand setting up separate builds for them
is likely a PITA.

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141201165954.2ff0c43c%40sh10.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: two errors in master

[Stephen Haberman]

Okay, okay, sorry for all the emails, but I ditched sourceLevel 1.8 and am 
now just playing with the new cached-SDM...

Wow. It's awesome. Great work!

I was hesitant to move our app over to 2.7.0, but this, this is nice.

- Stephen
 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/5cfcf422-c969-4a00-8351-fbe34c648958%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: two errors in master

[Stephen Haberman]

> Note that in my previous email, both errors came from running 
> (Super)DevMode, but FWIW the Guava errors also occur in a regular 
> production compile (which I was not anticipating).
>

Ah, crap, I had thought checked for this, but I had mistakenly introduced a 
2nd variable: source level.

In both devmode/production, GWT master works fine with "-sourceLevel 1.7", 
but fails with those Guava errors with "-sourceLevel 1.8".

Maybe I'll go try and build a 1.8 version of Guava and see if the issue is 
in Guava itself? Not sure.

- Stephen



-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/8a1f1aff-33c5-4cc8-b7e7-6709740a3335%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: two errors in master

[Stephen Haberman]

Note that in my previous email, both errors came from running 
(Super)DevMode, but FWIW the Guava errors also occur in a regular 
production compile (which I was not anticipating).

- Stephen


On Sunday, November 30, 2014 4:24:21 PM UTC-6, Stephen Haberman wrote:
>
> Hi, 
>
> Given that the reuse-SDM cache patch (+ various Java 8 patches, hot 
> damn) landed, I tried our app with master. I'm seeing two issues: 
>
> 1. A transient/only-happened-once ConcurrentModificationException: 
>
> https://gist.github.com/stephenh/6e32c3077b67769e46cb 
>
> 2. Some compile errors related to guava/guava-gwt: 
>
> https://gist.github.com/stephenh/92f451858eb9828c199f 
>
> [ERROR] Line 1691: The method and(Predicate, 
> Predicate) is undefined for the type Predicates 
>
> [ERROR] com.google.common.collect.Maps.ImprovedAbstractMap cannot be 
> resolved to a type 
>
> Not quite sure what is going on here...I have guava and guava-gwt 18.0 
> on the classpath and, AFAICT, no other version is shadowing it, e.g. 
> due to be included-non-rebased in another jar (which is surprising for 
> once that the problem isn't related to that :-)). 
>
> Also, along the old/shadowed version theory, I checked and 
> Predicates.and seems to have been in Guava for awhile. 
>
> This same app runs fine in gwt-2.7.0 final. Has there been a change 
> recently that might affect this? Anything I can do to help poke around? 
>
> (Normally I would have submitted a patch (assuming it's semi-trivial) 
> for the first issue, but my GWT environment is on another machine.) 
>
> Thanks, 
> Stephen 
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/bf5374d8-07d5-40f5-b8a0-721df8278537%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] two errors in master

[Stephen Haberman]

Hi,

Given that the reuse-SDM cache patch (+ various Java 8 patches, hot
damn) landed, I tried our app with master. I'm seeing two issues:

1. A transient/only-happened-once ConcurrentModificationException:

https://gist.github.com/stephenh/6e32c3077b67769e46cb

2. Some compile errors related to guava/guava-gwt:

https://gist.github.com/stephenh/92f451858eb9828c199f

[ERROR] Line 1691: The method and(Predicate,
Predicate) is undefined for the type Predicates

[ERROR] com.google.common.collect.Maps.ImprovedAbstractMap cannot be
resolved to a type

Not quite sure what is going on here...I have guava and guava-gwt 18.0
on the classpath and, AFAICT, no other version is shadowing it, e.g.
due to be included-non-rebased in another jar (which is surprising for
once that the problem isn't related to that :-)).

Also, along the old/shadowed version theory, I checked and
Predicates.and seems to have been in Guava for awhile.

This same app runs fine in gwt-2.7.0 final. Has there been a change
recently that might affect this? Anything I can do to help poke around?

(Normally I would have submitted a patch (assuming it's semi-trivial)
for the first issue, but my GWT environment is on another machine.)

Thanks,
Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141130162413.4cd9bdfd%40sh10.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] JsInterop retrofit

[Stephen Haberman]

> I will try to summarize my thought process and different options that
> I have played with so that you could get a better understanding where
> I'm coming from and I hope it will provide good documentation for
> future.

Thanks for the email; I think the format was really useful.

> One may argue that if we are committing to use some kind of DSL why
> not use something else like IDL or xml etc. There are 3 main reasons
> to use java + APT instead of others:

I really want to advocate APT, as I've used it and do generally like it,
but frankly it can be a huge PITA for Eclipse. See long-standing issues
e.g.:

https://github.com/square/dagger/issues/126

Granted, maybe someone can just fix Eclipse, but, in my experience, it
can really ruin the first impressions for a project (1000s of compile
errors due to missing generated code, and no hints that, btw, it's
because the APT was not on the classpath/didn't run).

> All the cons are around the testability aspect. For JRE testing,
> native methods are a headache. Also we no longer generate an interface
> for static methods.

I know I just bitched about APT, but, just musing, what if the class
(with the native methods/etc.) was the DSL the user wrote, and then APT
just generated an interface from that?

This is basically what I'm doing by hand in tessell with writing
IsTextBox for TextBox, etc.

I admittedly am not an expert on JS prototype semantics, so am not sure
how this would handle statics/etc. But in testing I usually only care
about instance methods anyway...

A few years ago I spiked an APT processor to do this automatically:

https://github.com/stephenh/interfacegen

The oddity then becomes that the user is writing "class JsObject", but
then if they want testable code, they need to code against the generated
"IsJsObject" interface. But perhaps that it's optional is a good thing,
e.g. you could come back and add the "@GenInterface"-type method later
if/when you wanted.

Anyway, I think I do like the last proposal, the class/native method
best.

Thanks, Goktug!

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141101102535.45715a48%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.7.0-RC1 is available

[Stephen Haberman]

When running DevMode (the Swing UI) with gwt-2.7.0-rc1 installed from
Maven central, without gwt-codeserver on my classpath, I get:

Caused by: java.lang.NoClassDefFoundError: 
com/google/gwt/dev/util/arg/JsInteropMode
at com.google.gwt.dev.codeserver.Options.(Options.java:79)
at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Adding the gwt-codeserver jar makes it work, but IIRC we were
attempting to make a "no gwt-codeserver yet" classpath setup work.

(I'm not weighing in one way or the other, just reporting results.)

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141029225313.3555fec5%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.7 : precompile and incremental flags

[Stephen Haberman]

>   if (child.getName().equals(".svn")) // hardcoded filter here

Just curious, but didn't svn change (maybe a year ago or so?) to only
using one top-level .svn folder, similar to Git's top-level .git
folder, and not having .svn littered throughout the file system?

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141021174343.46a191a4%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: odd super dev mode times

[Stephen Haberman]

Well, this is somewhat anti-climatic, but, AFAICT, it was just
MemoryUnitCache's maps using soft values.

Instead of turning on TRACE everywhere, I upgraded
MinimalRebuildCache's "known modified type" output to WARN. (It would
be great to have log4j-style package-level knobs in the GWT log
output.) That was always right (only 1 .java file with it's 3 inner
types).

After trying a few other things, I also upgraded
CompilationStateBuilder's doBuildFrom, where it reads from the unit
cache, "Used x/y units from cache" line.

And that's it; whenever I have a slow load, I'm loading only ~3k out of
~4k units from cache. Or less (I saw zero once, after I had
particularly annoyed the GC somehow). Whenever it's fast, all ~4k
(minus the newly invalidated one) are loaded from the unit cache.

I removed MemoryUnitCache's maps' .softValues() and that seems to fix
it. Upping the Xmx from 1g to 2g also fixes it, and provides a nice
speed up anyway.

Perhaps 1g was a naively low setting, but, AFAICT, without poking in
the code (or turning on TRACE and knowing exactly what to look for),
there are no visible hints about "hey, the cache isn't keeping up,
that's why your reloads are slow, so up your Xmx".

Given how important the unit cache is now, perhaps the maps should no
longer use soft values? In my case, I would have preferred an OOME as
an blatant "needs more RAM" than silent sub-optimal behavior.

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141020233903.2a9a93d1%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: odd super dev mode times

[Stephen Haberman]

> I think that CL is only on master. Thats why I said try master and if
> it works send me a cherry pick for the CL :)

$ git branch -a --contains 14f27064497f11
  master
* release/2.7
  remotes/gerrit/HEAD -> gerrit/master
  remotes/gerrit/master
  remotes/gerrit/release/2.7

I also opened the 2.7.0-beta1 jar and it's .java file has the change as
well (checks UnitOrigin.ARCHIVE instead of PERSISTENT).

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141020173326.3663f936%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: odd super dev mode times

[Stephen Haberman]

> However, right, it didn't actually make it into 2.7-beta1.

Crap. Eclipse was lying to me, and had a 2.6.x source jar hooked up to
gwt-dev-2.7-beta1.jar (don't ask) when I pulled up PersisentUnitCache
in my project to check for the change.

So: a) 2.7-beta1 does have John's 14f2706 fix, and b) even trying with
a locally built snapshot of release/2.7, the behavior is still
happening.

I'll spend quality time with the debugger tonight and try and see
what's going on. (But if a CL were to magically hit master before then,
I would not mind that either.)

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141020172605.0c3895aa%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: odd super dev mode times

[Stephen Haberman]

> I think it's in master now (commit 14f27064497f1171907d0ecbe01a4d2991a7a855)

Oh shoot; I was wondering if that's what Roberto was referring to.

I assumed 2.7-beta1 already had that fix, because I saw it on the
release/2.7 branch in gerrit (and a few commits down/non-cherry picked).

However, right, it didn't actually make it into 2.7-beta1. I'll test
with a snapshot of the 2.7 branch later today/tonight and report back.

Thanks,
Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141020160454.44d2bc14%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: odd super dev mode times

[Stephen Haberman]

> depends on how many files are modified [+ invalidations]

Yeah, sorry, I should have mentioned I've only been changing one file,
just adding/removing a character in a string.

> John detected that behavior in the persistent unit cache and has a
> fix for it.

Great! I'll try it out when it hits master.

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141019215142.6e6e53f1%40sh9.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: odd super dev mode times

[Stephen Haberman]

> ...and, right now, I can't even get the 3s time to kick in again.

Ah ha...seems to be something with the PersistentUnitCache.

When the recompile is 10-20s every time, I see output of:

Wrote 4944 units to persistent cache
Wrote 1 units to persistent cache
(reload)
Wrote 4944 units to persistent cache
Wrote 1 units to persistent cache
(reload)
Wrote 4944 units to persistent cache
Wrote 1 units to persistent cache

I nuked my gwt-unitCache dir, and then see:

(on startup)
Wrote 4944 units to persistent cache
(first load)
Wrote 1 units to persisent cache
...this (Wrote 1 unit) repeated 100s of times...
Purging cache files
Wrote 6166 units to persistent cache
Wrote 4945 units to persistent cache
Wrote 1 units to persistent cache
...few more 1 units...
(reload)
Wrote 1 units to persistent cache
(reload)
Wrote 1 units to persistent cache

I'm now getting the 3s reload. I restarted devmode 2-3x and it still
worked great. However, on the 4th-5th restart, the old behavior came
back. Nuking my gwt-unitCache re-fixed it.

- Stephen


-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141019211649.6a1a0307%40sh9.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] odd super dev mode times

[Stephen Haberman]

Hi,

I'm trying out GWT 2.7.0-beta1, and am seeing kind of odd recompile
times. (Our app is ~70k LOC, and the main/only generators are GWT-RPC
and UiBinder.)

The first compile take 40s. Then, only changing a single char in
a .java file, the first recompile takes 20s. Then each next one takes
consistently ~10-15s.

However, eventually something magical happens, and we hit 3s.

The 3s is great. The first 40s is known/understandable. But I can't
figure out what's happening with these ~10-20s recompiles in the
middle. ...and, right now, I can't even get the 3s time to kick in
again.

Here is the compile output from two attempts:

https://gist.github.com/stephenh/9eecf293570b8d5c5eee

I assume the idea it should immediately go from 40s to 3s? Any ideas
about how to debug the "faster but not quite fast" compiles? (I suppose
an obvious one is to kick up the log level; I should have tried that
already, and will later.)

Thanks,
Stephen


-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141019191825.4c11fd77%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: calling onLoadErrorFn on permutation 404

[Stephen Haberman]

> - User starts loading old nocache.js, you tell load balancers to
> redirect to the new app, the nocache.js runs and tries to load an old
> permutation from a new server where it doesn't exist.

Right.

> I suppose Stephen's deployment strategy is different

Yeah, slightly.

Currently, if we have two servers running, our deployment script will
start another two (by increasing the AWS auto scaling group size to 4),
which means AWS will immediately add them to the AWS ELB when they boot.

Our script then waits to shut down the old servers until it's verified
both new ones are running/healthy.

So, the window where we could have both running is ~3-5 minutes long.

That said, our new deployment scripts (that we just haven't moved to
yet), start a completely new AWS auto scaling group for the deployment,
let all the new instances start in there (without being added to the
ELB), and then do a mass register/deregister of the machines with the
ELB.

Which will have a much smaller window, but it's still not atomic.

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141006085918.42db61c4%40sh9.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] calling onLoadErrorFn on permutation 404

[Stephen Haberman]

Hey,

During our deployments, we have a small window where both old/new
servers could potentially be available. I'm trying to hook into the
failure of when a client loads the .nocache.js from one version,
but tries to get the permutation from another.

Currently what happens is that the permutation 404s and the GWT app
just stops in its tracks, leaving the user with a blank page.

I added a onLoadErrorFn, expecting it to be called in this case, but
turns out it is not. I put together a patch that changes this:

https://gwt-review.googlesource.com/#/c/9510/

It seems fairly straightforward and correctly fires onLoadErrorFn when
I purposefully delete a permutation file when running locally to
reproduce the behavior.

Feel free to either reply with thoughts either here or on the code
review. If no one volunteers for the code review, after a few days I'll
use git blame to nominate someone.

Thanks,
Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141005214029.3481030e%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] class cast exception in ff 17

[Stephen Haberman]

> It might be related to the bug[1] that mdempsky@ filed to Firefox
> earlier. The Firefox's VM was causing an incorrect polymorphic
> dispatch sometimes.
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=872796

Ah, nice!

Thanks (Jens too) for saving me the trouble of trying to reproduce
that. I was really not looking forward to it. :-)

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141003141714.51464061%40sh9.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] class cast exception in ff 17

[Stephen Haberman]

Hey,

I know FF17 is pretty old, but do we care about breakages in it? We
noticed some client-side ClassCastExceptions in our logs that are
from a user on FF17. The app works fine in FF latest.

The exception is odd, because, according to the de-obfuscated stack
trace, given a class hierarchy like:

   class Base
   class Foo extends Base
   class Bar extends Base

We are in "new Foo()", from the Foo cstr we call the Base cstr, which
calls Base.someMethod(). Base.someMethod() calls Base.anotherMethod().

Now the bizarre thing is that we end up in *Bar*.anotherMethod(), and
get a class cast exception.

E.g. somehow we jumped subclasses, and went from executing code in
Foo/Foo's base class to code that is in Bar.

Which seems really odd. Which is why I mention it. If we don't care,
that's fine, but it made me scratch my head for awhile.

(Our production build is using a GWT snapshot from ~April, but I also
reproduced it in our app with a GWT snapshot build from ~last week.)

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20141003135259.76c16354%40sh9.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] minor sdm bug

[Stephen Haberman]

Hey,

I was trying SDM on a project today, via the -superDevMode flag that
was added to DevMode (great work).

It worked really well on one project, and then on another I kept
getting the "GWT needs (re)compiled" that's from the old
.nocache.js.

Turns out I had a .nocache.js.gz artifact that was from some
previous compile I had done (with Precompress included), and Jetty was
serving this old .js.gz as the preferred version of the nocache.js file.

So, I'm not super familiar with where/when the files get generated, but
maybe SDM could detect/delete/update the potentially-stale .js.gz
version of the nocache.js file?

Thanks,
Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20140928182140.451f0289%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Proposal for a generic accessor for GWT properties

[Stephen Haberman]

> https://docs.google.com/document/d/1LEP0H-6z__Mog0QTt-NAFpllcOGu7X5gr7KR32BIT4Y/edit?usp=sharing

Spiffy.

Of my excitement, 20% of it is because I like this feature, and 80% of
it is because there is actually a public design doc before the CL hits
trunk. :-)

Really cool. I like the keyspace discussion, but don't have anything
specific to add.

Thanks for sharing!

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20140725112733.4a4f9786%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Future of Renderable and PotentialElement?

[Stephen Haberman]

> My point was more about, don't think Orkut announcement as "we >
> can't delete it now as Orkut is no more"; I might have misinterpreted
> that.

Cool, that makes sense. Maybe you can give us a heads up when Orkut is
gone from the Google repo, and then we can revisit PotentialElement's
future.

I agree with Colin; we should mark it as deprecated, ideally for 2.7. I
will volunteer, with deferring to Thomas since this was his fun idea if
he wants to drive the CL instead.

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20140707185507.3e7bac7f%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Future of Renderable and PotentialElement?

[Stephen Haberman]

> The point was more about Orkut announcement doesn't change anything
> and cannot effect the decision from our perspective; as long as the
> system is running we need to take care of it.

Right, sorry...I thought that the annoucement was exactly that: it
would no longer be running, soon (end of September).

So, yeah, I understand we can't delete things *right now*, but I assume
Thomas was talking about the post-shutdown-so-probably-deleted
timeline, which I assume will happen at some point post-September.

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20140707095026.4fb42f76%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Future of Renderable and PotentialElement?

[Stephen Haberman]

> Even Orkut closing the doors, it doesn't mean their code is going away
> anytime soon :)

You're killing me, Goktug. The backwards compatibility knife had
already pierced my heart, and this just shimmied it around a bit. :-)

I had to refresh on memory on PotentialElement, but it looks virtual
DOM-ish; making fake elements that are really pure JS objects, and then
later converting them into real DOM objects only as-needed. I believe
it sped up the first page load of Orkut by ...15%? or so.

I also vaguely recall that, AFAIU, the pipe dream was to have the
entire initial DOM render be one huge .innerHTML=, since IE
really liked that. But making strings that big hurts the GC such that
(AFAIK) it's a wash in modern browsers to just making DOM elements
directly anyway.

Speaking of PotentialElement, looking at commits from around that time
frame, there is also a change from Ray Ryan that turned
useLazyWidgetBuilders = true, with a commit message of "in prep for
deleting the old code".

Looks like that deleting never happened...can we do that now?

As with PotentialElement, I don't think useLazyWidgetBuilders had any
external design docs, discussion, etc., so I don't really know the
whole story on it. Or even little bits, other than I enjoy deleting old
code and will volunteer to do that if we can.

- Stephen

-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20140706220525.6ccc4472%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] JettyLauncher class loader

[Stephen Haberman]

I've not looked at the code, but I'll chime in my support for Manuel's
approach--I think the JettyLauncher/SuperDevMode class would be the
easiest transition path for us.

(Not all of our devs use GPE, so while the facets sound spiffy/etc.,
hopefully they would be an alternative and not a replacement.)

Goktug's idea of shipping servlets is pretty intriguing, in terms of
getting Jetty out of GWT core all together; I think the only complexity
would be conditionally mangling the web.xml for dev vs. prod mode (e.g.
I assume we wouldn't want the proposed GWT SuperDevMode servlet in the
web.xml that is deployed to production).

- Stephen


-- 
You received this message because you are subscribed to the Google Groups "GWT 
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/20140702120425.7e5b82ae%40sh9.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Last call for GWT 2.6.1

[Stephen Haberman]

Hi Daniel,

> If you want to get your changes into GWT 2.6.1, they need to get in
> before Friday.

Selfishly, our app is depending on this patch now:

https://gwt-review.googlesource.com/#/c/6780/

I know it's not a bug fix, but it's pretty simple; I assume it's find
to cherry pick into 2.6.1? I can go ahead and do that if so (I assume
it's for the release/2.6 branch?).

I can also make an issue for it in the tracker so that it shows up in the
release notes...

Thanks,
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/d/optout.

Re: [gwt-contrib] Re: Can we move the code to GitHub?

[Stephen Haberman]

> We're starting seeing integrations between Gerrit and GitHub 
> (http://gerrithub.io/)

Ooh, that looks spiffy. Thanks for the link, Thomas.

>From Benjamin's reply:

> I think other UI frameworks/platforms like AngularJS are gaining more 
> traction/adoption because they are accessible through GitHub.

AngularJS is not gaining more traction than GWT merely because it's
hosted on GitHub. I wish that there the case (what an easy thing to
fix!), but in reality it's much more than that, and not worth rehashing
here.

Basically, Benjamin, it's great to have you, and I'm sure you mean
well, but you're not going to win a "let's change our tools" thread on
your 1st post to gwt-contrib.

But it's great to see that you're enthusiastic about GWT. It'd be great
to have you help out. Perhaps you can indulge us and put up with Gerrit
for awhile while doing so. :-)

- 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/d/optout.

Re: [gwt-contrib] Re: Classloader issues for server-side code in DevMode with GWT 2.6

[Stephen Haberman]

> Neither one (depending on your build tool though).

Sure, I get that Maven/Gradle/Ant will go through a copy-to-target step
first, and so not use any src/... artifacts. So, for them, having the
Jetty classloader not use the project classpath makes sense.

But at least we way run DevMode in Eclipse (as vanilla .launch files
with DevMode as the main class), we pass -war src/main/webapp, so we
can run directly against src/ without any copy-to-target/build system
steps at all.

And so then all of our IvyDE-managed jars and project .class files come
from the regular Eclipse/system classpath that "Java Applications" get.

> I don't have a strong opinion though; I'd be fine just using the
> system classloader as the parent of the webapp classloader (the end
> result would be the same as if you deployed all your code and
> dependencies to Jetty's lib/ or lib/ext/ or Tomcat's shared/ );

Which is the behavior today, right? That is what I'd generally prefer,
given it allows the previous "only use Eclipse" sort of setup.

> I think newbies would need/prefer warnings. 

I'd be fine with a warning that could be disabled... :-)

- 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/d/optout.

Re: [gwt-contrib] Re: Classloader issues for server-side code in DevMode with GWT 2.6

[Stephen Haberman]

Hi Thomas,

> (or rather, it'll work "too well", and won't detect that "something is
> missing in WEB-INF/lib".

I'm attempting to follow along, but classloader semantics are "fun", so
apologies if I'm wrong somewhere...

So, to clarify, if I have a dependency, say foo.jar, that isn't GWT, and
isn't Jetty, but my server-side code uses it, with your proposal, would
it now have to be in (say) src/main/webapp/WEB-INF/lib? Or could it
still come from the Eclipse classpath like it does today?

My two cents is that foo.jar being on the Eclipse classpath is just
fine/what I generally prefer anyway, even if it "works too well", as it
means I can skip the "make a war" or "put all jars into WEB-INF/lib"
steps while just developing.

That said, you are right that it could lead to false positives, but I
would really hope that developers are not using "it works on my machine
in dev mode against my exploded war" as their criteria for "will work in
production". Perhaps that is too optimistic.

- 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/d/optout.

Re: [gwt-contrib] Re: final fields patch

[Stephen Haberman]

Hi Jens,

> If thats the case you might break people who have final fields whose
> types are not compatible to GWT-RPC serialization.

If this is happening today, and this fix started serializing EnumSet
where before it was not, I would again assert the new behavior is the
correct behavior, so the user should enjoy knowing that we've uncovered
what was likely an unintended bug/aspect of their code.

If the user really intended for EnumSet to not be serialized, then the
field should have been static/transient/etc. instead of relying on bugs
in GWT-RPC.

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

[gwt-contrib] final fields patch

[Stephen Haberman]

Hey,

At one time I was shepherding through the GWT-RPC patch for supporting
final fields.

One of the unpleasant aspects of the patch as that, instead of just
fixing the bug, and serializing final fields always, there was a knob
of serialize final fields true, false, and false_nowarn.

This, coupled with the existing gwt.suppressNonStaticFinalFieldWarnings
meant that 80% of the patch was passing around settings and doing
conditional warnings. And tests for each of the settings.

I'd like to propose instead just always serializing final fields. And
no warnings. We can put it in the release notes. "Final fields are now
serialized".

Previously there was a concern that GWT users might be knowingly or
unknowingly putting sensitive values into fields of objects that are
serialized by GWT-RPC, but since the fields were final, these sensitive
values were not going over the wire. But now they would.

This seems both remote and nonsensical to me (that anyone would do it
on purpose).

I'd like to resubmit the patch, with no knobs, to just always serialize
final fields. It's simpler and is what should have been happening all
long anyway.

Any objections? Brian?

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

Re: [gwt-contrib] bug in permutations.js?

[Stephen Haberman]

> Yes it sounds like a bug. Want to add that to the issue tracker?

https://code.google.com/p/google-web-toolkit/issues/detail?id=8575

I've verified that the patch fixes the behavior in our application.

Any good suggestions about how to test this? Or volunteers to review
the patch?

Given it was, I assume, a bug in permutations.js, I imagine I would
have to create a mini test app with collapse-all-properties, have it
compile to JS, and then somehow verify that the right deferred binding
for permutation 0 (which ever browser that happened to be) got the
right selection.

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

[gwt-contrib] Re: bug in permutations.js?

[Stephen Haberman]

Here is the difference in the generated JS. From a ~10/2013 trunk build:

function com_google_gwt_dom_client_StyleInjector_StyleInjectorImpl(){
  switch (permutationId) {
case 1:
case 2:
case 3:
  return new StyleInjector$StyleInjectorImplIE_0;
  }
  return new StyleInjector$StyleInjectorImpl_0;
}

So, even when permutationId was undefined (which it was for gecko_18,
which was basically permutation 0), it was fine, it'd get the non-IE
version.

But now with 2.6:

function com_google_gwt_dom_client_StyleInjector_StyleInjectorImpl(){
  switch (permutationId) {
case 0:
case 4:
  return new StyleInjector$StyleInjectorImpl_0;
  }
  return new StyleInjector$StyleInjectorImplIE_0;
}

The output changed; now when permutationId is undefined, which it still
is for gecko_1.8 (no change there), then IE is the default.

AFAICT the DOM.gwt.xml rules for StyleInjector haven't changed
recently. The permutations.js hasn't changed (permutationId was
undefined both pre-/post-2.6).

So, I can file a patch to make permutationId=0, but any ideas why this
would have changed since October-ish?

It must have been that, previously, "case 0" would never have been put
inside the runtime switch statement, and instead always have been the
fallback.

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

Re: [gwt-contrib] bug in permutations.js?

[Stephen Haberman]

> Want to add that to the issue tracker?

Sure, I'll do that soon...

> I wonder why more people aren't seeing this? Does it only affect soft
> permutations?

Removing collapse-all-properties does fix it.

I'll do that for now and then work on submitting a patch. No idea how I
would add a test for it.

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

Re: [gwt-contrib] Re: bug in permutations.js?

[Stephen Haberman]

> and only permutations.js assigns it to another value (but does so
> conditionally, so it never *assigns* undefined to
> __softPermutationId, it just leaves it not defined).

But line 61:

https://gwt.googlesource.com/gwt/+/master/dev/core/src/com/google/gwt/core/ext/linker/impl/permutations.js

Always assigns module.__softPermutationId to the value of the
softPermutationId local variable, declared on line 23. And it will be
undefined if idx == -1. Right?

That is what's happening when I debug through our app in FF.

> any chance that is what is biting you instead?

We have split points disabled.

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

[gwt-contrib] bug in permutations.js?

[Stephen Haberman]

Hey,

We upgraded to GWT 2.6 last week, and our seeing weirdness with
StyleInjector. Firefox ends up using the StyleInjectImplIE and errors
out because $doc.createStyleSheet is IE only.

FF gets the wrong deferred binding because its permutationId is
undefined, when it should be 0. (We use collapse-all-properties and
direct_install linker.)

Looking at permutations.js, it does "var softPermutationId", then later
when parsing the strongName, our FF strongName doesn't have ":" in it
(see below), so it ends effectively up doing:

module.__softPermutationId = undefined;

In our module.nocache.js file, here's the gecko1_8 entry:

  unflattenKeylistIntoAnswers(['gecko1_8'],
  '9181777BF8BB65802D36B21DCBB83FE1');

No ":0" at the end.

So, surely __softPermutationId being undefined is a bug?

Should I try fixing this by changing getCompiledCodeFilename's
softPermutationId to default to 0? Or is the problem with the strong
name itself, in that it should always have a : suffix?

Hm. PermutationsUtil:131 insinuates :0 is left off on purpose.

Looking at git log/git blame, doesn't seem like any of this has changed
recently? We had been running some post-2.5 GWT trunk.

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

Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype

[Stephen Haberman]

> It's curious, I googled about Java 8 compiler plugins when RayC said
> that you talked about a new code-gen feature in Java 8 

Ha, yes, that is curious. I guess my memory has never been that great...

> I hope it will be formalized in future Java versions

Ah, that makes sense, since APT followed the same path, IIRC.

> GWT-free generators

Per Brian's comments, a javax.rebinding spec might have a hard time
having feature-parity with GWT, because I imagine the Java8 plugins,
like APT, only runs on .java files currently under compile, and doesn't
re-process all of the types in .class files via .jars on the classpath.

Which, AFAIK, is what John is getting to work--that a .jar (or .gwtlib)
is basically compiled, but can have one more global rebinding pass that
modifies its contents before GWT writes everything to disk.

(GWT has an advantage here, in that since it's making non-.class file
output, it can sneak codegen into the compiler for both types in the
current project, and types that are in upstream projects. It would be
hard to see how a javax.rebinding spec could do this.) 

> JavaCode => JavaToJRibbleCompiler (Java 8 compiler plugin)

Well, you mentioned "jribble", so now I'm a fan of basically anything
you say. :-)

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

Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype

[Stephen Haberman]

> implemented as a Java 8 compiler plugin (extension point)

Interesting! I had not heard of these before:

http://techbitsfromsridhar.blogspot.com/2013/02/java-compiler-plug-ins-in-java-8-use.html

It looks like these compiler plugins use "com.sun" packages, and are
not a JSR, which AFAIK means no Eclipse IDE nor ecj support? What does
that mean for your GWT-free deferred binding proposal?

That aside, I think a GWT-free deferred binding API would be pretty
sexy. If one were starting GWT from scratch, I'd naively assert/agree
that the problems of "build-time codegen" and "transpiling .java to .js"
are orthogonal, and so should be tackled separately. Which would
ideally make both implementations smaller/simpler/better.

(IMO/in theory/lots of hand waving and disclaimers. Doing both has
obviously served GWT really well, so it is admittedly naive of me to
assert they could be separate steps without really flushing it out.)

Anyway, it's really exciting to see your contributions, Andres, your
write up was very good.

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

Re: [gwt-contrib] elemental templates

[Stephen Haberman]

> Yes. We are planing to revive elemental based on new @JsInterface
> proposal and have web-components-like widget system on top of that.

Nice! I'll look forward to your proposal.

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

[gwt-contrib] elemental templates

[Stephen Haberman]

Hey,

Just curious, but what's the story around templating for Elemental?

Googling around seems like it's not supported by UiBinder. Is there
anything coming along/WIP internally? Will Goktug's new widget proposal
be based on Elemental?

I'm just curious as, after glancing at it again, I finally noticed the
obvious fact that it already has interfaces for all of the elements,
window, etc., etc., just like I'm patching into the old widget set.

To me that's awesome, so I hope/assume that aspect of Elemental is here
to stay. Now I'm mulling over how/when to move over, and UiBinder-ish
templates would be a big help towards doing so.

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

Re: [gwt-contrib] Re: Deprecating and moving AsyncProxy out of SDK

[Stephen Haberman]

> Never used it

Same here, so +1 to your plans to extract it.

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

Re: [gwt-contrib] Deprecating DeRPC classes

[Stephen Haberman]

Hi Naresh,

> Could you please let me know is there any patch available to check
> the impact of removing de rpc calls.

I'm glad you're interested in looking in to this.

Unfortunately, I don't really know much about DeRPC. There are probably
others on the gwt-contrib list who do though...we'll see if anyone can
point you in the right direction.

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

Re: [gwt-contrib] Re: GPE does not like GWT trunk SDK?

[Stephen Haberman]

Hi Rajeev,

Good to hear from you.

> We're in the process of moving the GPE source to github (and
> converting the build system to Maven/Tycho so that external
> developers can build it) , which is why that repo hasn't been updated
> in a long time. I'll update the homepage to reflect that.

Sounds like a good plan. Thanks!

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

Re: [gwt-contrib] Re: GPE does not like GWT trunk SDK?

[Stephen Haberman]

I was going to ask how active the GPE project is...is the last commit
really from October 2012?

https://code.google.com/p/google-plugin-for-eclipse/source/list

That doesn't seem right, but AFAICT there isn't another source repo?

https://developers.google.com/eclipse/community

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

Re: [gwt-contrib] Re: GPE does not like GWT trunk SDK?

[Stephen Haberman]

> have not been updated to @GWT_GITREV@.

Thanks! Good catch.

https://gwt-review.googlesource.com/#/c/5194/

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

Re: [gwt-contrib] being cute with git describe

[Stephen Haberman]

>- do we really want to keep the 0.0.0 special version? (would it
> really hurt if master currently said 2.5.1-250-g4a00f1e?)

FWIW I like 0.0.0 because it strongly differentiates hand-made/master
releases vs. official/release branch releases.

And it always sorts before release versions, which feels safer to me.

Also FWIW, I am not a fan of master's "git describe" looking like
"2.5.1-250-...". That seems misleading, because if we put the 2.5.1-rc0
tag directly on master's commit B:

A - B [2.5.1-rc0] - C - D (master)

And the 2.5.1 branch continues off B:

A - B [2.5.1-rc0] - E - F [2.5.1]

Then describe will name commit C as "2.5.1-rc1-1-C", when really in my
mind "2.5.1-rc1 + 1 commit" is commit E. On the 2.5.1 branch. There
would basically be two "2.5.1-rc1 + 1 commit" commits, which, yes,
there is still the sha, but that seems confusing IMO.

> If we do want these, then it should be as easy as hard-coding the
> version in a file somewhere

I see what you're saying, although from a workflow perspective that
would mean branching is "branch, edit version file, commit" which is
pretty close to "branch, make a dummy commit, tag as 2.5.0-rc1".

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

Re: [gwt-contrib] being cute with git describe

[Stephen Haberman]

> I was thinking about something like that too.  I actually kinda like
> it, and it gives an easy monotonic counter for tracking master.

Agreed.

> I don't think we're using proper git tags yet.  The 'tags' currently
> in the tree for 2.5.1, etc that were imported from SVN are actually
> just regular git commits.

I think the svn import was smarter than that..."git tag -l" shows tags
for 2.5.0, 2.5.1, 2.5.1-rc1, etc.

> while intermediary development steps would still be "2.6rc1-42-blah".

Yep, that makes sense.

> Hm, something to consider though, I was planning on creating the 2.6
> branch and then immediately tagging as 2.6rc1.  Since tags are
> independent of branches, I think that would actually cause the 2.6rc1
> tag to be picked up by master too.

Hm, true...you'd need at least one commit on the 2.6 branch to avoid
it's tags getting picked up by "git describe" on master. I dunno.

Looking at the DAG for the 2.5.1 branch, it looks like svn had a
"Cutting at r11495 for 2.5.1 RC1" commit at the start of that branch
(granted, svn semantics require that). We could always make a similar
dummy commit. Not great, but not horrible, I think.

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

Re: [gwt-contrib] Gerrit presubmit changes

[Stephen Haberman]

Wow, that sounds awesome, Matthew. Great work. I'm looking forward to
hopefully *not* triggering this great feedback. :-)

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

[gwt-contrib] being cute with git describe

[Stephen Haberman]

Hey,

So, I was toying with changing "git.version" over to being based on
"git describe" output, instead of having to pass in GWT_VERSION.

The default behavior of "git describe" is to fail if no tags are found,
which it does on master, and this is fine because then we want the
"0.0.0" version for releases made from master anyway.

So, I was messing with getting Ant to handle this conditional, when I
realized if we tag the very first svn commit from 2006 with a dummy
"0.0.0" tag:

git tag 0.0.0 ab0aa686820319e1

Then on the master branch, "git describe --tags" shows:

0.0.0-7062-g8a0cf14

Which is remarkably close to what we want. A "0.0.0" prefix with "extra
info as a dash". Here it's "number of commits since the found tag" and
then "sha of the current commit".

(Of course, if "git describe" was run on a commit that exactly matched
a tag, e.g. 2.5.1, then the output is just "2.5.1".)

Granted, we also (soon) have gwt.gitrev, which is just the sha, but I'm
thinking if we add this admittedly one off 0.0.0 tag, we should be able
to use "git describe" as is/with no conditionals for gwt.version.

Thoughts? Too weird?

- Stephen

(Note I've been using lightweight tags for messing around, but we could
use annotated tags...wasn't sure what we'd been using so far.)

-- 
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: gwt.svnrev

[Stephen Haberman]

> AFAICT, this error only appears if you converted a "git svn" repo to
> "plain git" (i.e. added the googlesource repo and simply do not use
> "git svn" any longer)

Ah, you are right! That makes more sense...I was fairly incredulous
that no one else would have noticed this by now.

> and I'm not sure it's worth investing time into Ant tasks

Agreed.

> (we ditched Maven in favor of Gradle, right?)

Given you've done basically 100% of the build refactoring/project
reorg, I think that is pretty much your call. :-)

I might still poke at fixing gwt.svnrev, but thanks for pointing out
the git svn vs. plain git thing.

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

Re: [gwt-contrib] gwt.svnrev

[Stephen Haberman]

> The closest is Daniel was working on adding a commit-id file

Cool, thanks for the link, I had not seen that.

Do you know what the idea of the commit-id file was? A replacement for this
"gwt.svnrev.filename"?

Looking at About.java, I think it makes sense/would be easy to replace
gwt.svnrev with the git hash, and then git.version with a git describe output,
which would be like "2.5.0" if that was the closest annotated tag.

I'll do this for our local build, then submit a CL. I can include Daniel's
commit-id if that is related.

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

[gwt-contrib] gwt.svnrev

[Stephen Haberman]

Hey,

I was building GWT master (ant dist-dev) and am getting an error in
common.ant.xml when it tries to call "git svn info", as it must think
my working copy is still from the old svn repo.

I can work on changing this over to just a "git describe", but was
curious if anyone had ran into this before/fixed it? I know Google
doesn't use the ant scripts, but still a little surprised it hasn't
been fixed yet.

Thanks!

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

Re: [gwt-contrib] Thoughts on dropwizard framework as a backend for GWT

[Stephen Haberman]

> Seems like there have been quite a few attempts ([1] is nice), but it
> doesn't seem like one has ever become widely used.

After looking at flatpack, I remember why I don't think it will take
off: it (AFAIK) assumes the server-side is Java/JPA/annotations/etc.

Swagger looks nice [1] [2] as being more/truly language agnostic, if a
bit verbose (I prefer jschema.org), and supposedly has a lot of
implementations.

Granted, Swagger/etc. are not "write an interface and GWT.create it",
but seems like we want to step away from that pattern anyway.

Instead, just run a regular code generator over one of these
Swagger/etc. schemas. At which point it's just a 3rd party library.

...perhaps at some point GWT is just JS-generation+Elemental and
everything else gets kicked out.

...actually, when can we do that? :-)

- Stephen

[1]: https://github.com/wordnik/swagger-core/wiki/Parameters

[2]: https://github.com/wordnik/swagger-core/wiki

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

[Stephen Haberman]

> I find the approach of flatpack-java from Perka interesting.

That does sound nifty; thanks for mentioning it, Jens.

I know everyone is scarred from the SOAP debacle, but I'm still
surprised that there isn't a defacto web API schema by now.

Seems like there have been quite a few attempts ([1] is nice), but it
doesn't seem like one has ever become widely used.

So instead each web API implementation is slightly one off, has
different conventions (often differing even between it's own end
points), and requires custom implementations. Ugh.

- Stephen

[1]: http://jschema.org/rpc.html

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

[Stephen Haberman]

Hi John,

Thanks for the great responses.

> do you still have to retranslate the *entire* AST to Javascript source (and is
> the resulting process still fast if you have to do so)?

Yeah, good question...seems like in an ideal world you could cache the
JS string for each compilation unit and then stream them to the
target .js file on disk. I know that's not at all how GWT works today.

> The approach i'm working on is to make change normal compiles to be
> incremental at the "per module" level. This should transparently
> speed up not just build systems, but also SuperDev mode.

That is a good point.

> In a nutshell my approach (leaving out lots and lots of edge cases) is
> this: run the GWT compiler on "Module A" with *just* the Java source
> for "Module A" and the bytecode for its dependencies provided to the
> JDT compiler. [snip]

That sounds similar to what I was thinking (although much more flushed
out instead of random arm chair musing), except done on the module
level instead of the compilation unit level.

I get what you're saying, that if done with modules, you could output
"gwtar v2" files :-), and speed both dev/prod mode up.

...well, and I'd wanted to pass in an GWT AST instead of Java source,
because I think you could very quickly get a GWT (Java) AST from the
Eclipse Java AST, so could skip the JDT step of the compilation process.

Sounds pretty awesome.

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

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

[Stephen Haberman]

Hi John,

Thanks for reminding me about this...

> The problem is let's say you change file A.

Two things:

First is that AFAIK GWT already does this...see the Dependencies class,
which I became familiar with when trying to build a list of dependencies
for Scala-GWT ASTs so they could fit in this workflow.

Second is that I want GWT to *not* do this (right now it literally
scans every classes saying "have your dependencies changed? nope. have
your dependencies changed? nope." etc.).

If I already have an IDE like Eclipse or IDEA sitting in front that is
tracking this information--why do it twice?

For example, if Eclipse sees A.java change and it knows that now B.java
must be compiled too (let's say because a method signature changed),
it could tell the GWT backend about both:

gwtBackend.update(astForA);
gwtBackend.update(astForB);

The gwtBackend would blithely trust that the front-end (whether an IDE
or a CLI daemon that has the extracted Dependencies logic in it) is
submitting a series of ASTs that is eventually well-formed.

Mutations could be done semi-non-destructively to the AST, like removing
a method doesn't actually drop the method, it makes the body "alert(this
method got deleted, you shouldn't see this message").

So the user could technically load the app at this point, but they'd
get these alerts, just like in Eclipse if you run unit tests while
methods aren't compiling you get little "btw this doesn't compile"
runtime exceptions. Same idea.

Eventually the user will fix all of their compile errors (that they're
seeing in Eclipse/CLI), the udpated ASTs which now no longer call the
method that went away will be submitted, and things will work again.

> Even if you walk down the inheritance tree, you can't just remove that
> interface, because some other ancestor might have implemented it.

I'm making all of this up, but I would mark the interface as deleted and
leave it at that. (Lots of hand waving.)

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

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

[Stephen Haberman]

Hey John,

> it means having an optional compilation path that does not recompile
> the entire world (as the current monolithic compile path does) and
> instead tries to recompile just files (or or modules) that have
> changed.

Spiffy! Out of curiosity, would the API look something like:

theBackendCompile.recompile(List filesThatChanged)

Such that the existing ResourceOracle/TypeOracle instances are mutated
with the updated state, instead of being rebuilt?

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.

...IIRC. It's been a little while since I've poked at the code.

I know I'm being a broken record, but I think the mutative/truly
incremental approach, while a (large) PITA to build, in the long run is
the only solution that would be fast enough to get SuperDevMode fast
enough such that it's "hit save in Eclipse, the js file is updated,
done!", just like Java (and web) developers are used to.

(I know Brian really doesn't like solutions that require Eclipse, but I
think the same mutative/incremental compiler API could just as well be
called by an Eclipse plugin or an IDEA plugin or even a Java daemon
polling the file system for changes. It's not IDE-specific.)

Feel free to ignore my musings given I'm not actually contributing
anything to the effort; just curious as to how things are going.

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

Re: [gwt-contrib] Re: Google team meeting notes for August 7 (and earlier)

[Stephen Haberman]

Hi Brian,

> Our plan is to make Super Dev Mode compile faster.

Have you gotten to discovering what parts are the slow ones?

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

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Stephen Haberman]

> because I don't want to spend so much extra time working on something
> that people don't really care about."

I'm sure many people, current GWT committers included, care very much
about bug fixes/improvements to the stack trace deobfuscation code.

Unfortunately, I doubt that translates to breaking out their wallet to
fund your project. It's just not sexy/motivating enough.

I would love to be proven wrong, as I also lament the lack of community
financial support around open source projects.

But I hope you won't let that less-than-ideal state of affairs mean you
leave a patch with bug fixes sitting on the shelf.

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

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Stephen Haberman]

Hi Alex,

> By the way, who wants to try it?  Please get it touch with me (alex
> at typeracer.com), and I will email you my patch so you can see for
> yourself how awesome it is.

Instead of emailing a patch, how about just uploading it here:

https://gwt-review.googlesource.com/#/

I do not think you will get very far trying to ransom your bug fixes.

I get that Kickstarter/etc. is great for new/potential projects, but
you're basically saying "well, I already built/fixed this, but crap, it
would have been nice to get paid for it...". That's not really how open
source works.

And, FWIW, if you're serious about crowdsourcing some GWT compiler
consulting, I think the "GWT moonshot" concept would be much sexier and
(relatively) more likely to get funded. Granted, it is also more work.

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

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Stephen Haberman has submitted this change and it was merged.

Change subject: Optimize initializing fields at the top scope.
..


Optimize initializing fields at the top scope.

Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
1 file changed, 108 insertions(+), 3 deletions(-)

Approvals:
  Roberto Lublinerman: Looks good to me, approved
  Leeroy Jenkins: Verified



diff --git  
a/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java

index 240f6a0..7ec2231 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
@@ -15,10 +15,10 @@
  */
 package com.google.gwt.dev.jjs.impl;

+import com.google.gwt.core.ext.PropertyOracle;
 import com.google.gwt.core.ext.linker.CastableTypeMap;
 import com.google.gwt.core.ext.linker.impl.StandardCastableTypeMap;
 import com.google.gwt.core.ext.linker.impl.StandardSymbolData;
-import com.google.gwt.core.ext.PropertyOracle;
 import com.google.gwt.dev.jjs.HasSourceInfo;
 import com.google.gwt.dev.jjs.InternalCompilerException;
 import com.google.gwt.dev.jjs.JsOutputOption;
@@ -859,7 +859,7 @@
   JVariable target = x.getVariableRef().getTarget();
   if (target instanceof JField) {
 JField field = (JField) target;
-if (field.getLiteralInitializer() != null && (field.isStatic() ||  
field.isFinal())) {

+if (initializeAtTopScope(field)) {
   // Will initialize at top scope; no need to double-initialize.
   push(null);
   return;
@@ -893,7 +893,7 @@
 @Override
 public void endVisit(JField x, Context ctx) {
   // if we need an initial value, create an assignment
-  if (x.getLiteralInitializer() != null && (x.isFinal() ||  
x.isStatic())) {

+  if (initializeAtTopScope(x)) {
 // setup the constant value
 accept(x.getLiteralInitializer());
   } else if (x.getEnclosingType() == program.getTypeJavaLangObject()) {
@@ -2207,6 +2207,39 @@

jsInvocation.setQualifier(names.get(clinitMethod).makeRef(sourceInfo));

   return jsInvocation;
 }
+
+/**
+ * If a field is a literal, we can potentially treat it as immutable  
and assign it once on the
+ * prototype, to be reused by all instances of the class, instead of  
re-assigning the same

+ * literal in each constructor.
+ *
+ * Technically, to match JVM semantics, we should only do this for  
final or static fields. For
+ * non-final/non-static fields, a super class's cstr, when it calls a  
polymorphic method that is
+ * overridden in the subclass, should actually see default values (not  
the literal initializer)

+ * before the subclass's cstr runs.
+ *
+ * However, cstr's calling polymorphic methods is admittedly an  
uncommon case, so we apply some
+ * heuristics to see if we can initialize the field on the prototype  
anyway.

+ */
+private boolean initializeAtTopScope(JField x) {
+  if (x.getLiteralInitializer() == null) {
+return false;
+  }
+  if (x.isFinal() || x.isStatic()) {
+// we can definitely initialize at top-scope, as JVM does so as  
well

+return true;
+  }
+  // if the superclass can observe the field, we need to leave the  
default value

+  JDeclaredType current = x.getEnclosingType().getSuperClass();
+  while (current != null) {
+if (canObserveSubclassFields.contains(current)) {
+  return false;
+}
+current = current.getSuperClass();
+  }
+  // should be safe to initialize at top-scope, as no one can observe  
the difference

+  return true;
+}
   }

   private static class JavaToJsOperatorMap {
@@ -2266,6 +2299,69 @@
 }
   }

+  /**
+   * Determines which classes can potentially see uninitialized values of  
their subclasses' fields.

+   *
+   * If a class can not observe subclass uninitialized fields then the  
initialization of those could

+   * be hoisted to the prototype.
+   */
+  private class CanObserveSubclassUninitializedFieldsVisitor extends  
JVisitor {

+private JDeclaredType currentClass;
+
+@Override
+public boolean visit(JConstructor x, Context ctx) {
+  // Only look at constructor bodies.
+  assert currentClass == null;
+  currentClass = x.getEnclosingType();
+  return true;
+}
+
+@Override
+public void endVisit(JConstructor x, Context ctx) {
+  currentClass = null;
+}
+
+@Override
+public boolean visit(JMethod x, Context ctx) {
+  if (x.getName().equals("$$init")) {
+assert currentClass == null;
+currentClass = x.getEnclosingType();
+return true;
+  }
+  // Do not trave

[gwt-contrib] Change in gwt[master]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Stephen Haberman has posted comments on this change.

Change subject: Optimize initializing fields at the top scope.
..


Patch Set 6:

(1 comment)

Okay, I went with the conservative approach. I'll look forward to hearing  
whether this fixes the internal perf regression.



File dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
Line 2346:   if (x.getTarget().isStatic() | 
| !x.getTarget().getEnclosingType().replaces(currentClass)) {

Done


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Matthew Dempsky 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3440

to look at the new patch set (#9).

Change subject: Optimize initializing fields at the top scope.
..

Optimize initializing fields at the top scope.

Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
1 file changed, 108 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 9
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Matthew Dempsky 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 

--
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Stephen Haberman has posted comments on this change.

Change subject: Optimize initializing fields at the top scope.
..


Patch Set 6:

(1 comment)


File dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
Line 2346:   if (x.getTarget().isStatic() | 
| !x.getTarget().getEnclosingType().replaces(currentClass)) {

You are right, fields are tricky.

At this point, I'm in favor of 1)--if/when we do miss a complex scenario,  
the worst case is that the semantics (fields being assigned too soon) will  
be GWT's current behavior.



--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Matthew Dempsky 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3440

to look at the new patch set (#8).

Change subject: Optimize initializing fields at the top scope.
..

Optimize initializing fields at the top scope.

Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
1 file changed, 119 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 8
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Matthew Dempsky 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 

--
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Stephen Haberman has posted comments on this change.

Change subject: Optimize initializing fields at the top scope.
..


Patch Set 6:

(2 comments)

Thanks all, for continuing to vet the patch.


File dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
Line 2326: public boolean visit(JMethod x, Context ctx) {
Done


Line 2346:   if (x.getTarget().isStatic() | 
| !x.getTarget().getEnclosingType().replaces(currentClass)) {
I believe it's okay because the "new UnrelatedClass(this)" call is itself a  
JMethodCall to the cstr, which would have leaked "this", and so caused the  
current class to be marked (I actually saw this happen when debugging; I  
forget which class it was for).


So--the current logic is "if you call any method on yourself, use the slow  
way" or "if you call any static/other method that could pass you, also use  
the slow way".


If I leave this check out, running CompilerTest, it goes from ~3 classes  
using the slow way (Throwable, http.client.Request, and FieldInitOrderBase)  
to ~20-25 classes using the slow way (including ArrayList due to the  
c.toArray() method call).


So, I think this is worth keeping in?


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Matthew Dempsky 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3440

to look at the new patch set (#7).

Change subject: Optimize initializing fields at the top scope.
..

Optimize initializing fields at the top scope.

Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
1 file changed, 120 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 7
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Matthew Dempsky 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 

--
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3440

to look at the new patch set (#6).

Change subject: Optimize initializing fields at the top scope.
..

Optimize initializing fields at the top scope.

Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
1 file changed, 110 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Matthew Dempsky 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 

--
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Stephen Haberman has posted comments on this change.

Change subject: Optimize initializing fields at the top scope.
..


Patch Set 5:

(2 comments)


File dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
Line 2216:  * Technically, to match JVM semantics, we should only do  
this for final or static fields. For
Well, I had added a test to CompilerTest in the last CL that does assert  
the semantics are correct/match the JVM. Which I thought was the most  
important part.


For this CL, since the optimization does not change any observable program  
behavior, I'd have to assert against the generated javascript--e.g. assert  
this field literal as assigned on the prototype.


I know other GWT tests do this (assert against the JS), but I didn't see  
any infrastructure in CompilerTest for doing that...I think I'd have to  
make a separate test and copy/paste some other approach...


Should I explore that?


Line 2225:   if (x.getLiteralInitializer() != null) {
I like minimized nested as well; will change.


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Matthew Dempsky 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Stephen Haberman has posted comments on this change.

Change subject: Optimize initializing fields at the top scope.
..


Patch Set 5:

Tweaked some comments.

--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3440

to look at the new patch set (#5).

Change subject: Optimize initializing fields at the top scope.
..

Optimize initializing fields at the top scope.

Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
1 file changed, 110 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 

--
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Stephen Haberman has posted comments on this change.

Change subject: Optimize initializing fields at the top scope.
..


Patch Set 3:

(2 comments)


File dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
Line 2342:   canObserveSubclassFields.add(currentClass);
Okay, so I implemented a very naive way of checking if "this" could escape  
via static method or other-instance instance method parameters: just  
looking at the type signatures.


It seems effective, as after also ignoring $init (which was showing up with  
the name "$$init") and ignoring super/this cstr calls, when running the  
test only 3 classes are being nominated for the correct/slow non-top level  
field init:


Throwable,
http.client.Request, and
FieldInitOrderBase (the reproduction of the original issue).

All of these nominations seem right, as, inspecting their cstrs, there is  
polymorphic dispatch to the current instance in each of them.


So I think this is pretty good.


Line 2498:* Classes that could potentially see uninitialized values for  
fields that are ininitialized in

Done


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3440

to look at the new patch set (#4).

Change subject: Optimize initializing fields at the top scope.
..

Optimize initializing fields at the top scope.

Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
1 file changed, 111 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 

--
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Stephen Haberman has posted comments on this change.

Change subject: Optimize initializing fields at the top scope.
..


Patch Set 3:

(1 comment)


File dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
Line 2342:   canObserveSubclassFields.add(currentClass);
Roberto: Ignoring calls to cstrs of this/super makes sense--they will get  
their own endVisit checks. $init I will look in to. Ignoring 0-arg static  
calls makes sense too.


Brian: I believe what Roberto is saying is that the other cstr calls will  
have their contents checked by their own  
visit(JConstructor)/endVisit(JMethodCall)s, so if we see a method call from  
1 cstr to another cstr in the same class, we can assume it will get checked  
later, and the cstr->cstr call itself doesn't mean we have to mark the  
currentClass as observing subclass fields.



--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Stephen Haberman has posted comments on this change.

Change subject: Optimize initializing fields at the top scope.
..


Patch Set 2:

(1 comment)


File dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
Line 2336:   if (x.canBePolymorphic()) {
Good point. I've updated it so that any method call results in putting the  
class into the canObserveSubclassFields set.



--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3440

to look at the new patch set (#3).

Change subject: Optimize initializing fields at the top scope.
..

Optimize initializing fields at the top scope.

Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
1 file changed, 88 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 

--
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Stephen Haberman has posted comments on this change.

Change subject: Optimize initializing fields at the top scope.
..


Patch Set 1:

(1 comment)


File dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
Line 2234:   // method. For now, assume that they might.
Done


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Stephen Haberman has posted comments on this change.

Change subject: Optimize initializing fields at the top scope.
..


Patch Set 2:

Okay, I added a visitor to detect cstrs with polymorphic method calls.  
Thanks, Roberto, that saved me a lot of time.


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 
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]: Optimize initializing fields at the top scope.

[Stephen Haberman]

Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3440

to look at the new patch set (#2).

Change subject: Optimize initializing fields at the top scope.
..

Optimize initializing fields at the top scope.

Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
1 file changed, 92 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3440
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I97a06eb36396a8b8659ce9a025b21a9cf93d0500
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman 
Gerrit-Reviewer: Brian Slesinsky 
Gerrit-Reviewer: Leeroy Jenkins 
Gerrit-Reviewer: Roberto Lublinerman 
Gerrit-Reviewer: Stephen Haberman 

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