Re: [gwt-contrib] Static fields on JavaScriptObjects

[Colin Alworth]

The problem with this answer is that the failure is silent and surprising
for Java developers, and that the optimizations can make it even more so.
If I recall correctly, calling a static method in the same type from an
instance method is not enough to get the static initializer called - an
optimization prunes the clinit.

I have a patch that restores clinits from instance methods, but I'm out of
reach of it at the moment. I haven't made a code review yet in the interest
of adding tests for this case.

If we do decide that cl units should be pruned, we should stop cutting them
from other newly 'static' methods - at least in that case bit must be a
bug. If not that, then emit a warning?
On Mar 16, 2013 1:44 PM, Daniel Kurka kurka.dan...@gmail.com wrote:

 Thanks John for clearing this up. This was exactly what I had in mind. I
 will close the issue AsDesigned, maybe we should document this is little
 better.

 -Daniel

 Am 16.03.2013 um 20:40 schrieb John A. Tamplin j...@jaet.org:

 On Sat, Mar 16, 2013 at 3:09 PM, Daniel Kurka kurka.dan...@gmail.comwrote:

 I am a little confused about some issues I encountered on the issue
 tracker and need some help.

 This one is about a static field on a JSO:
 https://code.google.com/p/google-web-toolkit/issues/detail?id=8060

 From the docs:
 Overlay types cannot have instance fields. The fields would have no place
 to live in web mode. Programmers should instead make an explicit wrapper
 class and put the fields there.

 JavaScriptObjects are created in JavaScriptCode (this is why they need a
 at least protected constructor). Do we have a clinit for JSOs or am I
 assuming correctly that this is a misuse of a JSO?


 JSOs can't have clinits, since generally they are created by pure JS code,
 and in particular it is likely code outside of GWT's control.  You
 conceivably could allow default-initialized static fields (which would
 basically just be namespaced globals), but I'm not sure what the point is.

 I suppose you could also allow static finals that are just compile-time
 constants (hoisting initializers to always happen has been discussed, but
 could potentially execute expensive code at startup), but I think it is
 better to leave it out than to have only partial support.

 --
 John A. Tamplin

 --
 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




  --
 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Static fields on JavaScriptObjects

[Colin Alworth]

If you call a method or access a field from pure JS, you aren't going to 
get the JSO implementation - 
com.google.gwt.dom.client.Element.removeClassName(String) doesn't exist in 
the underlying browser, so we build it in Java, and talk to methods/fields 
which *do* exist in the browser. In other cases we dispatch to static 
methods that exist elsewhere in GWT. You can't call it from pure JS, so how 
it works or what it needs shouldn't be considered when looking at how JSO 
should behave and what code should be emitted.

There are many static fields which exist in existing JSOs already, but most 
(all?) are final, and are Strings or other primitives, so are already 
constants, not just fields. In the linked bug, an array is being kept, and 
it isn't initialized in time. I've only found one case of a static field in 
a JSO, and the docs suggest that it is optimized for dev mode. 
Hypothetically, if Document were subclassed (it isn't final) and get() were 
invoked by an instance method (consider referring to another document from 
within an iframe), this issue could be tickled if it weren't for that 
'optimization':
  /**
   * We cache Document.nativeGet() in DevMode, because crossing the JSNI
   * boundary thousands of times just to read a constant value is slow. 
   */
  private static Document doc;
  
  /**
   * Gets the default document. This is the document in which the module is
   * running.
   * 
   * @return the default document
   */
  public static Document get() {
if (GWT.isScript()) {
  return nativeGet();
}

// No need to be MT-safe. Single-threaded JS code.
if (doc == null) {
  doc = nativeGet();
}
return doc;
  }

I recognize that the primary intent of JavaScriptObject is to offer a Java 
API to a JavaScript object, but there are plenty of cases where that JSOs 
are used to achieve other points, or contain logic beyond what might 
normally be necessary. Ray Cromwell wrote a post a few years ago that 
encouraged using JSOs to 'cheat' the Java type system a bit - 
http://timepedia.blogspot.com/2009/04/gwts-type-system-is-more-powerful-than.html
 
- these examples don't make use of fields, but it seems a logical next step 
to add a little logic to some of these psuedo-categories.

To look at my own use case, GXT extends Element as XElement to allow Java 
method calls to cache some values as XElement is used. We've worked around 
this by moving those to a static inner non-JSO type - they remain private, 
static, and final, and behave as expected with this workaround.

So, with all of this in mind, a change to make this 'as designed' will 
warn/error on any static field that is not a) final and b) 
String/primitive, and on any static block? Or, can we consider the utility 
of the JSO class to be something that is actually meant to be used only 
from Java, so we don't care what happens to the underlying JavaScript 
object, and how that continues to behave as JS normally would?

On Saturday, March 16, 2013 4:43:13 PM UTC-5, John A. Tamplin wrote:

 On Sat, Mar 16, 2013 at 5:30 PM, Colin Alworth nilo...@gmail.comjavascript:
  wrote:

 The problem with this answer is that the failure is silent and surprising 
 for Java developers, and that the optimizations can make it even more so. 
 If I recall correctly, calling a static method in the same type from an 
 instance method is not enough to get the static initializer called - an 
 optimization prunes the clinit.

 I have a patch that restores clinits from instance methods, but I'm out 
 of reach of it at the moment. I haven't made a code review yet in the 
 interest of adding tests for this case.

 I don't see how you can add clinits on a JSO -- the point is it is a plain 
 JS object under the hood (ignoring all the magic to make it work in 
 DevMode).  If you call a method or access a field from pure JS, how can it 
 know to call the clinit?

 If we do decide that cl units should be pruned, we should stop cutting 
 them from other newly 'static' methods - at least in that case bit must be 
 a bug. If not that, then emit a warning?

 I'm fine with making it an error. 

 -- 
 John A. Tamplin 

-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] widget interfaces

[Colin Alworth]

On Thu, Mar 21, 2013 at 9:24 PM, Stephen Haberman
step...@exigencecorp.comwrote:


  Also we can use this as an opportunity to provide a compatibility
  layer across different vendors and/or different widget systems.

 I suppose, technically yes. That is more complex than what I really had
 in mind...but if gets me widget interfaces, I suppose I'm interested.

 In general I'm skeptical about vendor agnostic widget APIs, because
 given how nit-picky perfect UIs have to be, it doesn't seem realistic to
 be able to switch implementations and still have things look right
 (other than some trivial theming).


Agreement on this point - within GXT we annoy developers by not
implementing HasClickHandlers on our buttons, but instead using our own
HasSelectHandlers (distinct from HasSelectionHandlers). This frees us to
not require the 'click' event to activate a button - the user can tab into
a button and hit the space bar, even if the dom element doesn't magically
turn key events into clicks. Likewise some menu items (i.e. those with a
sub menu) activate on hover, while others on click. We've made a point of
distinguishing between the dom events and the logical events - effort to
standardize these interfaces will need to be careful to cover these details.


  In upcoming weeks, we will start talking more about improving
  UI+widget development in GWT. It is good to wait until that gets more
  concrete before introducing/changing any APIs.

 No problem. Sounds interesting!

 Also, I'm really glad to hear you'll be keeping us non-Googlers in the
 loop. Perhaps it is naive, but with the re-open sourcing of GWT, I'd
 love to see more of Google's internal conversations about GWT happen in
 a public forum, like gwt-contrib.

 Totally understood that you can't discuss internal business details on a
 public forum, but it seems like a lot of open source projects have
 technical, cross-company discussions on their open mailing lists.


+1

-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Use JSON.parse() instead of eval() to deserialize rpc callba...

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Use JSON.parse() instead of eval() to deserialize rpc  
callback payload

..


Patch Set 1:

(1 comment)

The ServerSerializationStreamWriter will also need modifications, two that  
I can think of:
 * writeLong currently is using  instead of ', which isn't valid in JSON.  
This should be failing in the unit tests, as long as testing something that  
uses parse instead of eval.
 * very large payloads will now break when the array concatenating code  
kicks in, writing ].concat([ to join arrays that are otherwise too big for  
ie6/7 (and 8?). This isn't valid JSON, so this will break when the object  
graph reaches a certain size.


Can you make sure to run the unit tests remotely in each IE version to  
verify that you changes will behave? I believe there is a test for each  
direction of each primitive, but not a test for very large data sets.



File  
user/src/com/google/gwt/user/client/rpc/impl/AbstractSerializationStreamWriter.java

Line 97:   append(0);
Infinity does actually work round trip in my quick testing in this way, as  
1e1000 or the like is a) legal json and b) outside the range of double, so  
will end up as +Infinity on the JS side after parsing, or when wrapped up  
in Double.parseDouble. However, 0 being used as NaN won't fly, you're  
right. One idea is to emit null, then read out the null as a special case -  
in my testing this behaved well in all browsers.


Sending the strings +Infinity, NaN could also work, but then you need  
parse those as strings, not as numbers after reading it as json, i think in  
my first try at this I decided that was more trouble than it was worth.


No need to use = or = for infinity checks, == should be sufficient.

writeFloat will also need similar treatment.


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

Gerrit-MessageType: comment
Gerrit-Change-Id: I6062180397f5fabed1dd5f08140c2bd43a19fa9f
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Ahlroos j...@vaadin.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Add hasClassName method in com.google.gwt.dom.client.Element

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Add hasClassName method in com.google.gwt.dom.client.Element
..


Patch Set 3: Code-Review-1

As an idea, looks good, but remember that JSOs are a particularly bad place  
to add new arbitrary methods, especially mid-release (i.e. consider 3.0).  
Any downstream code that extends Element and has a method with the same  
signature is going to break.


As an example (admittedly, one that I am biased toward), GXT has a Element  
subclass class that supports this very same method signature,  
hasClassName(String). Adding final methods to non-final classes in general  
must be done carefully - since in a JSO either all methods must be final or  
the type itself must be final, all new methods should be carefully  
scrutinized.


My vote would be that this would be implemented in a different way to not  
require new methods, at least for 2.x - breaking changes with downstream  
code isn't generally expected in minor releases (though that hasn't stopped  
us in the past, see JClassType about 2.2.0). The 3.0 release might be a  
better target for the patch as-is.


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

Gerrit-MessageType: comment
Gerrit-Change-Id: Ia09567b8c58cac02f8126c33ef169b26def3d19c
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com
Gerrit-Reviewer: Andrey Korzhevskiy a.korzhevs...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-HasComments: No

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: widget interfaces

[Colin Alworth]

What are we looking at having in these interfaces? The discussion that
Goktug and I had a few months ago got stalled around the concept that these
interfaces were trying to both be a) implementation independent but also b)
rich enough to be useful. Doing both is hard/meaningless.

To pick an example, button has a few basic premises (in the standard GWT
widgets) - it has text (or html if you support a base other than an
input), it can receive focus, and it is a source of click events. In a
perfect world an implementation could be backed by an appearance (perhaps
wrapped itself in a cell) like the TextButton...

But this ends up meaning that 'click' events aren't the only thing to worry
about - a div won't pass along key events like space or enter as a means
of activating the button. So we either need to also emit key events, and
touch events, or need to wrap all of these in one event (GXT calls it a
SelectEvent).

Either we have a backward compat problem (can't represent both past and
future button-ish widgets with the same interface), or we limit the button
implementations to a single setup (must be backed by button or input,
or perhaps an a?).

So, my point: Is the purpose of the IsButton *only* to be an interface for
com.google.gwt.user.client.ui.Button? Or are we trying to build this out
for the ideal button (and ideal text box, etc)?

On Wed, Jun 5, 2013 at 4:28 PM, Ed post2edb...@gmail.com wrote:

 The simpler thing than buffering is just to have a StubButton, e.g.:

 A, how could I forget ;)... I just remember the Stubs* Widgets in your
 gitHub  ;)

 But is this even needed ?
 If you use a template mechanism it might not be needed.
 The template is created during setStyle() and other operations and only
 used in GWT client mode when the underlying Widget is created...

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






-- 
218.248.6165
niloc...@gmail.com

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

[Colin Alworth]

Slight follow up to both Stephen's comments here and my own prev post - If
the interfaces are for existing, standard, built-in GWT widgets, type 2
makes a lot more sense, whereas for type 1, we really seem to need a
general, ideal button that can be replaced by any implementation (with
possibly any internal rebuilding via appearance/cells/etc).

-Colin

On Wed, Jun 5, 2013 at 4:36 PM, Stephen Haberman
step...@exigencecorp.comwrote:


  Yeah this Type 1 style is really PITA in the long term, especially if
  views are a bit more complex.

 I disagree; I actually prefer Type 1. Although to each their own, of
 course.

  However, with the release of UiBinder we constantly tell
  people/recommend to use the Type 2 style of MVP with UiBinder +
  @UiHandler and a delegate interface if they ask for MVP in
  gwt-discuss.

 UiHandler makes inner classes 2 lines shorter, but IMO it still leads
 to the same spaghetti code (reactive/imperative, instead of
 declarative).

 Tessell's binding DSL makes simple/common operations one line
 declarations (explicitly via Type 1-exposed widget interfaces, not
 UiHandlers). E.g. I don't see how UiHandlers/Type 2 could be as
 succinct as:


 https://github.com/stephenh/todomvc-tessell/blob/master/src/main/java/org/tessell/todomvc/client/app/TodoPresenter.java#L43

  So I think this argument looses some weight as probably no one really
  wants to do the type 1 way anymore and only a minority still choose
  it for new projects.

 Well, that is unfortunate, as MVP Type 1 with Tessell's view generation
 and binding DSL is quite pleasant. But, again, to each their own. :-)

  No need for GWTMockUtilities.disarm() or gwtmockito then.

 Exactly.

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





-- 
218.248.6165
niloc...@gmail.com

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Add hasClassName method in com.google.gwt.dom.client.Element

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Add hasClassName method in com.google.gwt.dom.client.Element
..


Patch Set 6: Code-Review+1

Nope, we can work with it - a wrapper isn't really an option, since we get  
real benefit from getting static methods that look like instance ones  
without the mess of static imports or new-ing up instances that wrap the  
original elt just long enough to run a method on them and gc them (unless  
the compiler now can unwrap that single final field and method and treat it  
as if it were static to begin with?). We used to have a great big flyweight  
thing going on to avoid the extra object creation, but move to extending  
Element to avoid that little extra cost...


My main point was to bring it up as a point to discuss, to make sure that  
adding a new final method to a non-final class was deliberate. GXT is happy  
to plan ahead and remove it before 2.6 lands (and thanks for the heads up  
on toggleClassName), and move to something else in the meantime, we'd just  
rather not make a habit of that, cutting new specific gxt minor releases to  
accommodate specific gwt minor releases, and I'm sure we're not alone in  
that.


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

Gerrit-MessageType: comment
Gerrit-Change-Id: Ia09567b8c58cac02f8126c33ef169b26def3d19c
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Add hasClassName method in com.google.gwt.dom.client.Element

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Add hasClassName method in com.google.gwt.dom.client.Element
..


Patch Set 6:

Thanks Goktug - one of the distinct advantages of extending Element is that  
we can subclass UiObject.getElement and already have access to the methods  
we want, and on the other side the subclass can invoke Element methods  
(without the pretend-jso-cast). As I understand it, from your example,  
GxtElement is superfluous - we'd need to .cast() to GxtElement to even get  
the .cast() method to get GxtExtensions ;).


(wrapping up, as Andrey's code review probably isn't the place...) W.R.T.  
devirtualization, that doesn't quite go far enough - constructors do not go  
away, and the this$static is still needed, even though it is only to grab  
the one field inside it. And while v8 might do the alias analysis and drop  
the ctor, I'm all by certain that IE6-9 don't (and 10 would be a guess).


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

Gerrit-MessageType: comment
Gerrit-Change-Id: Ia09567b8c58cac02f8126c33ef169b26def3d19c
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Andrey Korzhevskiy a.korzhevs...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Add interfaces for widgets.
..


Patch Set 6:

(4 comments)


File user/src/com/google/gwt/dom/client/HasStyle.java
Line 29:   void setStyleName(String styleName);
Might be worth adding hasStyleName, as this was recently added to Element -  
Goktug indicated in that review that a toggleStyleName is on the way as  
well. https://gwt-review.googlesource.com/#/c/3070/




File user/src/com/google/gwt/dom/client/IsElement.java
Line 61:   void appendChild(IsElement element);
This method seems out of place - it is the closest we get to dom  
manipulation - no removeChild(IsElement) nor IsElement getParentElement()  
or any getChild (which may not be). Is there a reason you picked this and  
removeFromParent, but not other dom methods? Variance issues almost explain  
it, but then I noticed that you needed to add new methods just to support  
this in Element itself.


And since you already are needing to add new methods in Element to deal  
with IsElement vs Node, would it make sense then to add new methods for  
these?




File user/src/com/google/gwt/user/client/ui/IsUIObject.java
Line 27:   IsElement getIsElement();
My concern there would be that we'd no longer have a way to get access to  
the element as a jso in the code that needs it. If I wanted the element so  
I could treat it as a InputElement, the JSO.cast() is no longer available  
to me, only the regular Java cast. Not a huge loss, but it definitely is a  
breaking change.


Simple/ugly way around that might be to rename IsElement.asElement to  
IsElement.cast, with the JSO.cast generics. Returns null for stubs, and  
with a real element lets you cast as usual.




File user/src/com/google/gwt/user/client/ui/IsWidget2.java
Line 28: public interface IsWidget2 extends IsWidget, IsUIObject,  
EventListener, HasHandlers,
(Sorry if I missed this discussion elsewhere, but) What is the  
philosophical thinking on IsWidget vs IsWidget2? This is for mocking  
Widget, while IsWidget is for Composite-free composition? If that is the  
idea, what about another name than IsWidget2, which seems to  
suggest 'better isWidget' rather than 'mockable iswidget'.



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

Gerrit-MessageType: comment
Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.

[Colin Alworth]

Colin Alworth has uploaded a new change for review.

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


Change subject: Ensure clinits get called for JSO instance methods.
..

Ensure clinits get called for JSO instance methods.

In following Java semantics, any static initialization code in a class
(collectively a clinit) should be run before any part of that class is  
used. To

achieve this, GWT ensures that this clinit was invoked before any (actually)
static method, and as part of any constructor. This way, instance methods  
are

sure to have already run the clinit, so it doesn't need to be run again.

However, JSO constructors don't exist, so instance methods are not  
guaranteed to
have had the clinit already run. This is the bug that this patch is trying  
to

fix.

Two locations are changed, both with the effect of ensuring that a clinit is
emitted for JSOs. First, the MethodInliner must not skip adding a call to  
the
clinit when the jso body is inlined and the method invocation (and ref to  
the

class) is dropped, and second, GenerateJavaScriptAST must likewise write out
explicit clinits for any static method or jso instance method.

Bug: issue 3192
Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
2 files changed, 4 insertions(+), 4 deletions(-)



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..1c7944a 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
@@ -2189,10 +2189,10 @@
   if (!crossClassTargets.contains(x)) {
 return null;
   }
-  if (x.canBePolymorphic() || program.isStaticImpl(x)) {
+  JDeclaredType enclosingType = x.getEnclosingType();
+  if (x.canBePolymorphic() || (program.isStaticImpl(x)  
 !program.isJavaScriptObject(enclosingType))) {

 return null;
   }
-  JDeclaredType enclosingType = x.getEnclosingType();
   if (enclosingType == null || !enclosingType.hasClinit()) {
 return null;
   }
diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java  
b/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java

index d2b05ae..6acbb49 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
@@ -169,8 +169,8 @@
 // Access from this class to the target class won't trigger a  
clinit

 return null;
   }
-  if (program.isStaticImpl(x.getTarget())) {
-// No clinit needed; target is really an instance method.
+  if (program.isStaticImpl(x.getTarget())  
 !program.isJavaScriptObject(x.getTarget().getEnclosingType())) {

+// No clinit needed; target is really a non-jso instance method.
 return null;
   }
   if (JProgram.isClinit(x.getTarget())) {

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

Gerrit-MessageType: newchange
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth niloc...@gmail.com

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Ensure clinits get called for JSO instance methods.
..


Patch Set 1:

Afraid not, this is the exact same patch we looked at - only difference was  
that I pulled the sys.out.println I was using to debug the circumstances  
for this fix.


W.r.t. test cases, would those be best in the form of a test JSO that  
demonstrates the issue, or something that actually builds a sample ast and  
verifies that JsInvocations or JMethodCalls are created for the clinit? I  
have the test sample from the original bug report that could be made into a  
GwtTestCase, but that seems a little more testing the effect than the bug.  
That said, I'm not seeing (or perhaps not looking in the right place for) a  
lot of test cases that make sure the generated JS is sane.


One last thought - while moving this from SVN to Git, it occurred to me  
that this same fix could potentially be achieved in another way: In the  
same way that MakeCallsStatic ties newly static calls to their original  
instance version via JProgram.putStaticImpl, it appears that  
JsoDevirtualizer could do the same. This would make these methods show up  
as needing a clinit when the `program.isStaticImpl(x.getTarget())` check is  
made (as in MethodInliner.createClinitCall. From your general gwtc point of  
view, does that seem to be a reasonable (as well as clearer) fix?


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

Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-HasComments: No

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.

[Colin Alworth]

Hello Leeroy Jenkins,

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

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

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

Change subject: Ensure clinits get called for JSO instance methods.
..

Ensure clinits get called for JSO instance methods.

In following Java semantics, any static initialization code in a class
(collectively a clinit) should be run before any part of that class is  
used. To

achieve this, GWT ensures that this clinit was invoked before any (actually)
static method, and as part of any constructor. This way, instance methods  
are

sure to have already run the clinit, so it doesn't need to be run again.

However, JSO constructors don't exist, so instance methods are not  
guaranteed to
have had the clinit already run. This is the bug that this patch is trying  
to

fix.

Two locations are changed, both with the effect of ensuring that a clinit is
emitted for JSOs. First, the MethodInliner must not skip adding a call to  
the
clinit when the jso body is inlined and the method invocation (and ref to  
the

class) is dropped, and second, GenerateJavaScriptAST must likewise write out
explicit clinits for any static method or jso instance method.

The jso methods for the unit tests include methods that seem slightly  
convoluted
to avoid being inlined - once inlined, the clinit would re-appear (as it  
shoud,
since the static field is being accessed directly). Each situation being  
tested
requires its own type, since the test app would require being restarted to  
empty
out each static field. Note that prior to this fix, only the instance  
method
case failed and returned null - the other situations are added just to  
ensure

that everything else is behaving as expected going forward.

Bug: issue 3192
Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
---
M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
M user/test/com/google/gwt/dev/jjs/test/JsoTest.java
3 files changed, 70 insertions(+), 4 deletions(-)


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

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Ensure clinits get called for JSO instance methods.
..


Patch Set 2:

(2 comments)


File user/test/com/google/gwt/dev/jjs/test/JsoTest.java
Line 49:   static final class ClinitStaticFieldFirst extends  
JavaScriptObject {

Correct - the commit message documents this, but I'll stick a comment too.


Line 54:   if (FIELD == null) {
Again, commit message touched on it. The bug only manifests in compiled  
code, and the compiler will inline this if it is too simple. I was going  
for the simplest code I could write that would not be optimized out (at  
least in draft mode) without using JSNI. Not that there is an issue with  
JSNI here, just that I wanted to keep the issue on track for following Java  
semantics. Once the method gets inlined, the bug goes away, since the  
outside code is accessing the field, and any static field access requires a  
clinit (which the compiler doesn't forget before this patch).



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

Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-HasComments: Yes

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Ensure clinits get called for JSO instance methods.
..


Patch Set 2:

(1 comment)


File dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
Line 172:   if (program.isStaticImpl(x.getTarget())  
 !program.isJavaScriptObject(x.getTarget().getEnclosingType())) {
The extra condition (both here and in GenerateJavaScriptAST) deals with the  
fact that MakeCallsStatic registers instance methods as static with  
JProgram, while JsoDevirtualizer does not. This seems reasonable at first,  
though since JSOs are *always* made static, there might be other  
implications. I suggested this in my first comment in this change request,  
but John seemed to think that this approach made more sense. That said, I  
haven't actually tried making that change, and seeing what else is affected  
(i.e. all other callsites of JProgram.isStaticImpl or .getStaticImpl).



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

Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-HasComments: Yes

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.

[Colin Alworth]

Colin Alworth has posted comments on this change.

Change subject: Add interfaces for widgets.
..


Patch Set 8:

What is the thinking for the remaining 10%-ish of widgets - all of the cell  
widgets (except CellPanel), remaining *boxes (DateBox, various number-Box),  
RichTextArea, missing *LayoutPanels (SplitLayoutPanel, LayoutPanel,  
HeaderPanel, DeckLayoutPanel), etc? Future patch, or less important? I  
could see skipping most of the boxes, since the api should be relatively  
similar since subclasses mostly modify internal behavior, but then you have  
IsNumberLabel which just makes the generics more explicit (and should  
almost certainly be extending IsValueLabel to get those other  
super-interfaces...). Then there are the layout panels which arguably look  
like HasWidgets.ForIsWidget, but if IsElement gets so specific as to allow  
direct dom manipulation, it seems reasonable to allow layout manipulation  
as well.


AbstractHasData and subclasses (lots of cell widgets) is a nice abstract  
class which already has most -- but not all -- methods declared in various  
interfaces.


Unless we're waiting for a future patch to finish the job, I'm not yet  
understanding the approach in which classes get selected for this treatment  
and which types/methods get a pass. I don't mean for this to stand in the  
way of this patch, but to suggest that the strategy is sufficiently unclear  
that we could probably use a gwt-site doc on this or a body of javadoc that  
covers how these are intended to be used, and how widget  
authors/maintainers should behave to make their code usable by downstream  
users who like these interfaces for testing.


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

Gerrit-MessageType: comment
Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9
Gerrit-PatchSet: 8
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: Nextgen GWT/JS Interop (Public) (google-web-tool...@googlegroups.com)

[Colin Alworth]

Nice writeup. Comments/questions (since comments seem disabled in the docs):

 * @Entry looks great - there has been some discussion in IRC about some 
way to do this for easier library wrapping code, but every direction we 
looked at with JSOs ended up with a little more cruft than we really wanted 
to see. Maybe worth mentioning that $entry doesn't just do exceptions, but 
also makes scheduleFinally behave as expected.
 * Constructors - how is one supposed to new up an object that implements a 
specific interface without making your own implementation (and thus 
declaring new implementations)? Are we keeping the static-method-only 
restriction, or can we use new? Similarly, how will these objects pass 
through the java/js barrier - are they to be a special class of objects in 
JSNI, allowed to be manipulated in plain JS instead of opaque objects, but 
still able to be instanceof'd?
 * Java 8 support/requirement - currently the GWT release jars are compiled 
to target java 6 (according to common.ant.xml), so that they can be used in 
a project that supports either 6 *or* 7 (and of course newer). If this new 
code is used at all internally with java8-only features, does this mean 
that support will be *dropped* for both 6 and 7 instead of merely *adding* 
java 8 support?
 * (JSNI doc) primitives - why support for long, which JS VMs don't 
actually support, but not float/short/byte?
 * (JSNI doc) forEach - will there be a function/callback interface that 
will be autowrapped in $entry and bind to be passed in, or will this simply 
access a JSO that will be treated as a function?


On Tuesday, August 6, 2013 2:24:47 AM UTC-5, Goktug Gokdogan wrote:

 I've shared an item with you.

 This is a design doc that describes a proposal for improving interoperability 
 with GWT and javascript. The proposal provides some essential pieces to 
 provide better and easier interoperability with JS while putting more complex 
 scenarios (e.g. Web Components) and testability into account.

 Please take a look and provide us some feedback.

 Cheers,

  - Goktug

 [image: Document] Nextgen GWT/JS Interop 
 (Public)https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit?usp=sharing
  
 Google Drive: create, share, and keep all your stuff in one place. [image: 
 Logo for Google Drive] https://drive.google.com


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

[Colin Alworth]

I got a tweet from you asking for a donation (or rather a 'partner', which
apparently means 'money'), but couldn't frame a useful response in 140
chars, so since this thread is coming back, I thought to do so here
instead.

What license are you offering these code samples under - if it isn't
something open and available, what is the benefit to an advance copy of the
jar if I, an author of a library and several open source tools and
applications, cannot provide it to my customers or other downstream users?

We've found that https://gist.github.com/niloc132/3906501 goes a heck of a
long ways toward offering optional debug info - if not enabled, the user
gets the normal-size application with zero size or performance hit, and by
redirecting to a slightly different url, the full trace info can be pulled
out (with the quirks you mention of course*), which typically goes a long
ways toward identifying the real issue.

* How often have you needed to know which line of Impl.java or DOMImpl.java
a stack trace intersects? To make your case more effectively, you might
consider using code where it is meaningful to see those lines, something
other than the equivelent of
java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life
JSNI, or an annoying IE6-9 focus() or setAttribute issue?

You touch briefly on the risk of '[exposing] your application’s
implementation details', but unless I am mistaken, the extra metadata
included in the file:line ints should still be enough to take apart an app
and map it to discrete files and reconstruct methods, even un-inlining (as
you mention) to pull out clearer details. My understanding was that the
premise of the sourceMap was to work entirely from the stack to allow the
actual source to be obfuscated, and avoid any other metadata from being
left in the compiled output. Combine this with the fact that many of those
classes are publicly available (GWT itself, etc), and it seems that you
could reverse out a significant portion of the app - the secret sauce.
Can you comment on using this for public applications and any reverse
engineering attempts you've made?


On Mon, Aug 19, 2013 at 3:06 PM, Alex Epshteyn alexander.epsht...@gmail.com
 wrote:

 Hello folks,

 I just wanted to remind everyone that the last day to fund this project is
 this Friday, August 23.

 I've been using this framework in production in my app now for 2 months,
 and it works great.  Have logged 70,000 perfect stack traces so far!
  Already fixed 3 major bugs in my GWT-based UI code that I would NEVER
 found otherwise.

 Let's get this capability into GWT by the end of the year.  Please donate!

 Thanks,
 Alex



 On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote:

 Dear fellow GWT users,

 I would like to announce that I have finally solved what I always thought
 to be GWT's greatest weakness: its lack of debugging information for
 client-side exceptions in production.

 With my patch, your deployed app will be able to report stack traces like
 this:

 com.google.gwt.core.client.**JavaScriptException: (TypeError) : a is null
 com.google.gwt.dom.client.**DOMImplMozilla.$**getBodyOffsetLeft(**
 DOMImplMozilla.java:145)
 com.google.gwt.user.client.ui.**PopupPanel.$setPopupPosition(**
 Document.java:1287)
 com.google.gwt.user.client.ui.**PopupPanel.setPopupPosition(**
 PopupPanel.java:884)
 com.google.gwt.user.client.ui.**PopupPanel.PopupPanel(**
 PopupPanel.java:453)
 com.typeracer.commons.client.**widgets.EnhancedPopup.**
 EnhancedPopup(EnhancedPopup.**java:32)
 com.typeracer.commons.client.**widgets.PopupWithIcon.**PopupWithIcon(**
 PopupWithFocusableTextBox.**java:28)
 com.typeracer.main.client.**controller.**TyperacerUncaughtExceptionHand**
 ler$1.execute(**TyperacerUncaughtExceptionHand**ler.java:55)
 com.google.gwt.core.client.**impl.SchedulerImpl.**runScheduledTasks(**
 SchedulerImpl.java:50)
 etc... :-)


 instead of the current state of affairs that looks like this:

 lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName:
 http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**B8.cache.htmlhttp://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html

 stack: @http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
 B8.cache.html:2422http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422

 Rub@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
 B8.cache.html:2423http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423

 dSb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
 B8.cache.html:3190http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190

 tA@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
 B8.cache.html:2810http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810

 Xmb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
 B8.cache.html:2289http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289

 etc... :-(


 I am asking the community to support me 

[gwt-contrib] Gwt benchmarks without Benchmark

[Colin Alworth]

Shortly after 2.5.1, the Benchmark classes were removed from GWT 
(https://gwt.googlesource.com/gwt/+/39eb6001a037fd8b6580a73a2540e6e9c04e54c2 
and 
https://gwt.googlesource.com/gwt/+/00c7ce43df3a629b7302ab902a07431db7224e2b) 
- what are folks using for low-level performance testing these days?

I'm wrapping up a changeset to emit JS TypedArrays when int[], double[], 
etc are used in code, and while I can see that some projects clearly 
improve with this, others seem to take a hit (specifically in rapidly 
allocating arrays that have a short lifetime). I'd like to record some 
numbers to paint this picture without rolling my own benchmark/gwtPerf 
tool, but I'm not quite clear on the current state of this sort of metrics. 

From the comment that originally deprecated the Benchmark class:

 This didn't get enough adaption externally or internally. The way it's 
 implemented requires special support from GWTTestCase infrastructure. Also, 
 we are not going have an environment to automate benchmarks written on this 
 any time soon.

 If there is enough demand later, parts of this code can be resurrected to 
 build a new benchmark system.


Thoughts?
-Colin

-- 
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] CSS3 support in CssResource: Closure Stylesheets?

[Colin Alworth]

I'd be interested in helping with either approach. The phloc-css project 
looks interesting if we are only trying to add support for newer CSS 
features, while integration with Closure Stylesheets seems geared more 
toward extending the CssResource featureset. Much of the existing 
functionality in GWT's CssResource is also in closure in some capacity, 
though the implementation is likely different enough to cause interesting 
issues. There are advantages to making it through those differences - 
mixins for example.

Another thought would be to implement both - expand CssResource to support 
new properties with phloc-css, and create a new ResourcePrototype 
(StylesheetResource perhaps?) with its own resource generator to put code 
through closure's wringer. 

-Colin

On Monday, August 26, 2013 5:38:45 AM UTC-5, Julien Dramaix wrote:

 Hi all,

 Just to inform you that I would like to give a try to add support of CSS3 
 in GWT if nobody is working on.

 After some research, I found another open source CSS parser in java 
 supporting CSS3 : https://code.google.com/p/phloc-css If we need only a 
 parser it could be a interesting alternative to Closure syle sheet.

 What do you think ?

 Julien


 On Thursday, February 2, 2012 9:38:02 AM UTC+1, Thomas Broyer wrote:

 On Thu, Feb 2, 2012 at 7:05 AM, Ray Cromwell cromw...@google.com wrote:
  Sorry to hear that. This is actually on our list of priorities for
  GWT, so we will have to take this up internally.

 Just a clarification: I was trying to replace Flute with the parser
 from Closure Stylesheets, replacing the whole CssResource processing
 (or creating a GssResource) with one based on Closure Stylesheets
 should be relatively easy though. For now, my priorities are fixing
 the remaining RF bugs and hope my half-a-dozen-or-so patches will land
 in 2.5 (we're helping a company switch to web apps in GWT, and I'd
 recommend them to use RF over RPC if there wasn't so many pitfalls
 [1], having the fixes in 2.5 would help make the choice based on the
 actual features and limitations due to their designs, rather than
 ditch RF based only on its known bugs [2]). I had very little time
 these past weeks so I couldn't even try fixing issue 6710 which, to
 me, is higher priority.

 So, when I'll have time and have fixed 6710 (the last remaining
 blocker IMO), I'll see if I can help integrating Closure
 Stylesheets, but I'm afraid not before. Does that sound good to you?

 [1] That one in particular caught me when upgrading to a recent
 trunk last fall, it's not documented and I can't say if it's a bug or
 simply a limitation due to batching:
 http://code.google.com/p/google-web-toolkit/issues/detail?id=7120#c1
 [2] One such example:
 http://code.google.com/p/google-web-toolkit/issues/detail?id=7120#c2



-- 
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] CSS3 support in CssResource: Closure Stylesheets?

[Colin Alworth]

I spent an hour or two last night playing with phloc-css, and it doesn't 
seem to be quite as flexible as flute in terms of adding custom behavior 
for unknown @-rules (@def, @sprite, etc), or handling arbitrary (and 
unknown to both flute and phloc-css) functions like literal() and value(). 
I played briefly with modifying the jjt file, but realized that any gain 
made there comes at the cost of re-namespacing and trying to rebase such a 
change along as phloc-css changes. As a drop-in replacement, I'm not seeing 
a good strategy here, though I'm open to suggestions. 

Closure doesn't quite seem a perfect fit either, though perhaps I am 
missing some details about it (I've only gone through the docs at 
http://code.google.com/p/closure-stylesheets/ and the wiki), specifically 
around the @sprite/gwt-image feature in CssResource, but also the other 
Java-specific pieces like @eval to get outside values into the css and @def 
to get inside values back out again. Can anyone comment on those aspects of 
how a GssResource could look?

On Tuesday, August 27, 2013 2:19:39 PM UTC-5, Julien Dramaix wrote:

 Thanks all,

 I will focus on Closure stylesheets integration and the introduction of a 
 new GssResource

 Julien


 On Tue, Aug 27, 2013 at 5:25 PM, Goktug Gokdogan 
 gok...@google.comjavascript:
  wrote:

 What we were planning was to add support for GSS, add the missing 
 features and then migrate existing users and deprecate the older 
 eventually. This would decrease the maintenance cost a lot in the long term.
 We really want to see GSS support for GWT in the long term. On top of 
 additional features, there are other benefits with moving to GSS; Google is 
 committed to maintain GSS and support it in the long term, we can get 
 direct support from the authors as they are close to us. One other major 
 advantage more specific to us is, we can reuse tons of already available 
 GSS resources. For that reason, we would love to see you moving in this 
 route and will definitely help you along the way, and also provide you 
 additional contact points from the team for support.



 On Tue, Aug 27, 2013 at 3:24 AM, Thomas Broyer 
 t.br...@gmail.comjavascript:
  wrote:



 On Tuesday, August 27, 2013 1:42:35 AM UTC+2, Colin Alworth wrote:

 I'd be interested in helping with either approach. The phloc-css 
 project looks interesting if we are only trying to add support for newer 
 CSS features, while integration with Closure Stylesheets seems geared more 
 toward extending the CssResource featureset. Much of the existing 
 functionality in GWT's CssResource is also in closure in some capacity, 
 though the implementation is likely different enough to cause interesting 
 issues. There are advantages to making it through those differences - 
 mixins for example.

 Another thought would be to implement both - expand CssResource to 
 support new properties with phloc-css, and create a new ResourcePrototype 
 (StylesheetResource perhaps?) with its own resource generator to put code 
 through closure's wringer.


 +1 to that (obviously, as I think that's what I was proposing) 

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

 For more options, visit https://groups.google.com/groups/opt_out.


  -- 
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 --- 
 You received this message because you are subscribed to a topic in the 
 Google Groups GWT Contributors group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/google-web-toolkit-contributors/e0qUfkqBSog/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to 
 google-web-toolkit-contributors+unsubscr...@googlegroups.comjavascript:
 .
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Making user.agent easier to extend to add new permutations

[Colin Alworth]

I've got to second Thomas on this point - adding a new user.agent is very
non-trivial at least without an overhaul of CssResource generation. In GXT
3 we took the route of providing our own PropertyProviderGenerator and
adding a few new user agents (ie7, ie10 for a start), but quickly found
that doing this broke internals of a variety of GWT widgets. The fallback
attribute let ie7 behave as ie6 (and ie10 as ie9) if a replace-with rule
set did not define specific behavior for it, but the CssResource generation
process creates types based on all properties available, not just the
properties that the CSS file was written to expect. This means that if you
have

@if user.agent ie6 ie8 {
  //...
}

then the enclosed content will only be in the _ie6 and _ie8 generated
classes, not _ie9 (good), _ie10 (good), or ie7 (bad). Without a fallback
mechanism that makes sense in CssResource, any existing GWT widget that
uses ClientBundle may be unusable in a project that builds its own user
agents.

This is the only case we ran into before we decided it wasn't worth it -
GXT 3 can and should run along side or in conjunction with standard GWT
widgets, so this was a deal-breaker right off the bat.


On Wed, Sep 11, 2013 at 4:40 AM, Thomas Broyer t.bro...@gmail.com wrote:


 On Wednesday, September 11, 2013 3:10:56 AM UTC+2, Goktug Gokdogan wrote:

 I recently noticed that developers are forking c.g.gwt.useragent in order
 to be able to add new browser permutations to existing ones. This is
 suboptimal and causes code duplication and possibly trying keep it in sync
 with the original during updates.
 The root cause of this is the determination of user.agent during runtime
 is statically defined in this package. I created a patch so that code
 snippets to extract user agent can be defined and injected from outside so
 that new permutations can be added externally without forking the original
 package.

 If you hit this issue before, please take a look at https://gwt-review.**
 googlesource.com/4500 https://gwt-review.googlesource.com/4500 and see
 if would make your life easier.


 Not opposed to it in principle, but adding a new user.agent is not an easy
 task, and more often than not people actually want to add a new property to
 be used in conjunction to user.agent in deferred-binding rules (e.g.
 https://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties#Example_2:_Avoiding_permutation_explosion);
 so I'm not sure this is the right move, as it makes it easier to do things
 the wrong way.

 As a side note, I think we should add a way to alias property values so
 we can progressively rename gecko1_8 to gecko and possibly safari to
 webkit [1] without breaking anyone. I think this can be faked today
 using fallback-value and excluding the fallback value from the possible
 values (i.e. extend-property name=user.agent value=gecko
 fallback-value=gecko1_8/set-property name=user.agent
 value=ie6,ie8,ie9,gecko,safari,opera/ notice the absence of gecko1_8
 here but thanks to the fallback-value, if-property-is name=user.agent
 value=gecko1_8/ should continue to work and match the gecko
 permutation) but we cannot set-property the user.agent property in GWT
 proper as it would break those who new values and expect the set of
 possible values to automatically grow with their new value.

 [1] Daniel thinks we should add a chromium permutation –he said blink,
 but I believe chromium would be a better name: it's not only about the
 rendering engine, but also the JS engine–, I know webkit can be used with
 other JS engines than JavaScriptCore but I'm unsure anyone would do it
 nowadays, and webkit probably still better matches reality than safari.

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




-- 
218.248.6165
niloc...@gmail.com

-- 
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] Possible firefox leak fix

[Colin Alworth]

 process? How far back in 
time do we rebuild and test?
 * How many auto-generated files (mostly .h from the idl, but also the 
.dll/.dylib/etc) do we commit when such a change is made?
 * Apparently plugins don't need to provide a disconnect() method, but if 
any do, are we *sure* they are actually being called as expected? Or is 
onUnload a long-lived typo?

Looking forward to discussing this here, in ##gwt on freenode, or on the 
call tomorrow,
Colin

-- 
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.
commit 6969765b5b60731f12ce529bbc6f730922b7e817
Author: Colin Alworth niloc...@gmail.com
Date:   Tue Sep 24 18:29:13 2013 -0500

Initial work on supporting a disconnect message from the browser to close off the connection to the code server

diff --git a/xpcom/ExternalWrapper.cpp b/xpcom/ExternalWrapper.cpp
index ab0423e..f4d61cb 100644
--- a/xpcom/ExternalWrapper.cpp
+++ b/xpcom/ExternalWrapper.cpp
@@ -399,6 +399,13 @@ NS_IMETHODIMP ExternalWrapper::Connect(const nsACString suppliedUrl,
   return NS_OK;
 }
 
+NS_IMETHODIMP ExternalWrapper::Disconnect() {
+  Debug::log(Debug::Info)  Disconnecting...  Debug::flush;
+  sessionHandler.get()-disconnect();
+  Debug::log(Debug::Info)  ...Disconnected  Debug::flush;
+  return NS_OK;
+}
+
 // nsISecurityCheckedComponent
 static char* cloneAllAccess() {
   static const char allAccess[] = allAccess;
@@ -422,7 +429,7 @@ NS_IMETHODIMP ExternalWrapper::CanCreateWrapper(const nsIID * iid,
 NS_IMETHODIMP ExternalWrapper::CanCallMethod(const nsIID * iid,
 const PRUnichar *methodName, char **_retval) {
   Debug::log(Debug::Spam)  ExternalWrapper::CanCallMethod  Debug::flush;
-  if (strEquals(methodName, connect) || strEquals(methodName, init)) {
+  if (strEquals(methodName, connect) || strEquals(methodName, init) || strEquals(methodName, disconnect)) {
 *_retval = cloneAllAccess();
   } else {
 *_retval = nullptr;
diff --git a/xpcom/IOOPHM.idl b/xpcom/IOOPHM.idl
index 1aeea54..14e4d6f 100644
--- a/xpcom/IOOPHM.idl
+++ b/xpcom/IOOPHM.idl
@@ -8,4 +8,5 @@ interface IOOPHM : nsISupports
   boolean init(in nsIDOMWindow window);
   boolean connect(in ACString url, in ACString sessionKey, in ACString addr,
   in ACString moduleName, in ACString hostedHtmlVersion);
+  void disconnect();
 };

Re: [gwt-contrib] Possible firefox leak fix

[Colin Alworth]

The patch I provided only tweaks the normal source, and leaves the 
generated sources and binaries alone - I think that is already what you are 
after. 

Note that this does *not* stop the leak by itself - we need to decide what 
to do about hosted.html/devmode.js. One (ugly) option is to try to have the 
ff plugin add an event handler to the window's close to call back to its 
own disconnect? I think there are other ways we could think about doing 
this as well, but changing hosted.html keeps it consistent across the board.

On Tuesday, September 24, 2013 6:50:07 PM UTC-5, Brian Slesinsky wrote:

 Hi,

 Wow, thanks for tracking this down! Could you send a patch that just 
 modifies the source (not worrying about the autogenerated files)? I will 
 rebuild them when I do the next release.

 Usually I just leave the existing dll's alone and move forward; it's not 
 worth fixing older plugins. However, I believe Firefox 24 will be an ESR 
 release so I think it's worth rebuilding that version.



 On Tue, Sep 24, 2013 at 4:31 PM, Colin Alworth nilo...@gmail.comjavascript:
  wrote:

 I spent a little time this weekend learning how to build firefox plugins, 
 and a little time spilled out into this week, but I think I'm at a point 
 where I can share what I've done, what I'm seeing, and start asking for 
 help to finalize this (if it is as meaningful as I hope it is).

 First, the issue itself: It looks like we're actually leaking on both 
 ends - that is, not just in the JVM, but in the browser itself. When Dev 
 Mode transfers control back to the browser itself, it runs 
 BrowserChannelServer.reactToMessages(). This listens at the open socket 
 between the browser's plugin and itself, and waits for the next byte to 
 float over the wire, meaning that the browser wants something. This waiting 
 specifically happens in Message.readMessageType, where we block on 
 stream.readByte(). Once a tab/window has been closed, the thread that is 
 actively watching that connection stays stuck in readByte(), waiting for 
 that next message to float over the wire.

 My first thought was why can't we just ask if that socket is closed? - 
 well, the socket *isn't* closed, which means that the browser is leaking 
 the socket itself, along with whatever supporting objects were set up to 
 manage that socket. Note that this suggests a workaround to the leak - quit 
 and relaunch firefox, and since the socket will be forcibly closed then, 
 readByte() will throw a EOF exception, and reactToMessages will trip off a 
 RemoteDeathError (not ideal, but at least it just logs it and moves on, 
 finishing the leak off).

 Next I dug into how to make the plugin actually disconnect when the page 
 was closed. I started this by finding exactly where the socket was opened 
 (common/HostChannel.{h|cpp}), then what creates HostChannel objects in the 
 firefox plugin. This turns out to be achieved in this line in 
 xpcom/ExternalWrapper.cpp (plus instructive comments):
   // TODO(jat): leaks HostChannel -- need to save it in a session object 
 and
   // return that so the host page can call a disconnect method on it at 
 unload
   // time or when it gets GC'd.
   HostChannel* channel = new HostChannel();

 Okay, so at the time it was written, it was known that this leaks the 
 channel. This is where I started losing confidence, as it doesnt look like 
 it could be this easy... The next block actually opens the connection, and 
 passes it off to a FFSessionHandler instance, which is stored away in a 
 field:
   Debug::log(Debug::Debugging)  Connecting...  Debug::flush;

   if (!channel-connectToHost(hostPart.c_str(),
   atoi(portPart.c_str( {
 *_retval = false;
 return NS_OK;
   }

   Debug::log(Debug::Debugging)  ...Connected  Debug::flush;
   sessionHandler.reset(new FFSessionHandler(channel/*, ctx*/));

 All this code is part of ExternalWrapper::Connect (note, defined twice 
 for varying ff versions), and since Connect is never invoked internally, it 
 was my assumption that I could build a ExternalWrapper::Disconnect that 
 simply unwound this channel:

 NS_IMETHODIMP ExternalWrapper::Disconnect() {
   Debug::log(Debug::Info)  Disconnecting...  Debug::flush;
   sessionHandler.get()-disconnect();
   Debug::log(Debug::Info)  ...Disconnected  Debug::flush;
   return NS_OK;
 }

 That, combined with two other changes seems to expose this new function 
 to be called from in the browser and actually triggers the QUIT case in 
 reactToMessages - First, declare this new method in IOOPHM.idl, and second 
 tweak ExternalWrapper's CanCallMethod check to allow invoking disconnect 
 from within the browser. Actually building with the attached patch then 
 modifies several other files (more on that later).

 Next, how to make disconnect() be invoked from within the browser - it is 
 already declared and invoked from within hosted.html and devmode.js, but it 
 seems to be in an invalid window callback:
   window.onUnload = function

Re: [gwt-contrib] Possible firefox leak fix

[Colin Alworth]

Done, change is at https://gwt-review.googlesource.com/4680.

Concern about breaking WindowImpl#initWindowCloseHandler was my guess as 
well - after connect() is called and the app starts up, the app has already 
wired up its own close handler, so it is too late when connect is 
successful to replace unload. 

Both the standard WindowImpl and the IE specific one replace onunload and 
call the old version, so provided those stay consistent with 
hosted.html/devmode.js, this approach should be okay...

I'd love to get any independent verification on this as even being a viable 
fix - I've only tried it in FF24/mac so far.

-Colin

On Tuesday, September 24, 2013 8:02:54 PM UTC-5, Brian Slesinsky wrote:

 +cromwellian since he did unload support.

 Oops, I see now that you attached it. Could you upload it to Gerrit?

 I looked pretty hard for a reason why it's window.onUnload and not 
 window.onload and I can't find any. It dates back to 2010 at least and was 
 copied from hosted.html, whether deliberately I don't know.

 One issue is that it's possible the app itself might want an onunload 
 handler. See 
 user/src/com/google/gwt/user/client/impl/WindowImpl.java line 32 where it 
 can install an onunload handler. It does preserve the old one but it still 
 seems kind of fragile to install one in the devmode.js. I wonder if there's 
 some way to detect the unload event in C++?

 - Brian



 On Tue, Sep 24, 2013 at 5:25 PM, Colin Alworth nilo...@gmail.comjavascript:
  wrote:

 The patch I provided only tweaks the normal source, and leaves the 
 generated sources and binaries alone - I think that is already what you are 
 after. 

 Note that this does *not* stop the leak by itself - we need to decide 
 what to do about hosted.html/devmode.js. One (ugly) option is to try to 
 have the ff plugin add an event handler to the window's close to call back 
 to its own disconnect? I think there are other ways we could think about 
 doing this as well, but changing hosted.html keeps it consistent across the 
 board.


 On Tuesday, September 24, 2013 6:50:07 PM UTC-5, Brian Slesinsky wrote:

 Hi,

 Wow, thanks for tracking this down! Could you send a patch that just 
 modifies the source (not worrying about the autogenerated files)? I will 
 rebuild them when I do the next release.

 Usually I just leave the existing dll's alone and move forward; it's not 
 worth fixing older plugins. However, I believe Firefox 24 will be an ESR 
 release so I think it's worth rebuilding that version.



 On Tue, Sep 24, 2013 at 4:31 PM, Colin Alworth nilo...@gmail.comwrote:

 I spent a little time this weekend learning how to build firefox 
 plugins, and a little time spilled out into this week, but I think I'm at 
 a 
 point where I can share what I've done, what I'm seeing, and start asking 
 for help to finalize this (if it is as meaningful as I hope it is).

 First, the issue itself: It looks like we're actually leaking on both 
 ends - that is, not just in the JVM, but in the browser itself. When Dev 
 Mode transfers control back to the browser itself, it runs 
 BrowserChannelServer.**reactToMessages(). This listens at the open 
 socket between the browser's plugin and itself, and waits for the next 
 byte 
 to float over the wire, meaning that the browser wants something. This 
 waiting specifically happens in Message.readMessageType, where we block on 
 stream.readByte(). Once a tab/window has been closed, the thread that is 
 actively watching that connection stays stuck in readByte(), waiting for 
 that next message to float over the wire.

 My first thought was why can't we just ask if that socket is closed? 
 - well, the socket *isn't* closed, which means that the browser is leaking 
 the socket itself, along with whatever supporting objects were set up to 
 manage that socket. Note that this suggests a workaround to the leak - 
 quit 
 and relaunch firefox, and since the socket will be forcibly closed then, 
 readByte() will throw a EOF exception, and reactToMessages will trip off a 
 RemoteDeathError (not ideal, but at least it just logs it and moves on, 
 finishing the leak off).

 Next I dug into how to make the plugin actually disconnect when the 
 page was closed. I started this by finding exactly where the socket was 
 opened (common/HostChannel.{h|cpp}), then what creates HostChannel objects 
 in the firefox plugin. This turns out to be achieved in this line in 
 xpcom/ExternalWrapper.cpp (plus instructive comments):
   // TODO(jat): leaks HostChannel -- need to save it in a session 
 object and
   // return that so the host page can call a disconnect method on it at 
 unload
   // time or when it gets GC'd.
   HostChannel* channel = new HostChannel();

 Okay, so at the time it was written, it was known that this leaks the 
 channel. This is where I started losing confidence, as it doesnt look like 
 it could be this easy... The next block actually opens the connection, and 
 passes it off to a FFSessionHandler

Re: [gwt-contrib] CSS3 support in CssResource: Closure Stylesheets?

[Colin Alworth]

Its never too late - I don't know how far Julien has gotten, but I've been 
distracted by other work, as well as trying to nail down conceptually where 
GSS meets ClientBundle.

For my part, SASS or LESS are a major step down from what we already have - 
the purpose of GWT in general is to let you write maintainable code that 
compiles to well-performing code, but not expose features that will perform 
badly (consider the lack of java.text, reflection support). The scoping 
feature that sass/less/compass has (allowing you to nest rules within other 
rules) makes for much longer selectors in the compiled out code, which 
equates pretty directly to worse performance (longer selectors take longer 
to find/track what they apply to). In contrast, Closure Stylesheets gives 
us the same sorts of variables, mixins, and @if syntax, but puts as much of 
this work on the compiler rather than adding more classes at runtime. It is 
a little more limited (and I'm not sure how we can even achieve things such 
as @def and @eval... which current CssResource has), but those limitations 
seem designed to provide better runtime performance.

On a different note, less/sass are implemented in Ruby, not Java, so either 
they must be made to work in JRuby or we'd need to require an existing Ruby 
installation.

OOCSS could be worth looking at - I don't know anything about it yet but 
would be interested in learning. At a glance, it *appears* to be more of a 
philosophy about writing html/css and a single set of starting structural 
css, rather than a more 'useful' css language - do I have it right?

Also, just as GssResource can be added as a new ResourcePrototype type, you 
could just as easily create a LessResource or OocssResource with its own 
generator to perform the required transformations.

I hang out in ##gwt on freenode, and would love to talk more about this 
whole task with anyone who is interested, otherwise i'd be open for a 
hangout to chat too.

On Wednesday, September 25, 2013 2:24:06 AM UTC-5, Samuel Schmid wrote:

 I'm a little bit late in this discoussion, i see there is a lot of work 
 already on going.
 But +1 for this.
 SASS or LESS would be a big plus.
 For me I think supporting OOCSS is more important than supporting CSS3 
 without workarounds.

 Thank you guys!
 Sam


 On Friday, December 16, 2011 11:51:43 PM UTC+1, Michael Vogt wrote:

 Hello.

  How could I refuse?  :) SGTM. We will of course, still have to
  maintain all of the GWT-isms. Actually, I've been wondering if we
  shoudn't just adopt LESS or SASS extensions too.
 
 Yes, please.


 Greetings,
 Michael



-- 
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] Build failures after deprecated tree/treeitem methods removed

[Colin Alworth]

It looks like a recent commit that removed some deprecated methods may not 
have gone far enough, as there is still code that makes use of those 
methods - the 
https://gwt.googlesource.com/gwt/+/f9630059081921b195ee4f7014e1a78c4b570f79 
commit dropped several methods from Tree and TreeItem, but the 'json' 
sample used those methods, so our nightly builds are seeing failures.

Source file that continues to use removed addItem methods:
https://gwt.googlesource.com/gwt/+/master/samples/json/src/com/google/gwt/sample/json/client/JSON.java

Build log errors:
compile:
[mkdir] Created dir: 
/Users/colin/Documents/idea/gwt/build/out/samples/JSON/war/WEB-INF/classes
[gwt.javac] Compiling 1 source file to 
/Users/colin/Documents/idea/gwt/build/out/samples/JSON/war/WEB-INF/classes
[gwt.javac] 
/Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:132:
 
error: no suitable method found for addItem(String)
[gwt.javac] TreeItem child = treeItem.addItem(getChildText([
[gwt.javac]  ^
[gwt.javac] method TreeItem.addItem(Widget) is not applicable
[gwt.javac]   (actual argument String cannot be converted to Widget by 
method invocation conversion)
[gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to IsTreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(TreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to TreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable
[gwt.javac]   (actual argument String cannot be converted to SafeHtml 
by method invocation conversion)
[gwt.javac] 
/Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:139:
 
error: no suitable method found for addItem(String)
[gwt.javac] TreeItem child = treeItem.addItem(getChildText(key));
[gwt.javac]  ^
[gwt.javac] method TreeItem.addItem(Widget) is not applicable
[gwt.javac]   (actual argument String cannot be converted to Widget by 
method invocation conversion)
[gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to IsTreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(TreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to TreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable
[gwt.javac]   (actual argument String cannot be converted to SafeHtml 
by method invocation conversion)
[gwt.javac] 
/Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:144:
 
error: no suitable method found for addItem(String)
[gwt.javac]   treeItem.addItem(jsonString.stringValue());
[gwt.javac]   ^
[gwt.javac] method TreeItem.addItem(Widget) is not applicable
[gwt.javac]   (actual argument String cannot be converted to Widget by 
method invocation conversion)
[gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to IsTreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(TreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to TreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable
[gwt.javac]   (actual argument String cannot be converted to SafeHtml 
by method invocation conversion)
[gwt.javac] 
/Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:147:
 
error: no suitable method found for addItem(String)
[gwt.javac]   treeItem.addItem(getChildText(jsonValue.toString()));
[gwt.javac]   ^
[gwt.javac] method TreeItem.addItem(Widget) is not applicable
[gwt.javac]   (actual argument String cannot be converted to Widget by 
method invocation conversion)
[gwt.javac] method TreeItem.addItem(IsTreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to IsTreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(TreeItem) is not applicable
[gwt.javac]   (actual argument String cannot be converted to TreeItem 
by method invocation conversion)
[gwt.javac] method TreeItem.addItem(SafeHtml) is not applicable
[gwt.javac]   (actual argument String cannot be converted to SafeHtml 
by method invocation conversion)
[gwt.javac] 
/Users/colin/Documents/idea/gwt/samples/json/src/com/google/gwt/sample/json/client/JSON.java:154:
 
error: no suitable method found for addItem(String)
[gwt.javac] TreeItem treeItem = jsonTree.addItem(errorType);
[gwt.javac] ^
[gwt.javac] method 

[gwt-contrib] gwtproject.org javadoc missing files

[Colin Alworth]

According to the the gwt-site git repo (at 
https://gwt.googlesource.com/gwt-site/+/master/src/main/site/javadoc/latest), 
the package-list file is present, but it can't be downloaded from 
http://www.gwtproject.org/javadoc/latest/package-list. It *is* still 
available from 
http://google-web-toolkit.googlecode.com/svn/javadoc/latest/package-list.

This file is useful for projects that are building javadoc that should link 
up to GWT itself - without it, the javadoc tool apparently doesn't link to 
referenced classes in GWT.

I'm not seeing anything useful in terms of a web.xml file or a 
servlet/filter/htaccess that can be customized to correct for this in the 
git repo, so I'm assuming that this is a server configuration change that 
needs to be made. Can someone confirm that, or point me in the right 
direction for a change I can make as a contributor?

Thanks,
Colin

-- 
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] Non-client apis and breaking changes

[Colin Alworth]

Just wandered by https://gwt-review.googlesource.com/#/c/1040/ and noticed 
that with this change, any downstream generator/linker using the static 
helper methods in Name will no longer build across 2.5.1 to 2.6.0. With the 
other discussions going on about JRE and browser support, perhaps we could 
discuss something policy-like around 'internal' code like this? 

If the policy that internal public methods are not actually for public 
consumption, or subject to breakage across minor releases, we should note 
that somewhere to keep people away. My inclination is that we want to 
encourage downstream code to use utility methods like this rather than 
copying them into their own projects.

And again on the side of discouraging use of code like this, how far and 
wide can public code be expected to be 'usable by downstream'? The 
com.google.gwt.editor.rebind.model.ModelUtils class is very handy for 
getting specifics about generic types, but from its package it is clearly 
part of editor so could change with modifications to that framework, 
whereas Name and StringKey seem to be in the relatively 'safe' package of 
com.google.gwt.dev.util with other benign classes like Util.

Thoughts?

-- 
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: Bad news for GWT DevMode!

[Colin Alworth]

I end up debugging IE in dev mode on a regular basis as well, though in a
VM, through to my host OS's Eclipse or IntelliJ debugger. It is
significantly slower than running the IDE and browser on the same OS, but
it does let you set up your env once and debug multiple OSes whenever you
like.




On Mon, Oct 21, 2013 at 8:56 AM, Thomas Broyer t.bro...@gmail.com wrote:

 I don't think any committer to the GWT project uses Windows (other than
 for testing, using VMs then), so it'd be either Firefox or Chrome (no other
 choice on Linux; and on OSX, Safari is no longer supported started with
 5.1, and I don't think anyone uses OmniWeb or similar).
 Both work well.

 To answer the question about a “preferred browser”, I've been told that,
 on Windows, IE works best (is the fastest); that was a while back though,
 so things might have changed.


 On Monday, October 21, 2013 3:21:49 PM UTC+2, Ivan Dimitrijevic wrote:

 IMO Firefox

 On Friday, October 18, 2013 11:47:13 PM UTC+2, Alex Raugust wrote:

 Just curious, is there a preferred browser for Classic DevMode?

 What do the cool kids use? :)

 On Tuesday, September 24, 2013 4:05:59 AM UTC-7, Thomas Broyer wrote:

 Just saw this passing on Twitter: http://blog.chromium.**
 org/2013/09/saying-goodbye-to-**our-old-friend-npapi.htmlhttp://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html
 This is really bad for DevMode in Chrome (maybe also in Firefox, which
 was already a nightmare). Means we really need to improve SuperDevMode, or
 find a non-NPAPI way to plug into the browser.

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




-- 
218.248.6165
niloc...@gmail.com

-- 
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: Reminder: GWT 2.6 feature complete is Nov 4

[Colin Alworth]

Patrick, looking at these, only two appear to have code reviews, and both 
are in the pre-git system. Gerrit, the current system, needs a CLA before 
it allows changes, to make sure that there are no copyright/licensing 
issues with contributions, and makes history/change management a little 
easier. Can you migrate those to Gerrit so they can be reviewed and merged? 
Link back to the original so any discussion there can be read and taken 
into account by future reviewers.

On Friday, October 18, 2013 7:18:40 AM UTC-5, Patrick Tucker wrote:

 I really would like to see some of these make the cut.  Most of the which 
 are trivial fixes, some have patches proposed.
  
 title set on parent TreeItem appears also on its children

 http://code.google.com/p/google-web-toolkit/issues/detail?id=1393

 HeaderPanel setHeaderWidget is broken

 http://code.google.com/p/google-web-toolkit/issues/detail?id=7037

 BorderStyle enum is missing values

 http://code.google.com/p/google-web-toolkit/issues/detail?id=8071

 Inconsistent TextArea border-top style

 http://code.google.com/p/google-web-toolkit/issues/detail?id=8176

 Vertical MenuBar popup is always left aligned even if there is not enough 
 right-space to do so.

 http://code.google.com/p/google-web-toolkit/issues/detail?id=3888

 Add max-height and max-width support to Style

 http://code.google.com/p/google-web-toolkit/issues/detail?id=7905

  
  
 I don't necessarily care about this one but it is just a documentation 
 fix...
  
 Documentation for TabBar doesn't list gwt-TabBarItem-disabled

 *http://code.google.com/p/google-web-toolkit/issues/detail?id=4050*http://code.google.com/p/google-web-toolkit/issues/detail?id=4050

  
  
  
  
  

 On Thursday, October 17, 2013 1:22:56 PM UTC-4, Matthew Dempsky wrote:

 Hi all,

 Just writing to remind everyone that the GWT 2.6 feature complete 
 deadline is November 4th.  On that day I'll fork the GWT 2.6 release 
 branch, and I'll only approve patches for release critical bug fixes.

 The GWT 2.6 Release 
 Planhttps://docs.google.com/a/gwtproject.org/document/d/1ZdMwcTjc4rkWg6nntCY1BDB1xI2PHPwaCnTYw-9uAKE/edit#
  contains 
 the handful of outstanding issues that I know we still want to get in for 
 2.6, and I'll be following up with people to try to make sure they're 
 merged in time.  If there are other features you think should be included 
 but aren't listed, please speak up now so I can add them and track their 
 progress.

 Thanks



-- 
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: Where is gwt-customchecks.jar?

[Colin Alworth]

Tentative patch up at https://gwt-review.googlesource.com/5063 - can 
someone sanity check it for me? It looks like step 4 (now step 3) should 
have previously been pointing to step 3 (now step 2), so is now more 
correct.

On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote:

 Thanks Thomas. I think it should be removed from eclipse/README.txt. 

 - Andrés Testi

 El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió:


 On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote:

 Where is the gwt-customchecks.jar file referred in eclipse/README.txt? 
 Is it no longer required to configure codecheck?
 Thanks in advance.


 It's gone, and no longer required.
 See https://gwt-review.googlesource.com/1051



-- 
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: Where is gwt-customchecks.jar?

[Colin Alworth]

If only *all* of my changes were that easy to make...

On Tuesday, October 22, 2013 8:15:12 AM UTC-5, Andrés Testi wrote:

 Thanks Colin! I'm glad to see the power of the community in action :-)

 - Andrés Testi

 El lunes, 21 de octubre de 2013 19:59:53 UTC-3, Colin Alworth escribió:

 Tentative patch up at https://gwt-review.googlesource.com/5063 - can 
 someone sanity check it for me? It looks like step 4 (now step 3) should 
 have previously been pointing to step 3 (now step 2), so is now more 
 correct.

 On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote:

 Thanks Thomas. I think it should be removed from eclipse/README.txt. 

 - Andrés Testi

 El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió:


 On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote:

 Where is the gwt-customchecks.jar file referred in eclipse/README.txt? 
 Is it no longer required to configure codecheck?
 Thanks in advance.


 It's gone, and no longer required.
 See https://gwt-review.googlesource.com/1051



-- 
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: Bad news for GWT DevMode!

[Colin Alworth]

Amazingly, it still works great in the IE11 preview too! Only gotcha is 
that the missing plugin page thinks you are running firefox, so you need to 
manually grab the right copy of the IE plugin.

On Tuesday, October 22, 2013 12:58:57 PM UTC-5, Brian Slesinsky wrote:

 I expect that by next summer devmode will *only* work in IE and perhaps an 
 older version of Firefox. Oddly enough, the IE plugin has apparently worked 
 for years with no complaints. (But the issue is that nobody currently on 
 the team has ever built it.)

 - Brian

 On Mon, Oct 21, 2013 at 6:56 AM, Thomas Broyer t.br...@gmail.comjavascript:
  wrote:

 I don't think any committer to the GWT project uses Windows (other than 
 for testing, using VMs then), so it'd be either Firefox or Chrome (no other 
 choice on Linux; and on OSX, Safari is no longer supported started with 
 5.1, and I don't think anyone uses OmniWeb or similar).
 Both work well.

 To answer the question about a “preferred browser”, I've been told that, 
 on Windows, IE works best (is the fastest); that was a while back though, 
 so things might have changed.


 On Monday, October 21, 2013 3:21:49 PM UTC+2, Ivan Dimitrijevic wrote:

 IMO Firefox

 On Friday, October 18, 2013 11:47:13 PM UTC+2, Alex Raugust wrote:

 Just curious, is there a preferred browser for Classic DevMode?

 What do the cool kids use? :)

 On Tuesday, September 24, 2013 4:05:59 AM UTC-7, Thomas Broyer wrote:

 Just saw this passing on Twitter: http://blog.chromium.**
 org/2013/09/saying-goodbye-to-**our-old-friend-npapi.htmlhttp://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html
 This is really bad for DevMode in Chrome (maybe also in Firefox, which 
 was already a nightmare). Means we really need to improve SuperDevMode, 
 or 
 find a non-NPAPI way to plug into the browser.

  -- 
 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.comjavascript:
 .
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Publish nighly snapshots of GWT builds to Maven

[Colin Alworth]

I've just put up a patch that seems to resolve a current issue in deploying 
snapshots to a maven repository: https://gwt-review.googlesource.com/5192

The basis of the problem requiring this patch is that maven (at least maven 
3, possibly not maven 2) expects unique snapshots, and that each call to 
deploy:deploy-file or sign:sign-and-deploy uploads its artifact as a 
standalone object - when we call deploy three times (jar, sources, 
javadoc), the last one in is treated as the 'newest'. This doesn't happen 
for releases, as there can only be one release, while there can be several 
snapshots for a version.

As noted, this patch does not resolve the issue locally - its my 
understanding that install:install-file would need to be used to make this 
work our locally, or else I'm just doing it wrong. The issue appears to be 
related to metadata not being updated correctly, but I didn't debug too 
extensively. I think that we can safely ignore local snapshots for the time 
being anyway - first, they didn't work before this patch, and second a user 
can either build from a snapshot server or can assign a non-snapshot 
version when installing locally and run it multiple times (pushing a 
non-snapshot version to a remote server would result in clients caching 
that result and not downloading it again).

I'd appreciate any testing of this so that we can see about starting to put 
out snapshot builds on sonatype going forward.

On Sunday, September 22, 2013 8:53:16 AM UTC-5, Thomas Broyer wrote:

 It should be relatively easy with the existing shell scripts; the major 
 pain point would be securing the credentials. I think Sonatype can do app 
 passwords.
 I can have a look at the scripts if needs be, as I think they've only been 
 tested for local deployment or staging, and only for releases (not 
 snapshots)

-- 
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: Building Elemental fails

[Colin Alworth]

I can't reproduce this, we're also running ant clean elemental dist on our 
teamcity build. We're also running ubuntu 12, python 2.7.3. Last confirmed 
building as of 0d6a865556ca56840114e8397a1f2be522e83361 (current HEAD).

On Monday, October 28, 2013 5:43:04 AM UTC-5, Jens wrote:

 I just tried to add Elemental to our GWT trunk builds and thus changed 
 ant clean dist to ant clean elemental dist and now always getting the 
 following build error:


 generate:
  [exec] Traceback (most recent call last):
  [exec]   File idl/scripts/elemental_fremontcutbuilder.py, line 217, 
 in module
  [exec] sys.exit(main())
  [exec]   File idl/scripts/elemental_fremontcutbuilder.py, line 214, 
 in main
  [exec] return build_database(idl_files, database_dir)
  [exec]   File idl/scripts/elemental_fremontcutbuilder.py, line 139, 
 in build_database
  [exec] builder.import_idl_file(file_name, webkit_options)
  [exec]   File 
 /var/lib/jenkins/jobs/GWT/workspace/elemental/idl/scripts/databasebuilder.py,
  
 line 472, in import_idl_file
  [exec] idl_file = self._load_idl_file(file_path, import_options)
  [exec]   File 
 /var/lib/jenkins/jobs/GWT/workspace/elemental/idl/scripts/databasebuilder.py,
  
 line 86, in _load_idl_file
  [exec] raise RuntimeError('Failed to load file %s: %s' % 
 (file_name, e))
  [exec] RuntimeError: Failed to load file 
 idl/scripts/../third_party/WebCore/css/WebKitCSSRegionRule.idl: At line 1 
 offset 0: Expected module or interface or exception but  found: 
  [exec] Traceback (most recent call last):
  [exec]   File idl/scripts/elementaldomgenerator.py, line 164, in 
 module
  [exec] sys.exit(main())
  [exec]   File idl/scripts/elementaldomgenerator.py, line 155, in 
 main
  [exec] database_dir, use_database_cache)
  [exec]   File idl/scripts/elementaldomgenerator.py, line 120, in 
 GenerateDOM
  [exec] systems = systems)
  [exec]   File 
 /var/lib/jenkins/jobs/GWT/workspace/elemental/idl/scripts/elementalgenerator.py,
  
 line 279, in Generate
  [exec] 
 self.PopulateMixinBase(self._database.GetInterface('ElementalMixinBase'), 
 mixins)
  [exec]   File 
 /var/lib/jenkins/jobs/GWT/workspace/elemental/idl/scripts/database.py, 
 line 188, in GetInterface
  [exec] raise RuntimeError('Interface %s is not loaded' % 
 interface_name)
  [exec] RuntimeError: Interface ElementalMixinBase is not loaded


 The build is executed by Jenkins on Ubuntu 12.04 with Python 2.7.3. I 
 tried the same on Mac OS (without Jenkins) and everything works as 
 expected. I have also created MD5 sums of WebKitCSSRegionRule.idl on 
 Ubuntu and Mac OS and both MD5 sums are the same.

 Does anyone have an idea what can cause the above error?


 -- J.


-- 
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: Building Elemental fails

[Colin Alworth]

Good thought, I tried that too to confirm that teamcity wasn't setting 
anything funny. Still passed, not sure what is up.
Other details that may or may not help:

$ java -version
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10)
Java HotSpot(TM) Server VM (build 20.10-b01, mixed mode)

$ ant -version
Apache Ant(TM) version 1.8.2 compiled on December 3 2011

$ uname -a
Linux ubuntu 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 12:29:27 UTC 2013 
x86_64 x86_64 x86_64 GNU/Linux

$ python --version
Python 2.7.3



On Monday, October 28, 2013 11:37:40 AM UTC-5, Jens wrote:

 Thx for checking it, Colin. 

 Pretty strange that it doesn't work. The error also happens if I just 
 execute ant on console directly on the server.

 -- J.


-- 
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: Reminder: Branching GWT 2.6 later today

[Colin Alworth]

It looks like while I can get maven from the command line to get along with 
that repo, IntelliJ isn't having it - it is getting confused by the fact 
that the latest gwt-user snapshot 2.6.0-20131105.081128-3 only has a 
sources jar and a pom, no actual jar with compiled code in it. The -1 jar 
is only the compiled code, the -2 is only javadoc, and the -3 is, as 
mentioned, sources.

The maven/push-gwt.sh patch I put up should resolve this - for now this 
setup is good for maven builds, but not for IDEs that expect to have 
sources and javadocs available in the 'same' snapshot.

On Tuesday, November 5, 2013 2:18:30 AM UTC-6, Matthew Dempsky wrote:

 In the mean time though, I think I successfully pushed 2.6.0-SNAPSHOT to 
 https://oss.sonatype.org/content/repositories/google-snapshots/.


 On Tue, Nov 5, 2013 at 12:04 AM, Matthew Dempsky 
 mdem...@google.comjavascript:
  wrote:

 As promised, I created the release/2.6 branch for tracking development 
 towards 2.6.  At this point, development can continue on master towards the 
 next release.  If you think a change should be made for 2.6, please propose 
 it against master, and then notify me to cherry pick it onto release/2.6.

 Setting up the 2.6 release branch took longer than expected due to some 
 last minute changes and technical issues.  I plan to finish preparing the 
 2.6rc1 snapshot tomorrow morning, and push them out.  I'll send an 
 announcement when that's ready.  Thanks for your patience and sorry for the 
 slight delay.


 On Mon, Nov 4, 2013 at 1:58 PM, Matthew Dempsky 
 mdem...@google.comjavascript:
  wrote:

 As a reminder, I'm going to create the GWT 2.6 branch later today and 
 prepare a 2.6rc1 snapshot.  There's still some time to propose and submit 
 patches, but it's down to hours remaining now.  Don't fret if you miss the 
 deadline: there will be more releases in the future!
  




-- 
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: Reminder: Branching GWT 2.6 later today

[Colin Alworth]

Just moved to eclipse to verify a possible issue with the snapshot (nope,
bug was in my code), and eclipse seems to do okay with finding each
artifact in its own snapshot.

Can you ping the list when you push a new set of snapshots?

-Colin
On Nov 5, 2013 7:55 PM, Matthew Dempsky mdemp...@google.com wrote:

 Thanks for testing, Colin!  I'll try another push tonight using your
 scripts.


 On Tue, Nov 5, 2013 at 5:14 PM, Colin Alworth niloc...@gmail.com wrote:

 It looks like while I can get maven from the command line to get along
 with that repo, IntelliJ isn't having it - it is getting confused by the
 fact that the latest gwt-user snapshot 2.6.0-20131105.081128-3 only has a
 sources jar and a pom, no actual jar with compiled code in it. The -1 jar
 is only the compiled code, the -2 is only javadoc, and the -3 is, as
 mentioned, sources.

 The maven/push-gwt.sh patch I put up should resolve this - for now this
 setup is good for maven builds, but not for IDEs that expect to have
 sources and javadocs available in the 'same' snapshot.


 On Tuesday, November 5, 2013 2:18:30 AM UTC-6, Matthew Dempsky wrote:

 In the mean time though, I think I successfully pushed 2.6.0-SNAPSHOT to
 https://oss.sonatype.org/content/repositories/google-snapshots/.


 On Tue, Nov 5, 2013 at 12:04 AM, Matthew Dempsky mdem...@google.comwrote:

 As promised, I created the release/2.6 branch for tracking
 development towards 2.6.  At this point, development can continue on master
 towards the next release.  If you think a change should be made for 2.6,
 please propose it against master, and then notify me to cherry pick it onto
 release/2.6.

 Setting up the 2.6 release branch took longer than expected due to some
 last minute changes and technical issues.  I plan to finish preparing the
 2.6rc1 snapshot tomorrow morning, and push them out.  I'll send an
 announcement when that's ready.  Thanks for your patience and sorry for the
 slight delay.


 On Mon, Nov 4, 2013 at 1:58 PM, Matthew Dempsky mdem...@google.comwrote:

 As a reminder, I'm going to create the GWT 2.6 branch later today and
 prepare a 2.6rc1 snapshot.  There's still some time to propose and submit
 patches, but it's down to hours remaining now.  Don't fret if you miss the
 deadline: there will be more releases in the future!



  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Reminder: Branching GWT 2.6 later today

[Colin Alworth]

:2.6.0-SNAPSHOT/maven-metadata.xml from/to sonatype (
 https://oss.sonatype.org/service/local/staging/deploy/maven2/): Failed
 to transfer file:
 https://oss.sonatype.org/service/local/staging/deploy/maven2//com/google/gwt/gwt-dev/2.6.0-SNAPSHOT/maven-metadata.xml.
 Return code is: 400
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 2.126s
 [INFO] Finished at: Wed Nov 06 15:47:54 PST 2013
 [INFO] Final Memory: 8M/112M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file (default-cli)
 on project standalone-pom: Failed to retrieve remote metadata
 com.google.gwt:gwt-dev:2.6.0-SNAPSHOT/maven-metadata.xml: Could not
 transfer metadata com.google.gwt:gwt-dev:2.6.0-SNAPSHOT/maven-metadata.xml
 from/to sonatype (
 https://oss.sonatype.org/service/local/staging/deploy/maven2/): Failed
 to transfer file:
 https://oss.sonatype.org/service/local/staging/deploy/maven2//com/google/gwt/gwt-dev/2.6.0-SNAPSHOT/maven-metadata.xml.
 Return code is: 400 - [Help 1]
 [ERROR]
 [ERROR] To see the full stack trace of the errors, re-run Maven with the
 -e switch.
 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
 [ERROR]
 [ERROR] For more information about the errors and possible solutions,
 please read the following articles:
 [ERROR] [Help 1]
 http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
 Error while deploying, ignore errors? (y/N):

 I'm going to root cause what's going on, but maybe you have an idea
 what's going on?


 On Wed, Nov 6, 2013 at 1:49 PM, Colin Alworth niloc...@gmail.comwrote:

 Just moved to eclipse to verify a possible issue with the snapshot
 (nope, bug was in my code), and eclipse seems to do okay with finding each
 artifact in its own snapshot.

 Can you ping the list when you push a new set of snapshots?

 -Colin
 On Nov 5, 2013 7:55 PM, Matthew Dempsky mdemp...@google.com wrote:

 Thanks for testing, Colin!  I'll try another push tonight using your
 scripts.


 On Tue, Nov 5, 2013 at 5:14 PM, Colin Alworth niloc...@gmail.comwrote:

 It looks like while I can get maven from the command line to get
 along with that repo, IntelliJ isn't having it - it is getting confused 
 by
 the fact that the latest gwt-user snapshot 2.6.0-20131105.081128-3 only 
 has
 a sources jar and a pom, no actual jar with compiled code in it. The -1 
 jar
 is only the compiled code, the -2 is only javadoc, and the -3 is, as
 mentioned, sources.

 The maven/push-gwt.sh patch I put up should resolve this - for now
 this setup is good for maven builds, but not for IDEs that expect to have
 sources and javadocs available in the 'same' snapshot.


 On Tuesday, November 5, 2013 2:18:30 AM UTC-6, Matthew Dempsky wrote:

 In the mean time though, I think I successfully pushed
 2.6.0-SNAPSHOT to https://oss.sonatype.org/
 content/repositories/google-snapshots/.


 On Tue, Nov 5, 2013 at 12:04 AM, Matthew Dempsky mdem...@google.com
  wrote:

 As promised, I created the release/2.6 branch for tracking
 development towards 2.6.  At this point, development can continue on 
 master
 towards the next release.  If you think a change should be made for 
 2.6,
 please propose it against master, and then notify me to cherry pick it 
 onto
 release/2.6.

 Setting up the 2.6 release branch took longer than expected due to
 some last minute changes and technical issues.  I plan to finish 
 preparing
 the 2.6rc1 snapshot tomorrow morning, and push them out.  I'll send an
 announcement when that's ready.  Thanks for your patience and sorry 
 for the
 slight delay.


 On Mon, Nov 4, 2013 at 1:58 PM, Matthew Dempsky mdem...@google.com
  wrote:

 As a reminder, I'm going to create the GWT 2.6 branch later today
 and prepare a 2.6rc1 snapshot.  There's still some time to propose and
 submit patches, but it's down to hours remaining now.  Don't fret if 
 you
 miss the deadline: there will be more releases in the future!



  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google
 Groups GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it,
 send an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google
 Groups GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

  --
 http://groups.google.com/group/Google-Web-Toolkit

Re: [gwt-contrib] Re: Reminder: Branching GWT 2.6 later today

[Colin Alworth]

Can you clarify about 2.6.0-rc1? Are we pushing the current build as
2.6.0-rc1 to maven central? I don't yet see 2.6.0-rc1 in central, nor in
the google-snapshots.

A key detail about maven is that once a release is pushed with a particular
version, it can't be unpushed, released is released. Snapshots are the
other way around, you are allowed to update snapshots, as well as remove
stale ones.

On the plus side, the -SNAPSHOT build looks to be working great from my
testing.


On Wed, Nov 6, 2013 at 7:07 PM, Matthew Dempsky mdemp...@google.com wrote:

 On Wed, Nov 6, 2013 at 4:54 PM, Colin Alworth niloc...@gmail.com wrote:

 My vote is 2.6.0-SNAPSHOT and 2.6.0-rc1, in case we need a bug fix
 release... Being consistent with snapshot versions lets maven users update
 to the new nightly without any config file changes.

 SGTM; rebuilt as 2.6.0-rc1 and pushed to google-snapshots as
 2.6.0-SNAPSHOT.

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




-- 
218.248.6165
niloc...@gmail.com

-- 
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: Reminder: Branching GWT 2.6 later today

[Colin Alworth]

Email is almost fast enough to avoid this confusion - disregard my
questions, looks like I've already got my answer!


On Wed, Nov 6, 2013 at 11:02 PM, Matthew Dempsky mdemp...@google.comwrote:

 gwt-2.6.0-rc1.zip download:
 https://code.google.com/p/google-web-toolkit/downloads/detail?name=gwt-2.6.0-rc1.zip

 (Next up the Maven 2.6.0-rc1 artifacts.)


 On Wed, Nov 6, 2013 at 5:07 PM, Matthew Dempsky mdemp...@google.comwrote:

 On Wed, Nov 6, 2013 at 4:54 PM, Colin Alworth niloc...@gmail.com wrote:

 My vote is 2.6.0-SNAPSHOT and 2.6.0-rc1, in case we need a bug fix
 release... Being consistent with snapshot versions lets maven users update
 to the new nightly without any config file changes.

 SGTM; rebuilt as 2.6.0-rc1 and pushed to google-snapshots as
 2.6.0-SNAPSHOT.


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




-- 
218.248.6165
niloc...@gmail.com

-- 
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 2.6 and Java 6

[Colin Alworth]

I'm not yet convinced that this isn't either a) a workspace issue or b) a 
decision the community reached and I missed, but I figured I should stick 
it out there and see if someone can correct me.

I've just brought our project up to date with GWT 2.6.0-rc1 from maven, and 
I can verify that the class files have magic number 50.0 set on them, 
indicating Java 6. I can compile the project with a Java 6 jdk, and gwtc 
behaves as expected, but I can't run dev mode. The error I get usually goes 
a little like this:

ERROR: Unable to initialize static dispatcher
java.lang.UnsupportedClassVersionError: 
com/google/gwt/core/client/JavaScriptObject$ : Unsupported major.minor 
version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.lang.ClassLoader.defineClass(ClassLoader.java:471)
at 
com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121)
at 
com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:249)
at com.google.gwt.dev.shell.JsValueGlue.set(JsValueGlue.java:220)

The magic number 51.0 indicates Java7 - how is it that while I'm running 
Java 6, I am generating Java 7-only classes?

My working theory is that since we moved some internals to be Java 7 
capable (somewhere around https://gwt.googlesource.com/gwt/+/e4f6142 or a 
related commit), it was set as the default. My question: do we intend to 
require Java 7 for dev mode (and therefore also GWTTestCase run in dev 
mode), but allow Java 6 for essentially everything else?

-- 
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 2.6 and Java 6

[Colin Alworth]

Thanks Roberto, I'll give that a shot. I normally work with Java 7, but we 
want our code to work with anyone who chooses to use Java 6 as well - and I 
surmised that GWT had the same goal.

Would it make sense to consider a warning indicating that the flag is 
needed with Java 6, or auto-detecting that Java 6 is running so a 
JavaScriptObject$ compiled for 7 can't possibly work?

On Friday, November 8, 2013 6:01:40 PM UTC-6, Roberto Lublinerman wrote:

 You should be able to invoke devmode with -sourceLevel 6.

 Roberto Lublinerman | Software Engineer | rlu...@google.com javascript:
  | 408-500-9148


 On Fri, Nov 8, 2013 at 3:31 PM, Colin Alworth nilo...@gmail.comjavascript:
  wrote:

 I'm not yet convinced that this isn't either a) a workspace issue or b) a 
 decision the community reached and I missed, but I figured I should stick 
 it out there and see if someone can correct me.

 I've just brought our project up to date with GWT 2.6.0-rc1 from maven, 
 and I can verify that the class files have magic number 50.0 set on them, 
 indicating Java 6. I can compile the project with a Java 6 jdk, and gwtc 
 behaves as expected, but I can't run dev mode. The error I get usually goes 
 a little like this:

 ERROR: Unable to initialize static dispatcher
 java.lang.UnsupportedClassVersionError: 
 com/google/gwt/core/client/JavaScriptObject$ : Unsupported major.minor 
 version 51.0
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:471)
 at 
 com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121)
 at 
 com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:249)
 at com.google.gwt.dev.shell.JsValueGlue.set(JsValueGlue.java:220)

 The magic number 51.0 indicates Java7 - how is it that while I'm running 
 Java 6, I am generating Java 7-only classes?

 My working theory is that since we moved some internals to be Java 7 
 capable (somewhere around https://gwt.googlesource.com/gwt/+/e4f6142 or 
 a related commit), it was set as the default. My question: do we intend to 
 require Java 7 for dev mode (and therefore also GWTTestCase run in dev 
 mode), but allow Java 6 for essentially everything else?
  
 -- 
 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.comjavascript:
 .
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] GWT 2.6 and Java 6

[Colin Alworth]

Thanks for the clarification, I'll take a quick stab to see if I can make
that change on my own.
On Nov 9, 2013 5:40 PM, Roberto Lublinerman rlu...@google.com wrote:

 You are right, there should be an extra option -sourceLevel auto and that
 should be the default for devmode.

 On Nov 8, 2013, at 17:47, Colin Alworth niloc...@gmail.com wrote:

 Thanks Roberto, I'll give that a shot. I normally work with Java 7, but we
 want our code to work with anyone who chooses to use Java 6 as well - and I
 surmised that GWT had the same goal.

 Would it make sense to consider a warning indicating that the flag is
 needed with Java 6, or auto-detecting that Java 6 is running so a
 JavaScriptObject$ compiled for 7 can't possibly work?

 On Friday, November 8, 2013 6:01:40 PM UTC-6, Roberto Lublinerman wrote:

 You should be able to invoke devmode with -sourceLevel 6.

 Roberto Lublinerman | Software Engineer | rlu...@google.com |
 408-500-9148


 On Fri, Nov 8, 2013 at 3:31 PM, Colin Alworth nilo...@gmail.com wrote:

 I'm not yet convinced that this isn't either a) a workspace issue or b)
 a decision the community reached and I missed, but I figured I should stick
 it out there and see if someone can correct me.

 I've just brought our project up to date with GWT 2.6.0-rc1 from maven,
 and I can verify that the class files have magic number 50.0 set on them,
 indicating Java 6. I can compile the project with a Java 6 jdk, and gwtc
 behaves as expected, but I can't run dev mode. The error I get usually goes
 a little like this:

 ERROR: Unable to initialize static dispatcher
 java.lang.UnsupportedClassVersionError:
 com/google/gwt/core/client/JavaScriptObject$ : Unsupported major.minor
 version 51.0
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:471)
 at
 com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121)
 at
 com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:249)
 at com.google.gwt.dev.shell.JsValueGlue.set(JsValueGlue.java:220)

 The magic number 51.0 indicates Java7 - how is it that while I'm running
 Java 6, I am generating Java 7-only classes?

 My working theory is that since we moved some internals to be Java 7
 capable (somewhere around https://gwt.googlesource.com/gwt/+/e4f6142 or
 a related commit), it was set as the default. My question: do we intend to
 require Java 7 for dev mode (and therefore also GWTTestCase run in dev
 mode), but allow Java 6 for essentially everything else?

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google
 Groups GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
 .
 For more options, visit https://groups.google.com/groups/opt_out.


  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


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

[Colin Alworth]

There is a workaround - I'm on my phone now, but I posted it in the bug
report. Essentially you can tell the plugin to not worry about invalid
SDKs, and either mark then as merely errors, or just ignore it entirely.
With that set, we've noticed no other I'll effects so far.
On Nov 17, 2013 12:29 AM, gslender gslen...@gmail.com wrote:

 I assume there is no workaround whilst we are waiting for GPE to be
 updated for 2.6 ??

 G

 On Wednesday, 30 October 2013 20:22:33 UTC+10, Jens wrote:

 We are start using GWT trunk builds for development but Eclipse / GPE
 always says GWT SDK ... on the projects build path is not valid (Version
 is not supported, must be 2.0.0 or later) if we add a trunk build to the
 list of GWT SDKs in Eclipse. In the list of GWT SDKs the version column is
 empty so it seems like Eclipse does not recognize any version. This happens
 for a typically GWT SDK 0.0.0 build and it also happens if I set the
 env.GWT_VERSION property to anything above 2.0.0.

 Is there anything I forgot to configure prior calling the ant script to
 make Eclipse happy?


 -- J.



  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Officially deprecating Opera permutation

[Colin Alworth]

Just to confirm, the plan is to set this in master as well as releases/2.6,
and this will go out in 2.6.0-rc2?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe 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: 2.6.0-rc2

[Colin Alworth]

What's the current thinking on removing ImageResource.isStandalone from 
2.6.0 final, as in the https://gwt-review.googlesource.com/#/c/5504/ review?

It isn't in GWT 2.5.x, and isn't in master, but is present in both 
2.6.0-rc1 and 2. If it was an oversight to add this the first time around, 
shouldn't it be dropped from 2.6 before it goes final? 

Aside from that, seems to be passing all our smoke tests so far, will have 
more comprehensive results tomorrow.

-Colin

On Monday, December 2, 2013 4:49:29 PM UTC-6, Matthew Dempsky wrote:

 I cut a new 2.6.0 release candidate this morning:

   1. There's a 2.6.0-rc2 tag in git.
   2. The gwt-2.6.0-rc2.zip is available on Google Code: 
 https://code.google.com/p/google-web-toolkit/downloads/list
   3. I've pushed a 2.6.0-rc2 release to Maven Central (as usual, I think 
 it takes an hour or so to be available).

 We originally planned to make the final release today, but I had forgotten 
 to take Thanksgiving into account, so I think we'll push the release back 
 until next week.  I'd appreciate if people could help test and wring out 
 any remaining bugs.

 There's still the outstanding version warning from GPE, but a fix for that 
 has already been submitted, and a new GPE release will hopefully be 
 available in the next few days.

 Changes since 2.6.0-rc1: 
 https://gwt.googlesource.com/gwt/+log/2.6.0-rc1..2.6.0-rc2


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe 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: 2.6.0-rc3

[Colin Alworth]

I'm still running into trouble with the major version of the compiled 
classes being 51, so I'm unable to gwt 2.6.0-rc3 to work under jdk 1.6. As 
before, I was able to confirm that the actual .class files are compiled 
correctly, but yet I get fatal errors in attempting to run dev mode. 
Testing so far is on a mac with 1.6.0_65:

$ java -version
java version *1.6.0_65*
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

$ javap -v com.google.gwt.core.client.impl.Impl | head
Compiled from Impl.java
public final class com.google.gwt.core.client.impl.Impl extends 
java.lang.Object
  SourceFile: Impl.java
  InnerClass: 
   public abstract #77= #76 of #170; //UncaughtExceptionHandler=class 
com/google/gwt/core/client/GWT$UncaughtExceptionHandler of class 
com/google/gwt/core/client/GWT
  minor version: 0
  major version: *50*
  Constant pool:
const #1 = Method#61.#163;//  java/lang/Object.init:()V
const #2 = Field#55.#164;//  
com/google/gwt/core/client/impl/Impl.unloadSupport:Lcom/google/gwt/core/client/impl/UnloadSupport;

When in dev mode, I've seen this error:
22:44:37.233 [ERROR] [com.example.SampleProject] Unable to load module 
entry point class null (see associated exception for details)
java.lang.UnsupportedClassVersionError: 
com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.lang.ClassLoader.defineClass(ClassLoader.java:471)
at 
com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121)
at 
com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:249)
at 
com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(ModuleSpace.java:670)
at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:359)
at 
com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200)
at 
com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526)
at 
com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
at java.lang.Thread.run(Thread.java:695)

When running unit tests in dev mode with HtmlUnit, I've seen this:
[ERROR] Unable to load module entry point class null (see associated 
exception for details)
[junit] java.lang.UnsupportedClassVersionError: 
com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0
[junit] Dec 5, 2013 10:51:41 PM 
com.gargoylesoftware.htmlunit.WebConsole info
[junit] at java.lang.ClassLoader.defineClass1(Native Method)
[junit] INFO: /launch error: Failed to load module 
com.example.SampleProject.JUnit.
[junit] at 
java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
[junit] Please see the log for details.
[junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
[junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:471)
[junit] at 
com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121)
[junit] at 
com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
[junit] at java.lang.Class.forName0(Native Method)
[junit] at java.lang.Class.forName(Class.java:249)
[junit] at 
com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(ModuleSpace.java:670)
[junit] at 
com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:359)
[junit] at 
com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200)
[junit] at 
com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526)
[junit] at 
com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
[junit] at java.lang.Thread.run(Thread.java:695)

It has been driving me nuts trying to track down what mistake I could 
possibly be making - I've tried explicitly adding -sourceLevel 1.6 to the 
arguments (which parses correctly, I set breakpoints to avoid the possible 
null issue reported for java 8), but this hasn't seemed to have any effect. 
I'm willing to admit user error, but the really odd thing about this is 
that if I debug 
com.google.gwt.dev.shell.rewrite.WriteJsoImpl.ForJsoDollar's ctor or 
com.google.gwt.dev.asm.ClassWriter.toByteArray() I can pick out that some 
objects have version 49, some have 50, and at least one has 51 (which under 
java 6 is fatal).  Here's the stack at this point, paused on a case where 
version is 

Re: [gwt-contrib] Re: 2.6.0-rc3

[Colin Alworth]

Sorry for being unclear - I'm building/testing an application that makes 
use of GWT while still on Java6, not building/testing GWT itself. I'm 
trying to sanity test rc3 as a candidate for a final release of 2.6.0, and 
as far as my testing goes, this is the only point it is failing.

To clarify the point about the references to Matthew's machine, unzip the 
gwt 2.6.0-rc3 download on code.google.com, unpack the gwt-user.jar file, 
and try this:

$ strings com/google/gwt/core/Core.gwtar  | grep file | head
fileNameq
bfile:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/AsyncProvider.javat
fileNameq
]file:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/Callback.javat
fileNameq
jfile:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/CodeDownloadException.javat
fileNameq
]file:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/Duration.javat
fileNameq
fileNameq

On Friday, December 6, 2013 12:10:10 AM UTC-6, Roberto Lublinerman wrote:

 Hi Colin,

 Did you do ant clean? I find it strange that the resource points to 
 Matthew's hard drive, as if Impl was precompiled by him (and in that case 
 probably is consistent that the version is 51.0).

 I build from scratch in my laptop (only has java 1.6) and builds and tests 
 run fine. Is there a specific application that you are trying to build?




 On Thu, Dec 5, 2013 at 9:23 PM, Colin Alworth nilo...@gmail.comjavascript:
  wrote:

 I'm still running into trouble with the major version of the compiled 
 classes being 51, so I'm unable to gwt 2.6.0-rc3 to work under jdk 1.6. As 
 before, I was able to confirm that the actual .class files are compiled 
 correctly, but yet I get fatal errors in attempting to run dev mode. 
 Testing so far is on a mac with 1.6.0_65:

 $ java -version
 java version *1.6.0_65*
 Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
 Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

 $ javap -v com.google.gwt.core.client.impl.Impl | head
 Compiled from Impl.java
 public final class com.google.gwt.core.client.impl.Impl extends 
 java.lang.Object
   SourceFile: Impl.java
   InnerClass: 
public abstract #77= #76 of #170; //UncaughtExceptionHandler=class 
 com/google/gwt/core/client/GWT$UncaughtExceptionHandler of class 
 com/google/gwt/core/client/GWT
   minor version: 0
   major version: *50*
   Constant pool:
 const #1 = Method#61.#163;//  java/lang/Object.init:()V
 const #2 = Field#55.#164;//  
 com/google/gwt/core/client/impl/Impl.unloadSupport:Lcom/google/gwt/core/client/impl/UnloadSupport;

 When in dev mode, I've seen this error:
 22:44:37.233 [ERROR] [com.example.SampleProject] Unable to load module 
 entry point class null (see associated exception for details)
 java.lang.UnsupportedClassVersionError: 
 com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:471)
 at 
 com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121)
 at 
 com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:249)
 at 
 com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(ModuleSpace.java:670)
 at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:359)
 at 
 com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200)
 at 
 com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526)
 at 
 com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
 at java.lang.Thread.run(Thread.java:695)

 When running unit tests in dev mode with HtmlUnit, I've seen this:
 [ERROR] Unable to load module entry point class null (see associated 
 exception for details)
 [junit] java.lang.UnsupportedClassVersionError: 
 com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 51.0
 [junit] Dec 5, 2013 10:51:41 PM 
 com.gargoylesoftware.htmlunit.WebConsole info
 [junit] at java.lang.ClassLoader.defineClass1(Native Method)
 [junit] INFO: /launch error: Failed to load module 
 com.example.SampleProject.JUnit.
 [junit] at 
 java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
 [junit] Please see the log for details.
 [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
 [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:471)
 [junit] at 
 com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121

Re: [gwt-contrib] Re: 2.6.0-rc3

[Colin Alworth]

Workaround: add -Dgwt.usearchives=false  to your jvm args when invoking the 
tests or dev mode. From maven this uses the extraJvmArgs param: 
http://mojo.codehaus.org/gwt-maven-plugin/compile-mojo.html#extraJvmArgs.

On Friday, December 6, 2013 1:03:57 AM UTC-6, Roberto Lublinerman wrote:

 It seems that we need to build the release with -sourceLevel 6 for it to 
 work with Java 6.


 On Thu, Dec 5, 2013 at 10:43 PM, Colin Alworth nilo...@gmail.comjavascript:
  wrote:

 Sorry for being unclear - I'm building/testing an application that makes 
 use of GWT while still on Java6, not building/testing GWT itself. I'm 
 trying to sanity test rc3 as a candidate for a final release of 2.6.0, and 
 as far as my testing goes, this is the only point it is failing.

 To clarify the point about the references to Matthew's machine, unzip the 
 gwt 2.6.0-rc3 download on code.google.com, unpack the gwt-user.jar file, 
 and try this:

 $ strings com/google/gwt/core/Core.gwtar  | grep file | head
 fileNameq

 bfile:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/AsyncProvider.javat
 fileNameq

 ]file:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/Callback.javat
 fileNameq

 jfile:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/CodeDownloadException.javat
 fileNameq

 ]file:/usr/local/google/home/mdempsky/wd/gwt/user/src/com/google/gwt/core/client/Duration.javat
 fileNameq
 fileNameq


 On Friday, December 6, 2013 12:10:10 AM UTC-6, Roberto Lublinerman wrote:

 Hi Colin,

 Did you do ant clean? I find it strange that the resource points to 
 Matthew's hard drive, as if Impl was precompiled by him (and in that case 
 probably is consistent that the version is 51.0).

 I build from scratch in my laptop (only has java 1.6) and builds and 
 tests run fine. Is there a specific application that you are trying to 
 build?


  

 On Thu, Dec 5, 2013 at 9:23 PM, Colin Alworth nilo...@gmail.com wrote:

 I'm still running into trouble with the major version of the compiled 
 classes being 51, so I'm unable to gwt 2.6.0-rc3 to work under jdk 1.6. As 
 before, I was able to confirm that the actual .class files are compiled 
 correctly, but yet I get fatal errors in attempting to run dev mode. 
 Testing so far is on a mac with 1.6.0_65:

 $ java -version
 java version *1.6.0_65*
 Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
 Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

 $ javap -v com.google.gwt.core.client.impl.Impl | head
 Compiled from Impl.java
 public final class com.google.gwt.core.client.impl.Impl extends 
 java.lang.Object
   SourceFile: Impl.java
   InnerClass: 
public abstract #77= #76 of #170; //UncaughtExceptionHandler=class 
 com/google/gwt/core/client/GWT$UncaughtExceptionHandler of class 
 com/google/gwt/core/client/GWT
   minor version: 0
   major version: *50*
   Constant pool:
 const #1 = Method#61.#163;//  java/lang/Object.init:()V
 const #2 = Field#55.#164;//  com/google/gwt/core/client/
 impl/Impl.unloadSupport:Lcom/google/gwt/core/client/impl/UnloadSupport;

 When in dev mode, I've seen this error:
 22:44:37.233 [ERROR] [com.example.SampleProject] Unable to load module 
 entry point class null (see associated exception for details)
 java.lang.UnsupportedClassVersionError: 
 com/google/gwt/core/client/impl/Impl 
 : Unsupported major.minor version 51.0
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:471)
 at com.google.gwt.dev.shell.CompilingClassLoader.findClass(
 CompilingClassLoader.java:1121)
 at com.google.gwt.dev.shell.CompilingClassLoader.loadClass(
 CompilingClassLoader.java:1194)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:249)
 at com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(
 ModuleSpace.java:670)
 at com.google.gwt.dev.shell.ModuleSpace.onLoad(
 ModuleSpace.java:359)
 at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(
 OophmSessionHandler.java:200)
 at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(
 BrowserChannelServer.java:526)
 at com.google.gwt.dev.shell.BrowserChannelServer.run(
 BrowserChannelServer.java:364)
 at java.lang.Thread.run(Thread.java:695)

 When running unit tests in dev mode with HtmlUnit, I've seen this:
 [ERROR] Unable to load module entry point class null (see associated 
 exception for details)
 [junit] java.lang.UnsupportedClassVersionError: 
 com/google/gwt/core/client/impl/Impl : Unsupported major.minor version 
 51.0
 [junit] Dec 5, 2013 10:51:41 PM 
 com.gargoylesoftware.htmlunit.WebConsole 
 info
 [junit

Re: [gwt-contrib] Re: 2.6.0-rc3

[Colin Alworth]

This system property isn't listed when either dev mode or the compiler runs
because it is a system property, not a program arg. It should be provided
with the other VM args when you start Java. These aren't listed as part of
the normal properties, but are documented here:
http://code.google.com/p/google-web-toolkit/wiki/JavaSystemPropertiesAndGwt

We probably should migrate that table (and expand it?), but for the most
part these are used to tweak internals that shouldn't normally be needed.
In the case of the issue I'm pointing out with java6, it appears that this
issue is only due to a build problem when the RC was originally compiled.
The only other flag I use in the list with any regularity is
gwt.jjs.traceMethods, which lets you see what the compiler is doing with
each method as it works.


On Sun, Dec 8, 2013 at 5:28 PM, Juan Pablo Gardella 
gardellajuanpa...@gmail.com wrote:

 Thanks Thomas!


 2013/12/8 Thomas Broyer t.bro...@gmail.com



 On Sunday, December 8, 2013 2:12:31 PM UTC+1, Thomas Broyer wrote:


 On Saturday, December 7, 2013 7:42:42 PM UTC+1, juan_pablo_gardella
 wrote:

 HostedMode appears in http://www.gwtproject.org/doc/latest/
 DevGuideCompilingAndDebugging.html at the section Development Mode
 Options.


 Will fix.


 See https://gwt-review.googlesource.com/5651

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
218.248.6165
niloc...@gmail.com

-- 
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: Questions remain for the GWT.create Steering Committee members

[Colin Alworth]

Another thought: Christian Sedilek, Dan Kurka, and myself can also be found 
pretty frequently in ##gwt on irc.freenode.net for a more informal 
discussion - I'd love to see more steering committee members hang out 
there, even if just idling most of the time, and chatting once in a while.

Keeping these discussions as 'conversations' rather than as written 
documents probably helps them to stay a little more informal - rather than 
feeling like we're describing our collective vision for what GWT will be in 
6, 12, 18 months, we get to be a little more interactive to hear about what 
people need GWT to be, and we get to float some ideas out there. From my 
perspective, that was an important step at the SF conf, getting us all to 
hear about concerns around SDM - since that panel discussion, I've switched 
my local development to about 80% sdm to try to come up with more concrete 
ways to improve how we document it and encourage people to use it. In 
Frankfurt, we fielded fewer online questions and got more from the room, 
and seemed to center around how GWT will change going forward - which 
browsers can be dropped, how we might continue to make Dev Mode work or 
otherwise keep in-IDE debugging. 

On Thursday, January 2, 2014 9:56:39 AM UTC-6, Daniel Kurka wrote:

 Just an idea: We could think about doing a hangout maybe every quarter 
 with a pre populated moderator.


 On Tue, Dec 17, 2013 at 4:09 PM, Michael Prentice 
 spla...@gmail.comjavascript:
  wrote:

 That would be great. I know that they are busy with the EU conference 
 this week, but there were a lot more questions to be addressed. I already 
 gave some feedback that we might need to expand the panel QA's next year 
 (either split them by some topics or extend the time).


 On Monday, December 16, 2013 3:58:07 PM UTC-5, Boris Brudnoy wrote:

 Hello,

 The closing session of the GWT.create 2013 US saw a panel of the GWT 
 Steering Committee members answer attendee questions. It so happened that 
 the issue of the changing debugging tools hijacked (most of) the 
 conversation but there were plenty more good questions the attendees 
 entered on the Moderator page for the panel: https://www.google.com/
 moderator/#7/e=21396f.

 I am wondering if perhaps the Steering Committee members could find time 
 to address the remaining questions in writing and, for example, post it on 
 the G+ community page?


  -- 
 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.comjavascript:
 .
 For more options, visit https://groups.google.com/groups/opt_out.




 -- 
 Google Germany GmbH
 *Dienerstr. 12*
 *80331 München*

 Registergericht und -nummer: Hamburg, HRB 86891
 Sitz der Gesellschaft: Hamburg
 Geschäftsführer: Graham Law, Katherine Stephens
  

-- 
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] gwtproject.org link tree broken

[Colin Alworth]

Something funny has happened to the dont-reload-the-page code on 
gwtproject.org, but I'm not seeing any obvious commit that should have done 
this.

Steps to repro:
1) visit http://gwtproject.org/, or any *top level* document
2) observe that any link you hover looks to be correct, and visiting any 
link will work correctly (including opening it from a new tab
3) Click on any *nested* link (such as something inside of articles  or 
documentation  latest ).
4) Now, hover over any link, and notice that the subdirectory you are 
currently in will be prepended to the link url
5) Open that link in a new tab, observe that you get a 404.

Example:
Go to http://gwtproject.org/.
Expand Documentation, Latest, and click on Overview.
Right-click Accessibility, and select 'open in a new tab'
Observe 404 error page, and obviously broken url: http://www.gwtproject.org/
*doc/latest/doc/latest/*DevGuideA11y.html

The source at https://gwt.googlesource.com/gwt-site-webapp/+/master/ hasn't 
been updated since early December, and I can't imagine this has been broken 
that long, and none of the recent commits to gwt-site itself seem capable 
of this, so I'm at a bit of a loss as to how this could have happened. Were 
there perhaps any changes made that didn't go through googlesource.com, or 
has this really been broken for months?

-- 
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: Quarterly Hangouts On Air

[Colin Alworth]

The concern I've heard expressed during in-person discussions about how to
do this is that a written document of answers 'feels' more real and
concrete than a group of people answer questions live, since they clearly
have no chance to vet their answers from their own organization or with
each other. As long as the questions stay in the realm of what GWT
currently is, that wouldn't be an issue, but when we start jumping into the
When will IE X support be dropped or When will Java Y support be added
or Why isn't my library being added to GWT territory, the panelists may
feel as though it is safer to just leave the questions un-answered. That
said, this would be keeping in the reddit ama form...

With a live speaker and panel, if no one answers a question, the dead airs
gets to people, and someone steps up to try an answer or at least rephrase
the question, even though the answer might be qualified (this is just my
opinion), or vague (we're still working through the specifics).

BTW, there is a /r/gwt already, we could start there for some informal
stuff (weekly/monthly AMAs), and then do a slightly more official call
quarterly?


On Tue, Jan 28, 2014 at 9:59 AM, James Nelson ja...@wetheinter.net wrote:

 A reddit-style AMA would be really cool; so long as we give enough warning
 and promo,
 (like posting the event in the G+ community a month ahead of time) I'm
 sure it would be a hit.

 The questions in the moderator would probably all get asked;
 though seeing some of them come up in the gwt-team meetings would be cool
 too.

 An actual hangout over a single time slot generally leaves a lot of people
 unable to come,
 so, maybe we'll see if we can keep attracting a lot of people to the
 community meetings,
 and maybe we'll get a greater audience to steering committee meetings.

 The only reason I was not viewing the public committee meetings was
 visibility;
 my gwt-contrib emails were getting filtered with hundreds of other group
 emails,
 so I didn't really keep up (have since create a filter specifically for
 Gwt).

 I am going to email Bhaskar to see if I can get plugged in on the meeting
 tomorrow,
 and I bet if we post it on G+, we'll see greater developer interest.

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




-- 
218.248.6165
niloc...@gmail.com

-- 
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: XSS in GWT

[Colin Alworth]

Another set of dangerous code to look for would be any SafeHtmlUtils or 
SafeHtmlBuilder (and their uri/style conterparts) call that should take 
'constant' or 'trusted' but instead takes untrusted user data. Custom 
implementions of SafeHtml should also be treated as suspect.

These all fall under the category of Deliberately abusing the safehtml api 
will make it no longer safe.

On Tuesday, January 28, 2014 11:17:49 AM UTC-6, Thomas Broyer wrote:



 On Tuesday, January 28, 2014 5:04:08 PM UTC+1, Kurt Dmello wrote:

 Hey folks,
 I am a relative noob to GWT and have been looking at it from a security 
 code review perspective.  I want to create a set of guidelines for people 
 who have to review GWT code from a security perspective looking for 
 vulnerabilities.

 I have read and understood :
 http://www.gwtproject.org/articles/security_for_gwt_applications.html

 I have also implemented the StockWatcher application by following the 
 tutorial.

 In trying to introduce vulnerabilities that I could exploit as a 
 demonstration for what to look for I have failed.  My understanding after 
 reading the article on GWT security was that if tainted data is set using 
 setHTML() or setInnerHTML() on a client widget it will be suceptable to 
 XSS. 

 I found the HTML() widget to contain a setHTML() routine that took a 
 String and not SafeHTML and set its value to contain a variety of standard 
 XSS exploits such as scriptalert(1);/script.  It does not produce the 
 expected results.  It seems to me that there is a black list or further 
 escaping that happens underneath the covers.  Is it that I am simply out 
 popping out to the right context or is GWT truly immune to XSS.


 What you're seeing here is browser sanitization from innerHTML (not 
 sanitization actually, just that the script are not run). Try with img 
 onerror=alert(1) src=// or similar (onclick, etc.)
  

 What should someone performing code review on a GWT app. be looking for ?


 Everywhere SafeHtml / SafeStyles / SafeUri could be used but is not 
 (HasHTML#setHTML is one such things)


-- 
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: XSS in GWT

[Colin Alworth]

For JSON, you'd have go pretty far out of your way to get attacked, like 
loading something untrusted via JSONP, or manually parsing your own json 
with eval (rather than any of the safe built-in tools), or, ya know, 
forgetting to run SSL and having someone intercept your server 
communication. This isn't GWT specific, you just have to ignore basic web 
security stuff for these.

GWT doesn't run on the server, so XSRF issues don't really apply to GWT 
itself. To be attacked in this way, the server needs to accept requests 
from remote (i.e. attacking) sites without doing something to confirm that 
they came from the real app. The default RPC and RequestFactory servlets 
don't do any session or auth management, so don't have a specific 
vulnerability, but a POST sent to them from an attacking site that is 
treated as a request from the app itself entirely based on the contents of 
a cookie (i.e. jsessionid) could be an attack vector. As I said though, 
RPC/RF don't build in any security but leave it to the app to decide what a 
user is, what a session is - the code that is reading the HTTP request and 
deciding that a request is valid is responsible for that. Both RPC and RF 
have ways to add some content to the body that keyed off of something only 
a real request from the user should know.

On Tuesday, January 28, 2014 2:22:03 PM UTC-6, Kurt Dmello wrote:

 Thanks folks,
 This is great stuff.  Keep it coming !

 I am looking for all potential points of interest in a code review.  
 Including XSRF and JSON related vulnerabilities.


-- 
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: GWT + Maven - Using gwt-dev package as dependency

[Colin Alworth]

If you know enough to start writing generators, it almost certainly is not 
a concern - you are probably also careful with which GWT version you are 
using as well as which gwt-m-p version. A problem can occur if more than 
one version of gwt-dev is present on the classpath, such as a mistakenly 
declared copy in your dependencies and the copy that gwt-m-p automatically 
pulls in. Provided both versions are the same or care is taken to ensure 
that gwt-m-p uses the same dependency, there is no issue.

See 
http://mojo.codehaus.org/gwt-maven-plugin/user-guide/using-different-gwt-sdk-version.html
 
for how to configure your project to allow for different GWT SDK version 
from the maven plugin. I typically use two different properties, one for 
gwt.version, and a second for gwt.plugin.version with this strategy to 
allow them fall out of sync in a safe way.

On Friday, February 7, 2014 11:09:23 AM UTC-6, Gilberto Torrezan Filho 
wrote:

 Hi,

 I'm using GWT 2.6.0 with Maven, using the gwt-maven-plugin, and in my 
 project I have some auto generated classes (using the generated-with 
 directive on Module.gwt.xml). The generator is a subclass of 
 com.google.gwt.core.ext.Generator.

 The problem is: every time I build my project, Maven emits a warning:

 [WARNING] Don't declare gwt-dev as a project dependency. This may 
 introduce complex dependency conflicts


 ... but I have to declare gwt-dev as dependency, since I need it to 
 compile my code generator.

 I never faced any conflict - maybe because I'm declaring gwt-dev with the 
 provided scope, avoiding it to be part of the generated war. So, in this 
 scenario, is that warning still accurate? Is there any other way to avoid 
 it (while still having the code generators)?

 Thanks.


-- 
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] ModuleDefLoader changes and CompilerContext

[Colin Alworth]

Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, but 
I've also seen this trying to understand the general compiler changes that 
are happening in trunk gwt - is the CompilerContext really an essential 
part of ModuleDefLoader in general? From what I can see it is tracked as a 
local variable, but only used in the enforceStrictResources() check, which 
could just as easily be a boolean. For any synthetic module (which can't 
have any resources at all), this is a moot point so the context could be 
skipped entirely, and more generally it *seems* to just be a flag. 

CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and 
passes it to the JdtCompiler, which doesn't actually use it at all - that 
seems to be the extent of its use when you do a 
ModuleDef.getCompilationState (which now requires that context as an 
argument, even though the ModuleDef already should have that state from the 
previously mentioned ModuleDefLoader?). Precompile takes it to get the 
module and the options (instead of taking the module and the options), and 
the J2JSCompiler takes it just to read options.

At least as of 2.6 branch, haven't done the same tracing through master 
just yet.

So my question is two-fold: Is this the new way of avoiding too many sets 
of config types to track, and if so, why restore the old APIs so that the 
designer can use them in 2.6.1 instead of updating the designer to generate 
a simple context for its own needs? Assuming this is the future way of 
dealing with options/etc, won't the designer just break again as this 
becomes more and more necessary to hook into the compiler from outside?

-- 
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] ModuleDefLoader changes and CompilerContext

[Colin Alworth]

Thanks for the reply - I'll keep watching ;).

W.R.T. designer, since existing installs are already broken and GWT 3+ is 
going to again remove these deprecated methods, wouldn't it make more sense 
to upgrade designer rather than downgrade ModuleDefLoader/DOM? (Keeping in 
mind that I don't know what other upcoming changes are coming, but I'm 
assuming that code like ModuleDefLoader will eventually have some 
advantages from the context objects, and designer can't just keep using 
this now-deprecated method forever.)

On Monday, February 10, 2014 3:02:00 PM UTC-8, John Stalcup wrote:




 On Mon, Feb 10, 2014 at 2:57 PM, Colin Alworth nilo...@gmail.comjavascript:
  wrote:

 Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, 
 but I've also seen this trying to understand the general compiler changes 
 that are happening in trunk gwt - is the CompilerContext really an 
 essential part of ModuleDefLoader in general? From what I can see it is 
 tracked as a local variable, but only used in the enforceStrictResources() 
 check, which could just as easily be a boolean. For any synthetic module 
 (which can't have any resources at all), this is a moot point so the 
 context could be skipped entirely, and more generally it *seems* to just be 
 a flag. 

 not all changers are in. there are more uses coming. 


 CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and 
 passes it to the JdtCompiler, which doesn't actually use it at all - that 
 seems to be the extent of its use when you do a 
 ModuleDef.getCompilationState (which now requires that context as an 
 argument, even though the ModuleDef already should have that state from the 
 previously mentioned ModuleDefLoader?). Precompile takes it to get the 
 module and the options (instead of taking the module and the options), and 
 the J2JSCompiler takes it just to read options.

 At least as of 2.6 branch, haven't done the same tracing through master 
 just yet.

 So my question is two-fold: Is this the new way of avoiding too many sets 
 of config types to track, and if so, why restore the old APIs so that the 
 designer can use them in 2.6.1 instead of updating the designer to generate 
 a simple context for its own needs?

 updating the designer code would leave existing designer installs broken.
  

 Assuming this is the future way of dealing with options/etc, won't the 
 designer just break again as this becomes more and more necessary to hook 
 into the compiler from outside?
  
 -- 
 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.comjavascript:
 .
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Colin Alworth]

In CrossSiteIframeTemplate.js this is handled by assigning 
__MODULE_FUNC__.__softPermutationId to 0 to begin with, and then only 
change that value if : was present in the permutation string. I'm not 
seeing any other js files that init __softPermutationId to 0, and only 
permutations.js assigns it to another value (but does so conditionally, so 
it never *assigns* undefined to __softPermutationId, it just leaves it not 
defined).

var idx = strongName.indexOf(':');
if (idx != -1) {
  softPermutationId = parseInt(strongName.substring(idx + 1), 10);
  strongName = strongName.substring(0, idx);
}

In researching 
https://code.google.com/p/google-web-toolkit/issues/detail?id=8539 
recently, this seemed to make sense (except in the context of the bug, 
where the permutationId in CollapsedPropertyHolder where it gets 
overwritten when it loads in a split point...). Looking at permutations.js, 
it defines a method getCompiledCodeFilename(), but from a grep of the 
codebase, this is only ever called from CrossSiteIframeTemplate.js, which 
as mentioned above, sets a default value of zero. 

The key direct_install maps to 
com.google.gwt.core.linker.DirectInstallLinker, which extends 
CrossSiteIframeLinker, and overrides getJsInstallScript to use 
com/.../installScriptDirect.js instead of 
com/.../installScriptEarlyDownload.js and change another boolean, but 
neither of those appear to block getSelectionScriptTemplate from being used 
to determine the actual selection script. Which should then mean that 
softPermutationId gets init'd to zero. 

That's just at a quick glance - aside from that I only have an absence of 
evidence of the bug but no evidence of absence. We use a lot of soft 
permutations, and 8539 is the only time we've seen an issue (where the 
first time the value gets used is in a split point) - any chance that is 
what is biting you instead?

On Thursday, February 13, 2014 11:41:50 AM UTC-8, Stephen Haberman wrote:

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

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

[Colin Alworth]

Only note to add here is that the AngularJS project does require a CLA also 
(see https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#cla) 
- it looks like they either have a bot which complains about missing CLAs 
on file (and so some associated between username and real name), or a very 
diligent user with a form that gets copy/pasted a lot. But, as Thomas 
noted, this can't stop a developer from accidently merging code which the 
contributor may not have the rights to merge. 

Okay, one more though: Remember the mess between Google and Oracle over 
Android emulating the JRE, specifically the part about possibly reusing 
some without permission? GWT has the same basic issue, the CLA isn't just 
about allowing Google to use the code, but also the contributor's guarantee 
that they have the rights to commit the changes they are making.

On Saturday, March 29, 2014 9:28:22 PM UTC-5, Thomas Broyer wrote:



 On Sunday, March 30, 2014 3:41:33 AM UTC+2, Benjamin Possolo wrote:

 I am interested in helping modernize the 
 gwtproject.orgwebsite/documentation and part of that effort would include 
 moving the code 
 to GitHub.

 I think GitHub provides a certain amount of credibility that lacks with 
 the current Gerrit system.


 Do you imply that the same system that is used for Android and ChromiumOS 
 lacks credibility? The same that's also used by Eclipse, OpenStack, Typo3, 
 Qt, Wikimedia, etc. https://code.google.com/p/gerrit/wiki/ShowCases
  

 Moving to GitHub would encourage more people to contribute and get 
 involved because they are familiar with the github UI and the process for 
 submitting pull requests, performing code reviews, etc.


 I agree GitHub is more familiar to many than Gerrit, and that would 
 probably ease contributions.
 But, as far as I'm concerned, I wouldn't move to GitHub (at least for GWT 
 proper).

 The main reasons we chose Gerrit were:
 * side-by-side diffs
 * enforcing a clean history (this is particularly important as Google 
 syncs their internal Perforce repo with the public Git repo, the history 
 needs to be linear for them)
 The website doesn't have those clean history constraints, but it'd be a 
 bit strange to use another system to review changes for the website than 
 changes to GWT proper (note that I'm not strongly against it)
 I believe you can find some discussions on the subject in the archives of 
 https://groups.google.com/d/forum/gwt-steering

 At GitHub, to maintain a clean history means that you either ask every 
 contributor to rebase and squash their branches before you can merge them, 
 and/or you rebase and squash them yourself when merging, but it at least 
 means being very careful when clicking the merge button (so careful that 
 you'd probably want to disable it –that's not possible– and force every 
 commiter to merge manually with --ff-only or --squash).

 We're starting seeing integrations between Gerrit and GitHub (
 http://gerrithub.io/), so who knows, maybe one day that plugin will be 
 available on gwt-reviews so contributors will be able to submit changes as 
 GitHub Pull Requests rather than pushing them to Gerrit.

 In the mean time, I believe what we need is better documentation. Our 
 making GWT better web page is really light. Patches welcome.
  

 Not to mention, it is simply much more social and transparent.


 !?
 I could understand the more social argument (although I don't think it's 
 a compelling one), but more transparent?
  

 It sounds like Gerrit has a feature that only allows patches from people 
 that have signed contributor legal agreements.
 I guess I don't really understand why this is necessary now that GWT has 
 become fully open sourced and is no longer owned by Google.


 Required reading: 
 http://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/and 
 http://www.clahub.com/pages/why_cla
 Ideally, the GWT Project would be a legal organization so you'd sign a CLA 
 with the GWT Project. But it's not, so you still sign an agreement with 
 Google.
  

 However, if this is actually necessary, couldn't we simply use a git 
 commit hook to enforce it?


 Yes, there are things like CLAHub; but you need to train all committers to 
 not look at patches until the CLA has been signed, it's not enforced.
 Similarly, GitHub hooks with the PR status API can inform you of the build 
 status of a pull request, but nothing prevents you from merging it. On the 
 other hand, merging a change that fails to build in Gerrit needs special 
 permissions (even though we don't do a full build, so in practice a change 
 can still break the build without failing the pre-check)
  

 AngularJS is on GitHub..doesn't make sense to me why Google Web Toolkit 
 can't be.


 Well, it is (https://github.com/gwtproject) but only as a mirror (to make 
 forks easier), and not for all projects (it's probably just a matter of 
 asking GitHub to mirror the missing projects). The issue tracker is still 
 at code.google.com 

[gwt-contrib] Re: Native Authorization in GWT

[Colin Alworth]

This seems to be a pretty quiet discussion so far, with mostly Zied 
responding to himself and Thomas’s one initial reply, but it is a holiday 
weekend here in the US, so that might be contributing to the lack of 
additional responses. I haven’t had the chance to even look at the initial 
proposal until this morning, but at a glance, I agree that it would be an 
interesting successor to uibinder or add-on to uibinder, but likely a poor 
modification of uibinder. I’m going to completely ignore the security 
aspect, as the ‘best practice’ is to ‘do it on the server’, and never ever 
trust the client. If you try trusting the client, you are better of just 
omitting the security to avoid any false sense of safety ;).

 - UiBinder is totally declarative - if it had the feature to wire in 
logical statements, we should equally have loop and conditional constructs. 
 - Not everyone uses UiBinder, not everything can be done with UiBinder - 
use of this tool will be limited to users and use-cases that already are 
good fits for uibinder. Anything that is @UiField(provided=true)/@UiFactory 
may be ineligible (since they may be have some runtime decided type, so the 
UiBinder generator can’t see their moving target of setters), any cells or 
other non-uibinder-able ui components can’t work either.
 - I don’t see a full proposal anywhere, but from the issue at 
code.google.com it appears that the intention is to provide isAllowed and 
isReadOnly, and these cases only at initial widget creation, based on a 
String idPath, synchronously. Implications from here: All possible 
permissions that the app might ever access need to be loaded preemptively, 
and from that the server needs to know (and have sent) all possible paths 
that the app might have, permissions can’t change without the app being 
reloaded (either user gets errors from the server when permissions change 
while the app is running, or whole app should be refreshed when any 
permission change of current user, group, or other business logic changes), 
and permissions are never data-dependent (no need to ever check if the user 
‘owns’ the given object, etc). 
 - isAllowed is a bit of a terrifying prospect - either it is not being 
rendered as the specified type (i.e. all @UiFields must be Object and 
typed-checked at runtime), or they are left as null (and null checked for 
any .add, .setWidget that uses them, any add/setter called *on* them, and 
any {} reference made *to* them across all of uibinder internals). Again, 
not very declarative, since the type assumptions that can be made by users 
authoring the matching .java and .ui.xml need to assume that any of their 
declared code in xml might just be ignored and not available in .java.

Were I doing this, I’d go in another direction - don’t try to rewrite 
UiBinder into an imperative language, but instead make your own 
non-declarative xml-widgets that cover the required cases. Support 
conditions and looping, expect to call out to java (or better yet let java 
call back in to note that a state change has happened in permissions), and 
accept more data, such as the current model object, etc. No need to be 
accommodating to UiBinder or non-UiBinder, since this is a new tool 
entirely.

For fun, I made a aop-replacement tool, ostensibly for simple ui hints 
about permissions for access to things. The goal wasn’t to demonstrate that 
*all* AOP can be achieved with simpler constructs, but instead to show that 
much if it can, much of the time, with very little code. This tool was 
annotation based - define your own annotations and the logic that drives 
them, stick them on fields in the view, and ask the rules to run when any 
changes are made. For example, this annotation means ‘call 
.setVisible(currentUser.group == foo) on any widget with 
@OnlyVisibleTo(foo) on it. This is triggered by extending an interface and 
keying off of the view type and the model type - the resulting object has a 
‘apply’ method that lets it take the view and the model, and applies the 
various rules declared in the view. 
Annotation: 
https://bitbucket.org/niloc132/generated-permissions/src/909e8cd41449c34ca2e3e659de921dc4221342e5/src/main/java/com/colinalworth/gwt/perms/sample/client/Sample.java?at=master
Sample that uses the annotation:
https://bitbucket.org/niloc132/generated-permissions/src/909e8cd41449c34ca2e3e659de921dc4221342e5/src/main/java/com/colinalworth/gwt/perms/sample/client/OnlyVisibleTo.java?at=master

I’m not proposing that this is the only way to solve this, but it is 
compatible with regular java views or UiBinder (just stick the annotations 
next to the @UiField). I also am not pushing this as a way to solve this 
sort of problem out of concerns for developers confusing the concept of 
hiding or disabling a widget with actual authorization, but am instead 
trying to move this toward a sort of binding tool, but for properties other 
than what editors normally work with (i.e. getter/setter against 

[gwt-contrib] Re: Officially deprecating Opera permutation

[Colin Alworth]

I've just opened https://gwt-review.googlesource.com/7780 to make it 
possible to specify a fallback for any/all useragents that don't match one 
of the built-in rules, via a rule like:

set-property-fallback name=user.agent value=webkit/

This example rule treats any unknown useragent as if it were webkit, rather 
than the non-existent 'unknown' useragent, which subsequently tries to load 
undefined.cache.html, etc. This could also be used in conjunction with 
defining a user.agent value for unknown browsers and falling back to an 
existing one (like Thomas suggested), along with a possible error message, 
but that runs the risk of failing to match any CssResource @if rules, for 
example. This will of course create a huge amount of warnings in your 
application Could not find an exact match rule. Using 'closest' rule... 
when attempt to rebind things that cannot be matched to unknown and fall 
back to gecko1_8, etc.

!-- Create new value, try and use ff details for it (most of the time) 
--
extend-property name=user.agent values=unknown 
fallback-value=gecko1_8 /
!-- this line is not actually necessary unless you want to use a 
string other than 'unknown', and won't work before the above patch --
set-property-fallback name=user.agent value=unknown/
!-- 'most of the time' we want ff, except for a warning when the page 
boots. --
!-- To achieve that, we create a second entrypoint that extends the 
real one, but also displays a warning about this browser being unsupported 
--
replace-with class=pack.age.to.client.UnknownBrowserEntryPoint
when-type-is class=pack.age.to.client.RealAppEntryPoint /
/replace-with

Thomas, were you suggesting a filter in GWT itself to let the server do 
this, or to have an 'UnknownUserAgentEntryPoint' built into GWT itself?

On Saturday, May 10, 2014 5:27:37 PM UTC-5, Thomas Broyer wrote
...snip...

 That said, Google Groups and Google Flight Search fallback to the gecko1_8 
 permutation in Opera 12 (with a warning message that it might break), so we 
 should probably make it possible at least (Google uses a server-side 
 selection script based on the User-Agent request header, rather than the 
 *.nocache.js using navigator.userAgent on the client-side)
 Would you mind opening an issue about it?
 Maybe there's a workaround though: it might be as easy as defining a 
 unknown (the value returned by the property generator) value for the 
 user.agent property that falls back to gecko1_8 (just like ie9 falls back 
 to ie8): i.e. extend-property name=user.agent values=unknown 
 fallback-value=gecko1_8 /; and then you could use deferred-binding 
 specifically for that unknown value to display a warning message, and you 
 could collapse unknown and gecko1_8 values into the same permutation.
 Worth a try IMO if you care about it.

 On Friday, May 9, 2014 8:14:55 PM UTC+2, Robert J. Carr wrote:

 This just burned me.  Just curious why you couldn't have it load the file 
 from firefox or webkit instead of just doing nothing?  Better to deal with 
 potential errors than to be a total non-starter.



-- 
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/de99d642-710b-44c9-8439-11a108d8e840%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Officially deprecating Opera permutation

[Colin Alworth]

Sorry, that first line should say 'safari' (or any other valid user.agent 
value), not 'webkit'. Wishful thinking perhaps...

set-property-fallback name=user.agent value=*safari*/

-- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe 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/92eace59-aa42-468c-823e-8c39dd82ff59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] SafeHtml on the server/vm

[Colin Alworth]

Currently SafeHtml co live in gwt-user, though they are for the most part 
listed in a shared package, implying that a server can use them. However, 
gwt-user.jar also includes javax packages as well as hibernate, w3c, etc, 
so can't reasonably be imported to a server which already uses any of those 
packages (i.e. any servlet container). Is this an oversight in the publicly 
packaged GWT and is SafeHtml used by teams that package differently, or 
instead is this package not actually intended for server use, but instead 
just compile-time tasks where gwt-user is on the classpath like compiling 
or linking?

I'm doing some work on a non-servlet server which hasn't so far seen 
concrete issues with gwt-user.jar, and having SafeHtml seemed to be an easy 
way to get server generated HTML from code that is shared with the client. 
This use case *appears* to be implied from the package name, but presently 
isn't possible for the majority of GWT backends.

Ideas on why it is the way it is? Thoughts on how to make it available to 
the server (without giving it yet another jar a la requestfactory-server)? 
Interest in a contributed SafeHtmlTemplates implementation for JVM?

Thanks,
Colin

-- 
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/f3f89edf-ce77-4975-a5c8-f33e7e0a1886%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] SafeHtml on the server/vm

[Colin Alworth]

Like I said, its not a concern for me (no servlet, no hibernate, no flute),
but for those who want to stick gwt-user.jar in a WEB-INF/lib/, it would be
nice to not have to renamed it zwt-user.jar.

My knee-jerk reaction is to put it in gwt-servlet (since other relatively
new classes like AutoBeanFactorySource also made it in there) - does that
seem like a reasonable step?


On Mon, Jun 9, 2014 at 6:22 PM, John A. Tamplin j...@jaet.org wrote:

 On Mon, Jun 9, 2014 at 6:33 PM, Colin Alworth niloc...@gmail.com wrote:

 Currently SafeHtml co live in gwt-user, though they are for the most
 part listed in a shared package, implying that a server can use them.
 However, gwt-user.jar also includes javax packages as well as hibernate,
 w3c, etc, so can't reasonably be imported to a server which already uses
 any of those packages (i.e. any servlet container). Is this an oversight in
 the publicly packaged GWT and is SafeHtml used by teams that package
 differently, or instead is this package not actually intended for server
 use, but instead just compile-time tasks where gwt-user is on the classpath
 like compiling or linking?

 I'm doing some work on a non-servlet server which hasn't so far seen
 concrete issues with gwt-user.jar, and having SafeHtml seemed to be an easy
 way to get server generated HTML from code that is shared with the client.
 This use case *appears* to be implied from the package name, but presently
 isn't possible for the majority of GWT backends.

 Ideas on why it is the way it is? Thoughts on how to make it available to
 the server (without giving it yet another jar a la requestfactory-server)?
 Interest in a contributed SafeHtmlTemplates implementation for JVM?


 Yes, SafeHtml is intended to be usable on the server.  There have been
 various discussions about splitting up gwt-user into parts for client-only,
 shared (and perhaps server-only), but that wasn't ever done.

 Mostly, putting gwt-user last on the classpath on your server won't cause
 any issues, though at least one JVM used to be unhappy with native methods
 without corresponding binaries.

 --
 John A. Tamplin

 --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X8CHkCjQK1CvGRxwS9H279BKpnZ%3DjeYwuVgqZtj6JJD3w%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X8CHkCjQK1CvGRxwS9H279BKpnZ%3DjeYwuVgqZtj6JJD3w%40mail.gmail.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
218.248.6165
niloc...@gmail.com

-- 
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/CADcXZMzdu5cz3bjvWYW7%3DvUm%3D%3DfC0b83sg0%3Dbs7j%2BmTNDjFSeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: SafeHtml on the server/vm

[Colin Alworth]

Ah ha! I dropped the ball in my testing, by supporting GWT 2.4+ instead of 
limiting to something more recent and manageable like 2.5.1+. Confirmed, 
SafeHtml etc is in gwt-servlet in recent GWT.

Thanks for the sanity check Thomas.

On Tuesday, June 10, 2014 3:43:48 AM UTC-5, Thomas Broyer wrote:



 On Tuesday, June 10, 2014 12:33:40 AM UTC+2, Colin Alworth wrote:

 Currently SafeHtml co live in gwt-user, though they are for the most 
 part listed in a shared package, implying that a server can use them. 
 However, gwt-user.jar also includes javax packages as well as hibernate, 
 w3c, etc, so can't reasonably be imported to a server which already uses 
 any of those packages (i.e. any servlet container). Is this an oversight in 
 the publicly packaged GWT and is SafeHtml used by teams that package 
 differently, or instead is this package not actually intended for server 
 use, but instead just compile-time tasks where gwt-user is on the classpath 
 like compiling or linking?

 I'm doing some work on a non-servlet server which hasn't so far seen 
 concrete issues with gwt-user.jar, and having SafeHtml seemed to be an easy 
 way to get server generated HTML from code that is shared with the client. 
 This use case *appears* to be implied from the package name, but presently 
 isn't possible for the majority of GWT backends.

 Ideas on why it is the way it is? Thoughts on how to make it available to 
 the server (without giving it yet another jar a la requestfactory-server)? 
 Interest in a contributed SafeHtmlTemplates implementation for JVM?


 SafeHtml *is* in gwt-servlet. In 2.5.1 and earlier it was missing the 
 streamhtmlparser classes, but we've fixed this in 2.6 so it should work now 
 (I must say I haven't tried it though)


-- 
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/7f06ce36-64a7-441a-92eb-421b2889e5ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] user tests fail to compile

[Colin Alworth]

I’m trying to bring https://gwt-review.googlesource.com/#/c/3361/ up to 
date, and after rebasing and fixing a few whitespace nits I tried to run 
the tests by they failed. Concerned that I had broken something I backed 
off to current master, and ran tests again. First I did a clean dist-dev in 
the root directory, then simply compiling user tests, I get a failure:

[colin@modo user (master)]$ ant clean compile.tests
Buildfile: /Users/colin/Documents/idea/gwt/user/build.xml

clean:
   [delete] Deleting directory 
/Users/colin/Documents/idea/gwt/build/out/user

compile.dev.tests:

compiler.standalone:

build.alldeps.jar:

compile:

-filter.props:

build:

compile.emma.if.enabled:

-compile.emma.if.enabled:

compile.tests:
[gwt.javac] Compiling 1 source file to 
/Users/colin/Documents/idea/gwt/build/out/dev/bin-test

compile.emma.if.enabled:

-compile.emma.if.enabled:

compile.tests:
[mkdir] Created dir: 
/Users/colin/Documents/idea/gwt/build/out/user/bin-test
[gwt.javac] Compiling 1514 source files to 
/Users/colin/Documents/idea/gwt/build/out/user/bin-test
[gwt.javac] 
/Users/colin/Documents/idea/gwt/user/test/com/google/gwt/dev/testdata/incrementalbuildsystem/super/com/google/gwt/dev/testdata/incrementalbuildsystem/ImmediateCompileFails.java:19:
 
error: duplicate class: 
com.google.gwt.dev.testdata.incrementalbuildsystem.ImmediateCompileFails
[gwt.javac] public class ImmediateCompileFails {
[gwt.javac]^
[gwt.javac] 
/Users/colin/Documents/idea/gwt/user/test/com/google/web/bindery/requestfactory/apt/RfValidatorTest.java:177:
 
error: cannot find symbol
[gwt.javac] rfValidator.setClientOnly(clientOnly);
[gwt.javac]^
[gwt.javac]   symbol:   method setClientOnly(boolean)
[gwt.javac]   location: variable rfValidator of type RfValidator
[gwt.javac] Note: Some input files use or override a deprecated API.
[gwt.javac] Note: Recompile with -Xlint:deprecation for details.
[gwt.javac] Note: Some input files use unchecked or unsafe operations.
[gwt.javac] Note: Recompile with -Xlint:unchecked for details.
[gwt.javac] 2 errors

BUILD FAILED
/Users/colin/Documents/idea/gwt/user/build.xml:150: Compile failed; see the 
compiler error output for details.

Total time: 15 seconds

Anyone else seeing this, or is it likely a local env issue? I’ve confirmed 
that my tools/ dir is up to date, and I’m not sure what other local 
configuration might be required just to compile tests.

-- 
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/0703af1b-e8bd-420d-9b6d-71dbbd281ce0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: user tests fail to compile

[Colin Alworth]

With some help from Jens Nehlmeier over in ##gwt, it looks like there are 
two distinct issues preventing the build from passing presently The first 
is that the class ImmediateCompileFails does in fact cause problems with 
compiling - the simplest fix was to tell the compile.tests target to leave 
off compiling any super sources:
diff --git a/user/build.xml b/user/build.xml
index 274f4ef..54fc17d 100755
--- a/user/build.xml
+++ b/user/build.xml
@@ -147,7 +147,7 @@
   depends=compile.dev.tests, compile.emma.if.enabled
   unless=compile.tests.complete
 mkdir dir=${javac.junit.out}/
-gwt.javac srcdir=test excludes=com/google/gwt/langtest/** 
destdir=${javac.junit.out}
+gwt.javac srcdir=test 
excludes=com/google/gwt/langtest/**,**/super/** 
destdir=${javac.junit.out}
   classpath
 pathelement location=${javac.out}/
 pathelement location=${gwt.tools.lib}/junit/junit-4.8.2.jar/

The second issue is that the requestfactory-apt.jar in the GWT Tools SVN 
repo appears to be out of date. Doing a dist-dev build and copying the 
newly generated -apt over to my local SVN checkout seems to bring this back 
into working order.

-- 
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/79c83872-2dfc-4272-be9d-9b08845ace22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Dropping IE8 support in useragent-less GWT

[Colin Alworth]

Sounds great, but is there a reason that we're now starting at IE9+ and not 
IE10+, thus giving us typed arrays, web workers, web sockets, etc? I only 
ask because the kind of case where you are giving up User (and Widget, RPC, 
Timer, and other fairly high-level apis) seems to suggest that you might 
not be writing for a browser at all (htmlunit, nashorn, web worker, 
node.js).

Dan definitely has a point that if we're supporting modern browsers for a 
core chunk of functionality, we really shouldn't let 'modern' be 'whatever 
junk still happens to be running rather tha updating'. And besides, I can't 
always be That Guy pushing to keep all versions forever, just because IE8 
is still 11% of North America's browser usage (really: 
http://theie8countdown.com/). 

If we're cutting a browser for being old/bad/whatever in Core, but leaving 
support for it still in User, we should consider carefully why we *aren't* 
cutting deeper.

On Monday, June 30, 2014 2:59:12 PM UTC-5, Goktug Gokdogan wrote:

 We are planning to drop support for IE8 if the application doesn't inherit 
 c.g.gwt.useragent.UserAgent and hence not have browser permutations.

 Nearly all of today's apps inherit User so they will not be affected by 
 this change. In the future more apps will only inherit Core however they 
 shouldn't need to pay price of IE8 support (currently they do because there 
 are no permutations in Core).

 Let me know if you have any concerns.

  - Goktug


-- 
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/45b68163-0d07-4a6c-9932-412232e2f71d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Colin Alworth]

PotentialElement seems to be one of those ghost features that was never
finished, or at least never correctly documented, so might as well be half
done:

EXPERIMENTAL and subject to change. Do not use this in production code.


We've never used it, and I've only encouraged people to stay away from it,
since, well, we aren't supposed to use it in production code.

There are only a handful of places that use PotentialElement - a Composite
has a 'resolve' step, DOM does some resolution as well, UiObject just has a
ton of asserts, and then of course RenderablePanel, EXPERIMENTAL and
subject to change. Do not use this in production code.. Then we get this
tidbit:

This class is a stepping in our transition to the Renderable strategy.
 Eventually this functionality should be merged into {@link HTMLPanel}.


Related classes seem to include IsRenderable:

 This interface is very experimental and in active development, so the
 exact API is likely to change. Very likely. In fact, it will definitely
 change. You've been warned.


Hard to argue with that. The snark is kinda fun, but we should know better
for production code.

  /**
* @see #render(RendearbleStamper, SafeHtmlBuilder)
* TODO(rdcastro): Remove this once UiBinder doesn't rely on it anymore.
*/
   SafeHtml render(RenderableStamper stamper);


 I'm assuming UiBinder still relies on it.

 // TODO(rdcastro): use the render() call that receives the
 SafeHtmlBuilder
 String elementHtml =
 fieldManager.convertFieldToGetter(childFieldWriter.getName()) + .render(
 + fieldManager.convertFieldToGetter(stamper) + );

Yep. Also looks like Composite and RenderablePanel use it too.

From an outsider's perspective, this is not only unfinished code, but
probably abandoned since it has been left unfinished for so long. If it
isn't going to be finished/maintained, it should be deprecated, wait a
version and remove it, otherwise it should be 'completed'. Another option
would be to factor it out to its own jar so that it doesn't appear to be an
integral part of User... but the hooks in DOM.java will make that hard, and
the 'only com.google.gwt code can write uibinder parsers' make this even
tougher.




On Sun, Jul 6, 2014 at 10:25 PM, 'Goktug Gokdogan' via GWT Contributors 
google-web-toolkit-contributors@googlegroups.com wrote:




 On Sun, Jul 6, 2014 at 8:05 PM, Stephen Haberman 
 stephen.haber...@gmail.com wrote:


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


 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.



 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=blah, 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.


  --
 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/CAN%3DyUA2itF_dBO%3D8GpRmRgs0%3D2NfeBY1r%3Dhr2may347Hb9BQHg%40mail.gmail.com
 

Re: [gwt-contrib] Re: Dropping IE8 support in useragent-less GWT

[Colin Alworth]

Sorry for the delay in getting back to you (and to my reviews, got at least 
one up to date now), finally catching up after a few days off.

I guess I was looking for We want to use Object.create in Core in your 
initial email. If we also wanted any/all of the features I had listed (fast 
byte[]/int[]/double[] for everyone? rpc-over-ws? cors?), dropping ie9 from 
Core might have also made sense. 

I'm not actually encouraging cutting IE9 (or 8), esp from User, but if we 
want to move some emulation code off to UserAgent or User, letting go of 
IE9 may make sense.

My email was written from the perspective of huh, Goktug wants to drop IE8 
because it will make *something* easier - won't also dropping IE9 make more 
something even more easier?. With the caveat that all you are interested 
in is Object.create, targeting only IE8 makes sense.

On Tuesday, July 1, 2014 12:02:50 AM UTC-5, Goktug Gokdogan wrote:




 On Mon, Jun 30, 2014 at 8:46 PM, Colin Alworth nilo...@gmail.com 
 javascript: wrote:

 Sounds great, but is there a reason that we're now starting at IE9+ and 
 not IE10+, thus giving us typed arrays, web workers, web sockets, etc? I 
 only ask because the kind of case where you are giving up User (and Widget, 
 RPC, Timer, and other fairly high-level apis) seems to suggest that you 
 might not be writing for a browser at all (htmlunit, nashorn, web worker, 
 node.js).


 A cross-compiled app is a good example that doesn't need User where you 
 can, for example, use closure to develop the UI.

 I specifically pointed IE8 as it is the only supported browser missing 
 Object.create functionality and such apps that just depends on java.emul 
 are paying the price of IE8. On the other hand by just inheriting 
 useragent.UserAgent (not necessarily the User) an app can target older 
 browsers.
  

 Dan definitely has a point that if we're supporting modern browsers for a 
 core chunk of functionality, we really shouldn't let 'modern' be 'whatever 
 junk still happens to be running rather tha updating'. And besides, I can't 
 always be That Guy pushing to keep all versions forever, just because IE8 
 is still 11% of North America's browser usage (really: 
 http://theie8countdown.com/). 

 If we're cutting a browser for being old/bad/whatever in Core, but 
 leaving support for it still in User, we should consider carefully why we 
 *aren't* cutting deeper.

  
 Can you be more specific?
  


 On Monday, June 30, 2014 2:59:12 PM UTC-5, Goktug Gokdogan wrote:

 We are planning to drop support for IE8 if the application doesn't 
 inherit c.g.gwt.useragent.UserAgent and hence not have browser permutations.

 Nearly all of today's apps inherit User so they will not be affected by 
 this change. In the future more apps will only inherit Core however they 
 shouldn't need to pay price of IE8 support (currently they do because there 
 are no permutations in Core).

 Let me know if you have any concerns.

  - Goktug

  -- 
 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 
 javascript:.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/45b68163-0d07-4a6c-9932-412232e2f71d%40googlegroups.com
  
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/45b68163-0d07-4a6c-9932-412232e2f71d%40googlegroups.com?utm_medium=emailutm_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/8e78df45-4d71-4dcf-9fea-52d32fc58d65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Dropping IE8 support in useragent-less GWT

[Colin Alworth]

I think Alain's use case is a legit one, and the SmartGWT product probably
also lives in that world to an extent - let the user write Java that mostly
interacts with JS libraries, and let them worry about which browser is
running, but compile the code to run anywhere. I can't speak to their
'older browser' need though - Alain, what do you guys target?


On Thu, Jul 17, 2014 at 6:52 PM, 'Brian Slesinsky' via GWT Contributors 
google-web-toolkit-contributors@googlegroups.com wrote:

 It would make sense in principle but we don't know anyone who wants to
 target older browsers without also using permutations.

 On Tue, Jul 15, 2014 at 3:55 AM, Jens jens.nehlme...@gmail.com wrote:

 I believe Google builds applications that use Elemental and/or JsInterop,
 so they don't use c.g.g.dom.DOM or any other thing that inherits UserAgent.
 Goktug also pointed out earlier in this thread cross-compiled apps
 where the UI is built with Closure Library. I suspect this might be the
 case of Google Drive (Spreadsheets) where GWT is only used to compile to JS
 those bits of Java that are shared with the server, Android app and iOS app
 (through J2ObjC); from what I understood, in Spreadsheets that would be the
 code necessary to parse and evaluate formulas.


 Thanks for the examples. Such cross compiled apps probably doesn't have
 the concept of permutations but they maybe also want to support older
 browsers. Wouldn't it make sense then to have something like Core.gwt.xml
 which is strictly modern, and CoreWithLegacySupport.gwt.xml which inherits
 Core and introduces runtime feature checks here and there? That way such
 apps don't have to pull in UserAgent at all and its probably more straight
 forward than saying: If you need legacy support then inherit core,
 useragent and possibly collapse all properties if you want a single
 permutation.
 Also GWT would have the control how it provides legacy support and far in
 the future if GWT only has a modern and a legacy permutation then Core
 could provide the modern permutation while CoreWithLegacySupport introduces
 the legacy permutation and UserAgent maps all the user agents to modern or
 legacy.

 -- 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/74f12c72-4e7e-4167-b60e-564448d5d918%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/74f12c72-4e7e-4167-b60e-564448d5d918%40googlegroups.com?utm_medium=emailutm_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/CA%2B%2BRBT_EmOdm%2BCNSSom9-RnBdoio74ure2aELE49kRExgiMnXw%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT_EmOdm%2BCNSSom9-RnBdoio74ure2aELE49kRExgiMnXw%40mail.gmail.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
218.248.6165
niloc...@gmail.com

-- 
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/CADcXZMwudpoUF9nQdaxaHKDanthq470nioODFYCaUZAbf%3Dnt%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Snapshot and maven

[Colin Alworth]

For what its worth, we use a slightly different snapshot url:
https://oss.sonatype.org/content/repositories/google-snapshots/. This
appears to only contain snapshots instead of releases and snapshots.

The /google/ url for whatever reason has a newer md5 and sha1 for the
maven-metadata.xml file, but the dates/sizes on everything else seem to be
consistent.


On Thu, Aug 21, 2014 at 9:33 AM, Julien Dramaix julien.dram...@gmail.com
wrote:

 indeed mvn clean install -U does the trick...

 Thanks Manolo


 On Thu, Aug 21, 2014 at 4:24 PM, Manuel Carrasco Moñino man...@apache.org
  wrote:

 The repo structure is ok, your maven should download the metadata file
 [1] which has a reference to the last snapshot index then it should
 continue downloading the pom [2] and jar [3] files.

 Maybe something wrong in your local repo cache, try to force updating
 snapshots running:
  mvn -U clean package
 or removing
  ~/.m2/repository/com/google/gwt/gwt-user/2.7.0-SNAPSHOT

 - Manolo

 [1]
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-user/2.7.0-SNAPSHOT/maven-metadata.xml
 [2]
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-user/2.7.0-SNAPSHOT/gwt-user-2.7.0-20140820.063656-32.pom
 [3]
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-user/2.7.0-SNAPSHOT/gwt-user-2.7.0-20140820.063656-32.jar


 On Thu, Aug 21, 2014 at 3:24 PM, Julien Dramaix julien.dram...@gmail.com
  wrote:

 Dear GWT lovers,

 I'm trying to test the last GWT snapshot but I cannot configure maven to
 use it.

 I've added the following repo:

 repositories
 repository
 idgwt-sonatype-snapshots/id
 urlhttps://oss.sonatype.org/content/repositories/google/url
 snapshotsenabledtrue/enabled/snapshots
 releasesenabledfalse/enabled/releases
 /repository
 /repositories

 and use the following version: 2.7.0-SNAPSHOT

 But Maven is not able to resolve dependencies:

 Downloading:
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-user/2.7.0-SNAPSHOT/gwt-user-2.7.0-SNAPSHOT.pom
 [WARNING] The POM for com.google.gwt:gwt-user:jar:2.7.0-SNAPSHOT is
 missing, no dependency information available
 Downloading:
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-dev/2.7.0-SNAPSHOT/gwt-dev-2.7.0-SNAPSHOT.pom
 [WARNING] The POM for com.google.gwt:gwt-dev:jar:2.7.0-SNAPSHOT is
 missing, no dependency information available
 Downloading:
 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-servlet/2.7.0-SNAPSHOT/gwt-servlet-2.7.0-SNAPSHOT.pom
 [WARNING] The POM for com.google.gwt:gwt-servlet:jar:2.7.0-SNAPSHOT is
 missing, no dependency information available

 I've looked into the directories

 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-user/2.7.0-SNAPSHOT/

 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-dev/2.7.0-SNAPSHOT/

 https://oss.sonatype.org/content/repositories/google/com/google/gwt/gwt-servlet/2.7.0-SNAPSHOT/

 and indeed the pom files are missing.

 Am I missing something ?

 Julien

 --
 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/CABb_3%3D4eduxbj5Z6FiVtw1H%2Bj%2BHhbzT6h1274Pq9VSJXF4wW0Q%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4eduxbj5Z6FiVtw1H%2Bj%2BHhbzT6h1274Pq9VSJXF4wW0Q%40mail.gmail.com?utm_medium=emailutm_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/CAM28XAveCmt9UnaQYESVOd9FYhKD-0tHYq%3D8fxxny_4sk3gm1Q%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAveCmt9UnaQYESVOd9FYhKD-0tHYq%3D8fxxny_4sk3gm1Q%40mail.gmail.com?utm_medium=emailutm_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/CABb_3%3D58%2BaAWf3C3A9XLt3%3DzxXDzzDkpooUYXEnR4DO7yqJ%2B%2Bg%40mail.gmail.com
 

[gwt-contrib] IE11 property, if not permutation

[Colin Alworth]

As I'm sure everyone is aware, IE11 is making the navigator.useragent 
property significantly more useless than it already was, by having IE11 
identify as 'Trident' rather than 'MSIE', and adding 'iPhone', 'Webkit', 
'Android' and a few other obviously garbage strings. 

Check out 
http://msdn.microsoft.com/en-us/library/ie/hh869301%28v=vs.85%29.aspx - its 
hard to believe, but its all spelled out easily, so that you can identify 
which device you might be running on by deciphering this simple table. /s.

By following a link at the bottom of the page to a document entitled 
Detecting Internet Explorer More Effectively at 
http://msdn.microsoft.com/en-us/library/ie/ms537509%28v=vs.85%29.aspx, 
anything newer IE8 considered 'recent'. This document is also marked as no 
longer being maintained, so I'm curious as to why it was linked from the 
above article. Other links are broken too (try clicking on 
'navigator.userAgent'), so I'm not sure if this is actually meant to be 
satire, or some kind of meta-joke about how hard it is to correctly develop 
for IE. In any case...

IE 11 is worlds better than earlier browsers (8, 9 still is at 27% 
worldwide, 34% in North America according to theie8countdown.com and 
theie9countdown.com), but it is still all kinds of crazy. Examples we've 
run into recently:

Scrollwheel events in gecko are wired up to use event.detail to find out 
how far the user scrolled. Since IE11 looks like Gecko (on the desktop...), 
you incorrectly get that instead of the code in DOMImplTrident or 
DOMImplStandardBase which uses (Math.round(-evt.wheelDelta / 40) || 0) 
instead. This is filed in GWT as 
https://code.google.com/p/google-web-toolkit/issues/detail?id=8476

Focus. So many focus issues, but for the most part we limp along by making 
everything else play IE's game. In one particular case, an element was 
focused, hidden, and shown again, and for IE (which is to say user.agent = 
ie8, ie9, ie10), we could make it work by rebinding to avoid letting 
anything else be focused, since other browsers were behaving as expected. 
Alas, IE11 thinks it's other browsers, so the only way to make it work is 
to do a silly runtime check...

...Or, add a permutation for IE11.

In the past we've explored extend-property'ing the user.agent values, but 
this either makes it impossible to cleanup get along with newer GWT 
versions, or breaks CssResource code that misses a rule or two here and 
there, or causes excessive logspam from the fallback property. Instead, in 
GXT we ended up adding our own user.agent-like property, and then using 
conditional properties and soft permutations to map back to user.agent 
without causing extra permutations unless the developer wants them (see 
http://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties and 
http://code.google.com/p/google-web-toolkit/wiki/SoftPermutations if you 
haven't already). In the past, this worked great for us to split out ie6/7 
for our own rules, and continues to work beautifully for telling the 
difference between Safari and Chrome and Opera, which all show up as 
'safari' in GWT.

This won't work for IE11, for a few reasons:
a) IE11 sometimes shows up as 'safari', and sometimes as 'gecko1_8', so 
conditional properties will get a bit hairy(er) than usual.
b) At some point, we've been expecting that the level of frustration with 
IE11 in the general community would be high enough to warrant a new value 
or slapping it on to an existing one, adding either 'ie10' or 'ie11' to the 
list above.

So, while this has gotten much longer than I had planned, I hope I've made 
a case for this. I'd like to propose in GWT 2.7 (and will write up the 
patch) that we add a 'ie11' value to user.agent, and detect it by checking 
for the presence of rv:11 and trident in the useragent string. I would be 
okay with forcing this to map to gecko1_8 in any IE-specific rebind rule 
and revisit at a later date (since that is what we are effectively doing 
today). Except of course for DOMImplMozilla, which is clearly broken with 
IE11.

Thoughts? Additional snark? Other IE11 bugs that will magically be fixed 
when this is complete?

-- 
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/232f5fbb-0134-4ea9-9844-13dad666f41e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: -src in DevMode EntryPoint

[Colin Alworth]

Its possible that we can get away without an explicit way to add this (like 
classic Dev Mode has done so far), but -src makes multi-project development 
so much saner. No longer do you need to depend on your IDE to do the Right 
Thing (i.e. use *that* project as a jar from local maven repo, but *that* 
one over there should be raw sources, since the one former has generated 
content but the latter is being edited constantly). Leaving this out puts 
the onus on the IDE tooling to get it right every time, or provide an 
alternate mechanism - you can get pretty close with the (often wrong but at 
least easy to customize) Eclipse Run Configuration wiring, but on the other 
hand the (totally un-customizable, but at least right 80% of the time) IDEA 
Run Configurations that are shipped with Ultimate have to be right out of 
the box, or you are just stuck (as is true for 12, 13, and the 14 EAP). I 
can't speak for Netbeans (though I've seen a recent resurgence of GWT users 
making use of it!).

Is there a reason that CodeServer has this feature but DevMode doesn't? 
Should DevMode have had it all along, or was this just a hack in CodeServer 
that should be phased out?

-- 
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/fc562a17-0f4c-4573-9f18-9b5ea13ad723%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Recompile issue coming up on sdm start, gwt 2.7.0-snapshot

[Colin Alworth]

The 'test runner' in this case is just the name of a regular module file, 
which happens to be used for running lots of tests, most of which look like 
EntryPoints. Nothing too magic going on here, and I've gotten this error by 
running modules for more 'normal' gwt apps as well, typically when I stop 
SDM, restart it, and then refresh the browser or click Compile without 
first using the SDM off bookmarklet.


 I'm not completely aware of your configuration but... it appears that 
 you're using incremental compiles from a test runner, and this test runner 
 isn't restricting the permutations to just 1. And that is being caught by 
 an assertion.

 You can fix this by adding some set-property tags to your test .gwt.xml 
 files.

 I hadn't thought of this use case, so I'm not sure if it's fair to tell 
 people to restrict their permutation or if we need to find a better way. 
 Thoughts?


Does this mean that we expect all projects to already be confined to one 
permutation, either via set-property or collapse-all-permutations? Is there 
no way to achieve that synthetically?

Further, does this mean that one cannot test in multiple browsers 
simultaneously, for example re-compiling in FF until some behavior is 
satisfactory, then moving to Chrome (at least without stopping and 
restarting SDM)? 

-- 
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/cdf99604-44c9-41b5-9cca-4f45227a3c89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: [2.7.0-SNAPSHOT] Bug in compilation with pretty mode

[Colin Alworth]

I also can reproduce this - when style is set to PRETTY, 4 of the 17
permutations starts off with the PRETTY setup code (from the linker?), then
moves on to have all obfuscated (and sorted, etc) JS from the compilation
process:

var $wnd = $wnd || window.parent;
var __gwtModuleFunction = $wnd.explorer;
var $sendStats = __gwtModuleFunction.__sendStats;
$sendStats('moduleStartup', 'moduleEvalStart');
var $gwt_version = 2.7.0-SNAPSHOT;
var $strongName = '1C1FC666B8D8D4A5634A1EDA3B51C36D';
var $gwt = {};
var $doc = $wnd.document;
var $moduleName, $moduleBase;
function __gwtStartLoadingFragment(frag) {
var fragFile = 'deferredjs/' + $strongName + '/' + frag + '.cache.js';
return __gwtModuleFunction.__startLoadingFragment(fragFile);
}
function __gwtInstallCode(code) {return
__gwtModuleFunction.__installRunAsyncCode(code);}
function __gwt_isKnownPropertyValue(propName, propValue) {
return __gwtModuleFunction.__gwt_isKnownPropertyValue(propName, propValue);
}
function __gwt_getMetaProperty(name) {
return __gwtModuleFunction.__gwt_getMetaProperty(name);
}
var $stats = $wnd.__gwtStatsEvent ? function(a) {return
$wnd.__gwtStatsEvent(a);} : null;
var $sessionId = $wnd.__gwtStatsSessionId ? $wnd.__gwtStatsSessionId : null;
function Qg(){}
function lr(){}
function fu(){}
function nu(){}
function Cu(){}...

file names, sizes:
23908346   0D4B0A8AEFAF8328F37ABFBECEB765AC.cache.js
23900780   102B4372CC1E48D4E25EF20E66AD58DC.cache.js
23900946   10F8674F5E5DA2F77E606EDC3EF15643.cache.js
23900106   19BE3EA887194EC666A99E7BF57466C9.cache.js
3179517   1C1FC666B8D8D4A5634A1EDA3B51C36D.cache.js
23900433   467DE13BCB709965841DEF1F6BFD4785.cache.js
23917825   52AE506F1022BBF96CD25D74BD321C21.cache.js
23907954   6D952B9399698247258186190F8E0C38.cache.js
23900411   BB376480C0E3F616DF9CC28CCF948D0B.cache.js
23900195   C603EC38E0BF3A20A865927C32E7F122.cache.js
3143293   C868922D674E3536B6E83AF9DC005B4C.cache.js
23900252   CFB5CC0D39830766B7CCC22F07FBDD98.cache.js
3129165   D60063CBD8120FF39347C97C3C38B770.cache.js
3225082   DDCA4900448CB91C57415D5B87D0F4A8.cache.js
2397   E11B2F6059BED303323AE4942F78E157.cache.js
23910979   F8003A30DB63AC175E0F7C5D0DF1EEA5.cache.js
23900163   FD1978D213B1B1592E0DC19E4F7FC46B.cache.js

A quick read of the compilation-mappings doesn't show a lot in common as to
why this might be happening - D60063 is theme=neptune, user.agent=ie9 while
DDCA49 is theme=gray, user.agent=safari, 1C1FC is theme=gray,
user.agent=gecko1_8, and C86892 is theme=gray, user.agent=ie8.

Compiled from gwt-maven-plugin 2.7.0-SNAPSHOT as well.

On Wed, Oct 1, 2014 at 4:49 PM, Manuel Carrasco Moñino man...@apache.org
wrote:

 Roberto, in my case this is the command line:

 /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/bin/java
 -Xmx512m -classpath . . .  -Dgwt.persistentunitcachedir= target
 com.google.gwt.dev.Compiler -logLevel INFO -style PRETTY -war
 target/v-demo-1.0-SNAPSHOT -localWorkers 8 -draftCompile -XnocheckCasts
 -compileReport -XfragmentCount -1 -sourceLevel 1.7 -XjsInteropMode NONE
 -extra target/extra -gen v-demo/target/.generated
 com.vaadin.prototype.wc.gwt.Demo

 I'm compiling with maven using gwt-maven-2.7-SNAPSHOT and trunk GWT.





 On Wed, Oct 1, 2014 at 11:44 PM, Manuel Carrasco Moñino man...@apache.org
  wrote:

 I could verify the issue.
 A clue, It seems that the last emitted permutation is the only one
 un-obfuscated.

 As a workaround you can collapse-all-properties, and the result is PRETTY

 - Manolo

 On Wed, Oct 1, 2014 at 11:27 PM, Julien Dramaix julien.dram...@gmail.com
  wrote:

 Am I the only one to have this problem ?

 On Fri, Sep 26, 2014 at 11:46 PM, Julien Dramaix 
 julien.dram...@gmail.com wrote:

 Dear GWT lovers,

 I've just tried to compile several projects with the last snapshot of
 GWT 2.7.0 using the PRETTY mode flag and several permutations. I noticed
 that only one js file (corresponding to one permutation) is emitted with
 non obfuscated javascript. The other files for each other permutation
 contains obfuscated javascript.

 I've tested with GWT 2.6.1 and everything works as expected: all the
 files contain only non-obfuscated javascript.

 Julien


  --
 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/CABb_3%3D4hPmdnqisA62R387c%3D77bVNboxB%3DW9R3%3DBgTFYTtvhNw%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4hPmdnqisA62R387c%3D77bVNboxB%3DW9R3%3DBgTFYTtvhNw%40mail.gmail.com?utm_medium=emailutm_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 

[gwt-contrib] Spam logs: Could not find an exact match rule. Using 'closest' rule

[Colin Alworth]

It looks like changes to a few rebind rules are generating some new logspam 
when any GWT app compiles. Specifically, I'm seeing FocusImpl and 
LayoutImpl, though its possible there are others I haven't seen yet. From 
the dynatable example we can see the FocusImpl spam:
gwtc:
 [java] Compiling module com.google.gwt.sample.dynatable.DynaTable
 [java]Computing all possible rebind results for 
'com.google.gwt.user.client.ui.impl.FocusImpl'
 [java]   Rebinding com.google.gwt.user.client.ui.impl.FocusImpl
* [java]  Could not find an exact match rule. Using 'closest' 
rule replace-with 
class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/ based on fall 
back values. You may need to implement a specific binding in case the fall 
back behavior does not replace the missing binding*
 [java]Compiling 5 permutations
 [java]   Compiling permutation 0...
 [java]   Process output
 [java]  Compiling
 [java] Compiling permutation 1...
 [java]   Compiling permutation 2...
 [java]   Compiling permutation 3...


First, the rules themselves:
  !-- Firefox uses a hidden input to set accesskeys --
  replace-with 
class=com.google.gwt.user.client.ui.impl.FocusImplStandard
when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
when-property-is name=user.agent value=gecko1_8/
  /replace-with

  !-- Safari uses a hidden input to set accesskeys and --
  !-- fires focus/blur after a timeout --
  replace-with class=com.google.gwt.user.client.ui.impl.FocusImplSafari
when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
when-property-is name=user.agent value=safari/
  /replace-with

  !-- IE's implementation traps exceptions on invalid setFocus() --
  replace-with class=com.google.gwt.user.client.ui.impl.FocusImplIE6
when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
all
  any
when-property-is name=user.agent value=ie6/
when-property-is name=user.agent value=ie8/
  /any
  none
when-property-is name=user.agent value=ie9/
  /none
/all
  /replace-with

No express binding of FocusImpl to itself, or to Standard (interestingly 
Standard really seems to mean Gecko, at least according to that comment, 
calling out a FF specific issue). I can't comment much on that just yet, 
though I might make a suggestion later. 

This code is as a result of https://gwt-review.googlesource.com/#/c/5055/ 
(or 
https://gwt.googlesource.com/gwt/+/040b3e4392186e48689a6fc1f19cdf294f2b5651 
if you like), ostensibly to make IE9+ use FocusImpl instead of FocusImplIE6 
(or Standard, for example).

[java]Computing all possible rebind results for 
'com.google.gwt.user.client.ui.impl.FocusImpl'

...

[java]  Found better fallback match for replace-with 
class='com.google.gwt.user.client.ui.impl.FormPanelImpl'/
[java]  Checking rule replace-with 
class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/
[java] Checking if all subconditions are true (all)
[java]when-type-is 
class='com.google.gwt.user.client.ui.impl.FocusImpl'/
[java]   Yes, the requested type was an exact match
[java]Checking if all subconditions are true (all)
[java]   Checking if any subcondition is true (any)
[java]  when-property-is name='user.agent' 
value='ie8'/
[java] Property value is '*ie9*'
[java] Property value 'ie8' is the fallback of 
'[[ie9]]'
[java] No, the value did not match
[java]  No: All subconditions were false
[java]   No: One or more subconditions was false
[java]No: One or more subconditions was false
[java]  Rule did not match
[java]  Found better fallback match for replace-with 
class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/
[java]  Checking rule replace-with 
class='com.google.gwt.user.client.ui.impl.FocusImplSafari'/
[java] Checking if all subconditions are true (all)
[java]when-type-is 
class='com.google.gwt.user.client.ui.impl.FocusImpl'/
[java]   Yes, the requested type was an exact match
[java]when-property-is name='user.agent' value='safari'/
[java]   Property value is 'ie9'
[java]   No, the value did not match
[java]No: One or more subconditions was false
[java]  Rule did not match
[java]  Checking rule replace-with 
class='com.google.gwt.user.client.ui.impl.FocusImplStandard'/
[java] Checking if all subconditions are true (all)
[java]when-type-is 
class='com.google.gwt.user.client.ui.impl.FocusImpl'/
[java]   Yes, the requested type was an exact match
[java]when-property-is name='user.agent' 

Re: [gwt-contrib] Spam logs: Could not find an exact match rule. Using 'closest' rule

[Colin Alworth]

Sorry Goktug, I don't follow - what should the comment indicate? In the old
code, IE9 was expressly bound to the IE6 imp, in the new (to be reverted)
code, it was expressly *not* bound to the IE6 impl, but it was the closest
fallback anyway.

Are you suggesting that the comment should point out that IE9 probably
shouldn't be bound in that way (though it works, and may not work if
differently bound)?

Thanks for any clarification,
Colin

On Thu, Oct 2, 2014 at 11:05 AM, 'Goktug Gokdogan' via GWT Contributors 
google-web-toolkit-contributors@googlegroups.com wrote:

 Reverting the binding sounds good to me. Please add a comment to the
 binding; it might probably be bound to something else but not tested.

 On Wed, Oct 1, 2014 at 9:39 PM, Colin Alworth niloc...@gmail.com wrote:

 It looks like changes to a few rebind rules are generating some new
 logspam when any GWT app compiles. Specifically, I'm seeing FocusImpl and
 LayoutImpl, though its possible there are others I haven't seen yet. From
 the dynatable example we can see the FocusImpl spam:
 gwtc:
  [java] Compiling module com.google.gwt.sample.dynatable.DynaTable
  [java]Computing all possible rebind results for
 'com.google.gwt.user.client.ui.impl.FocusImpl'
  [java]   Rebinding com.google.gwt.user.client.ui.impl.FocusImpl
 * [java]  Could not find an exact match rule. Using 'closest'
 rule replace-with
 class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/ based on fall
 back values. You may need to implement a specific binding in case the fall
 back behavior does not replace the missing binding*
  [java]Compiling 5 permutations
  [java]   Compiling permutation 0...
  [java]   Process output
  [java]  Compiling
  [java] Compiling permutation 1...
  [java]   Compiling permutation 2...
  [java]   Compiling permutation 3...


 First, the rules themselves:
   !-- Firefox uses a hidden input to set accesskeys --
   replace-with
 class=com.google.gwt.user.client.ui.impl.FocusImplStandard
 when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
 when-property-is name=user.agent value=gecko1_8/
   /replace-with

   !-- Safari uses a hidden input to set accesskeys and --
   !-- fires focus/blur after a timeout --
   replace-with
 class=com.google.gwt.user.client.ui.impl.FocusImplSafari
 when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
 when-property-is name=user.agent value=safari/
   /replace-with

   !-- IE's implementation traps exceptions on invalid setFocus() --
   replace-with class=com.google.gwt.user.client.ui.impl.FocusImplIE6
 when-type-is class=com.google.gwt.user.client.ui.impl.FocusImpl/
 all
   any
 when-property-is name=user.agent value=ie6/
 when-property-is name=user.agent value=ie8/
   /any
   none
 when-property-is name=user.agent value=ie9/
   /none
 /all
   /replace-with

 No express binding of FocusImpl to itself, or to Standard (interestingly
 Standard really seems to mean Gecko, at least according to that comment,
 calling out a FF specific issue). I can't comment much on that just yet,
 though I might make a suggestion later.

 This code is as a result of https://gwt-review.googlesource.com/#/c/5055/
 (or
 https://gwt.googlesource.com/gwt/+/040b3e4392186e48689a6fc1f19cdf294f2b5651
 if you like), ostensibly to make IE9+ use FocusImpl instead of FocusImplIE6
 (or Standard, for example).

 [java]Computing all possible rebind results for
 'com.google.gwt.user.client.ui.impl.FocusImpl'

 ...

 [java]  Found better fallback match for replace-with
 class='com.google.gwt.user.client.ui.impl.FormPanelImpl'/
 [java]  Checking rule replace-with
 class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/
 [java] Checking if all subconditions are true (all)
 [java]when-type-is
 class='com.google.gwt.user.client.ui.impl.FocusImpl'/
 [java]   Yes, the requested type was an exact match
 [java]Checking if all subconditions are true (all)
 [java]   Checking if any subcondition is true (any)
 [java]  when-property-is name='user.agent'
 value='ie8'/
 [java] Property value is '*ie9*'
 [java] Property value 'ie8' is the fallback of
 '[[ie9]]'
 [java] No, the value did not match
 [java]  No: All subconditions were false
 [java]   No: One or more subconditions was false
 [java]No: One or more subconditions was false
 [java]  Rule did not match
 [java]  Found better fallback match for replace-with
 class='com.google.gwt.user.client.ui.impl.FocusImplIE6'/
 [java]  Checking rule replace-with
 class='com.google.gwt.user.client.ui.impl.FocusImplSafari'/
 [java] Checking if all

Re: [gwt-contrib] GWT 2.7 release plan

[Colin Alworth]

https://code.google.com/p/google-web-toolkit/issues/detail?id=8716 is still 
open (and is a regression over GWT 2.6 and previous). Is this a reasonable 
item to get fixed?

On Wednesday, October 1, 2014 2:23:43 PM UTC-5, Brian Slesinsky wrote:

 - Make sure sample apps work with DevMode -superdevmode
 - I think we're waiting on a patch to CLDR 25 


 On Wed, Oct 1, 2014 at 12:15 PM, 'Daniel Kurka' via GWT Contributors  
 wrote:

 Hi all,

 we just settled on a GWT 2.7 release plan:

  - We *code freeze* on *October 7th* and branch for GWT 2.7.
  - As soon as we have the *remaining patches submitted*, we put out a 
 beta1 build, this should be no later than *October 7th.*
  - Putting out a *beta1 externally* allows us to collect feedback on the 
 new super dev mode integration externally as well.
  - We are going to *flip incremental to default* tomorrow and *wait for 
 1-2 weeks* for google internal feedback, if there is no serious issues 
 we are going to *put out RC1*
  - GWT 2.7 will still be compatible with Java 6.

 Patches / Fixes that need to go in:
  - Recompile on reload: https://gwt-review.googlesource.com/#/c/9323/
  (dankurka)
  - Sending the wrong permutation to the client in SDM, if no files have 
 changed (dankurka).
  - Investigate why some people are seeing errors with incremental  not 
 restricting to one permutation (dankurka).
  - Public directories are not copied o the war directory when using SDM 
 (skybrian).
  - Restore Java 6 compatibility (skybrian).
  - Document limitations of JsonUtils.safeEval and discourage usage 
 (goktug) (promote Json.parse)

 Patches that are nice to have:
  - Improve exception logging in SDM (goktug).

 *If you have any outstanding patches that you thing need to go into GWT 
 2.7, please bring them to our attention, by replying to this thread or 
 adding me as a reviewer on Gerrit and setting the topic to GWT2.7.*

 -Daniel

  


-- 
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/0b3edc35-cf55-4096-837c-fb4bcbbc4d32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Removal of IE6/7 specific code from the code base

[Colin Alworth]

I've just submitted a shallow removal of IE6 specific code in 
https://gwt-review.googlesource.com/#/c/9513/ - this patch starts with all 
.gwt.xml files that mention the user.agent value ie6 and removes those 
property checks, along with any classes *only* referenced from those rebind 
rules. Far from a complete job of what remains, but takes another swipe at 
removing old dead junk.

-- 
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/9c02912b-fd7f-4594-9287-061d166ead8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

[Colin Alworth]

Sorry for the thread necromancy, but aside from 
https://groups.google.com/d/topic/google-web-toolkit-contributors/90PSQ7wKHtI/discussion
 
this was the only relevant existing conversation I could find on the topic. 

In GWT 2.6 user.client.Element was finally deprecated, though done in a way 
to avoid any backward compatibility breakage. For example, UiObject now has 
two setElement methods, one for user.client.Element and another for 
dom.client.Element. 

However, UiObject.getElement still returns user.client.Element, as do a few 
other methods, as of master when I write these words. I'm submitting a 
patch that first amends UiObject.getElement and 
SimplePanel.getContainerElement to return dom.client.Element. My thinking 
is that we need an API-breaking release which still holds 
user.client.Element, but doesn't actually use them, allowing downstream 
libraries or projects to be compatible with more than one release.

The alternatives as I'm currently seeing them, after deprecating in an 
initial release
a) force a big jump, removing all traces of user.client.Element at once, 
meaning a library that is compatible with 2.x may not be compatible with 
2.x+1. Not ideal (as a downstream library author, who doesn't want to force 
users to only support a single version of GWT at a time, as bugs do happen, 
even in GWT), but certainly easier to maintain.
b) do this two-step dance, making API breakage twice, but with the goal of 
shifting to the new API within GWT itself (and encouraging it downstream), 
then a version later removing the old one. Any library/project compatible 
with N is then compatible with N+1 in as many cases as possible.

If we like b), I'd leave any static DOM methods, but dig in further and hit 
any overridable methods. If a) is preferred, we can just cut to the chase 
and remove user.client.Element entirely today.

Initial patch (subject to later discussion) is at 
https://gwt-review.googlesource.com/9514.

On Monday, December 21, 2009 5:10:47 PM UTC-6, Thomas Broyer wrote:

 Hi Googlers,

 How about deprecating c.g.g.user.client.Element and
 c.g.g.user.client.DOM altogether and port all existing widgets to
 c.g.g.dom.client.*?
 A first pass, say in 2.1, wouldn't break public APIs, still using
 c.g.g.user.client.Element as public and protected methods' return type
 and fields; only the second pass (in 2.2 or even 2.3) would completely
 get rid of c.g.g.user.client.Element.

 As for c.g.g.user.client.DOM, there are a few methods that have no
 equivalent in c.g.g.dom.client.* (getChild/insertChild/etc. for
 instance, which deal with child elements, not child nodes). Those
 would have to either be moved to c.g.g.dom.client.Element or removed
 altogether in the end (which means deprecated with replacement API
 vs. just deprecated in the mean time).
 Most widgets have complete control over their DOM, so changing from
 child element to child node shouldn't break them.

 I volunteer to providing patches (probably one widget at a time), but
 I'd like to know upfront if I'd waste my time or if it'd have a chance
 of being accepted.



-- 
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/04e16fb1-6fd5-456f-b421-771c6761da86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

[Colin Alworth]

Not quite. Anything that continues to return user.client.Element can only 
be overridden to return user.client.Element or a subclass.

To pick a case at random (ahem, GXT), say you want to override 
UiObject.getElement for whatever reason. GWT 2.6-2.7 means that we can't 
change that return type, since you can't override methods and return a 
superclass (or a subclass of the superclass).

If we assume that no downstream code ever subclasses and overrides any 
method that returns user.client.Element, yes, we can cut over cleanly in 
the future, you are right. But GXT notwithstanding, the SimplePanel class 
is meant to be subclassed and have getContainerElement() return a different 
container for the child - I'd be very surprised if there is no downstream 
code that does this somewhere.

Example: 
FooLib v1 is compatible with GWT 2.5, when user.client.Element was not 
deprecated. It has a SimplePanel subclass called HeaderPanel, which 
overrides getContainerElement() to return a specific child element.
GWT 2.6 deprecates user.client.Element, so FooLib v1 is compatible with 
both GWT 2.5 and 2.6. As it should be.
To catch up, FooLib v2 would like to remove usages of user.client.Element, 
but since SimplePanel.getContainerElement() still requires that return 
type, it can't. The best they can do is find all cases of 
user.client.Element and cast up to dom.client.Element from the return value 
of methods like getElement() and getContainerElement().
Lets say GWT 2.7 cuts all user.client.Element. Now FooLib v1 and v2 are 
*incompatible* with GWT 2.7, even though they compatible with 2.6, and v2 
was writing the cleanest possible code (returning a deprecated type). Not 
ideal.
Or, with the patch I'm offering, GWT 2.7 keeps user.client.Element, but now 
has SimplePanel.getContainerElement return a supertype of 
user.client.Element, so subclasses are free to *further restrict* the 
return type (like v1/v2 is doing), or use the dom.client.Element. The v1 
version will probably have issues if it uses the returned value from 
getContainerElement() as a user.client.Element, but v2 corrected that, so 
v2 now is compatible with GWT 2.6 and GWT 2.7. Win.
Next, GWT 2.8 or 3.0 drops all remaining traces of user.client.Element, and 
since v2 didn't use it any more, in this regard v2 is also compatible with 
GWT 2.8/3.0. Of course, this won't happen, some other API detail will 
break, I promise (Splittable.removeReified, removed logger classes breaking 
.gwt.xml, required resource tags causing warnings, etc).

On Wednesday, October 8, 2014 4:15:10 AM UTC-5, Thomas Broyer wrote:


 On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote:

 Sorry for the thread necromancy, but aside from 
 https://groups.google.com/d/topic/google-web-toolkit-contributors/90PSQ7wKHtI/discussion
  
 this was the only relevant existing conversation I could find on the topic. 

 In GWT 2.6 user.client.Element was finally deprecated, though done in a 
 way to avoid any backward compatibility breakage. For example, UiObject now 
 has two setElement methods, one for user.client.Element and another for 
 dom.client.Element. 

 However, UiObject.getElement still returns user.client.Element, as do a 
 few other methods, as of master when I write these words. I'm submitting a 
 patch that first amends UiObject.getElement and 
 SimplePanel.getContainerElement to return dom.client.Element. My thinking 
 is that we need an API-breaking release which still holds 
 user.client.Element, but doesn't actually use them, allowing downstream 
 libraries or projects to be compatible with more than one release.

 The alternatives as I'm currently seeing them, after deprecating in an 
 initial release
 a) force a big jump, removing all traces of user.client.Element at once, 
 meaning a library that is compatible with 2.x may not be compatible with 
 2.x+1. Not ideal (as a downstream library author, who doesn't want to force 
 users to only support a single version of GWT at a time, as bugs do happen, 
 even in GWT), but certainly easier to maintain.
 b) do this two-step dance, making API breakage twice, but with the goal 
 of shifting to the new API within GWT itself (and encouraging it 
 downstream), then a version later removing the old one. Any library/project 
 compatible with N is then compatible with N+1 in as many cases as possible.

 If we like b), I'd leave any static DOM methods, but dig in further and 
 hit any overridable methods. If a) is preferred, we can just cut to the 
 chase and remove user.client.Element entirely today.


 If we did things right in 2.6 (and I have no reason to think otherwise), 
 user code (anything not from GWT proper, including applications and 
 downstream libraries) can be written without any reference to 
 user.client.Element, using dom.client.Element exclusively and never calling 
 any deprecated method (related to Element).
 So after a grace period where downstream libraries use the same 
 technique that GWT used

Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

[Colin Alworth]

On Wednesday, October 8, 2014 5:16:18 PM UTC-5, Thomas Broyer wrote:



 On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth nilo...@gmail.com 
 javascript: wrote:

 Not quite. Anything that continues to return user.client.Element can only 
 be overridden to return user.client.Element or a subclass.


 Ha, didn't thought about subclassing w/ overriding.

 To pick a case at random (ahem, GXT), say you want to override 
 UiObject.getElement for whatever reason. GWT 2.6-2.7 means that we can't 
 change that return type, since you can't override methods and return a 
 superclass (or a subclass of the superclass).

 If we assume that no downstream code ever subclasses and overrides any 
 method that returns user.client.Element, yes, we can cut over cleanly in 
 the future, you are right. But GXT notwithstanding, the SimplePanel class 
 is meant to be subclassed and have getContainerElement() return a different 
 container for the child - I'd be very surprised if there is no downstream 
 code that does this somewhere.

 Example: 
 FooLib v1 is compatible with GWT 2.5, when user.client.Element was not 
 deprecated. It has a SimplePanel subclass called HeaderPanel, which 
 overrides getContainerElement() to return a specific child element.
 GWT 2.6 deprecates user.client.Element, so FooLib v1 is compatible with 
 both GWT 2.5 and 2.6. As it should be.
 To catch up, FooLib v2 would like to remove usages of 
 user.client.Element, but since SimplePanel.getContainerElement() still 
 requires that return type, it can't. The best they can do is find all cases 
 of user.client.Element and cast up to dom.client.Element from the return 
 value of methods like getElement() and getContainerElement().
 Lets say GWT 2.7 cuts all user.client.Element. Now FooLib v1 and v2 are 
 *incompatible* with GWT 2.7, even though they compatible with 2.6, and v2 
 was writing the cleanest possible code (returning a deprecated type). Not 
 ideal.
 Or, with the patch I'm offering, GWT 2.7 keeps user.client.Element, but 
 now has SimplePanel.getContainerElement return a supertype of 
 user.client.Element, so subclasses are free to *further restrict* the 
 return type (like v1/v2 is doing), or use the dom.client.Element. The v1 
 version will probably have issues if it uses the returned value from 
 getContainerElement() as a user.client.Element, but v2 corrected that, so 
 v2 now is compatible with GWT 2.6 and GWT 2.7. Win.
 Next, GWT 2.8 or 3.0 drops all remaining traces of user.client.Element, 
 and since v2 didn't use it any more, in this regard v2 is also compatible 
 with GWT 2.8/3.0. Of course, this won't happen, some other API detail will 
 break, I promise (Splittable.removeReified, removed logger classes breaking 
 .gwt.xml, required resource tags causing warnings, etc).


 That's basically what I said too, right? Remove all uses of 
 user.client.Element but keep the class around (or –better IMO– move it to a 
 gwt-user-compat.jar) for downstream libraries.


Okay, call it mixed messages then. I'll update the patch to go further in 
this direction, so that user.client.Element exists, but is unused in 2.7, 
and we can kill it in the next version.

Do we have a plan for a gwt-user-compat v2.7.0? Seems a bit silly to make 
one for a single class...

  



 On Wednesday, October 8, 2014 4:15:10 AM UTC-5, Thomas Broyer wrote:


 On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote:

 Sorry for the thread necromancy, but aside from 
 https://groups.google.com/d/topic/google-web-toolkit-
 contributors/90PSQ7wKHtI/discussion this was the only relevant 
 existing conversation I could find on the topic. 

 In GWT 2.6 user.client.Element was finally deprecated, though done in a 
 way to avoid any backward compatibility breakage. For example, UiObject 
 now 
 has two setElement methods, one for user.client.Element and another for 
 dom.client.Element. 

 However, UiObject.getElement still returns user.client.Element, as do a 
 few other methods, as of master when I write these words. I'm submitting a 
 patch that first amends UiObject.getElement and 
 SimplePanel.getContainerElement 
 to return dom.client.Element. My thinking is that we need an API-breaking 
 release which still holds user.client.Element, but doesn't actually use 
 them, allowing downstream libraries or projects to be compatible with more 
 than one release.

 The alternatives as I'm currently seeing them, after deprecating in an 
 initial release
 a) force a big jump, removing all traces of user.client.Element at 
 once, meaning a library that is compatible with 2.x may not be compatible 
 with 2.x+1. Not ideal (as a downstream library author, who doesn't want to 
 force users to only support a single version of GWT at a time, as bugs do 
 happen, even in GWT), but certainly easier to maintain.
 b) do this two-step dance, making API breakage twice, but with the goal 
 of shifting to the new API within GWT itself (and encouraging it 
 downstream), then a version later

Re: [gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM

[Colin Alworth]

 of this, JSNI dispatch changes, and
AutoDirectionHandler.Target losing HasText. So far.). But GWT 2.6 added new
*final* methods to Element, ImageResourcePrototype shimmered back and
forth, repackaged apache commons in the compiler, util classes vanishing in
favor of repackaged guava. Not to mentioned

API Changes are inevitable. Google does the lion's share of improvements to
GWT, and so guides the majority of what API changes are acceptable and
which ones are too much to handle. But stuff disappears when Google is
ready to pull it (EXPERIMENTAL comments or no), as long as Google isn't
using them and they are deemed unmaintainable. But mechanically processable
documented API changes made *over a year ago*? Too much, too soon, put it
back.

We can have it both ways, but we need to recognize that having it both ways
is inconsistent.


 On Thu, Oct 9, 2014 at 2:48 PM, 'Matthew Dempsky' via GWT Contributors 
 google-web-toolkit-contributors@googlegroups.com wrote:

 On Wed, Oct 8, 2014 at 3:15 PM, Thomas Broyer t.bro...@gmail.com wrote:

 On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth niloc...@gmail.com
 wrote:

 Not quite. Anything that continues to return user.client.Element can
 only be overridden to return user.client.Element or a subclass.


 Ha, didn't thought about subclassing w/ overriding.


 Yeah, that was the main issue I remember being concerned about.
 Thankfully covariant return types make it more manageable: as long as user
 code limits itself to:

   1. Only use com.google.gwt.user.client.Element as a return type when
 needed for overloading a GWT-provided method, and
   2. In those methods, only writes return statements in the form return
 DOM.asOld(...);

 then they'll be forwards compatible with the future GWT release that
 changes the return types everywhere to com.google.gwt.dom.client.Element
 (but keeps the user.client.Element subclass).

 Then finally once everyone's moved to that GWT release, user code can
 change user.client.Element - dom.client.Element and return
 DOM.asOld(...) - return ... to be forward compatible with the *next*
 future GWT release that removes those APIs completely.

 (Unfortunately like Goktug mentioned, updating Google's internal code
 base to meet those first two constraints is a major endeavor.)

 --
 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/CAF52%2BS7uEwwKV-im7XbUxLkNnXkZFHcgWHjMyJH3EcCBA5GM%3DA%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAF52%2BS7uEwwKV-im7XbUxLkNnXkZFHcgWHjMyJH3EcCBA5GM%3DA%40mail.gmail.com?utm_medium=emailutm_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/CAN%3DyUA18B6PddxH8G3R%2B9-9YQwHmhUyrVifDx5tLAXciKABXGw%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA18B6PddxH8G3R%2B9-9YQwHmhUyrVifDx5tLAXciKABXGw%40mail.gmail.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
218.248.6165
niloc...@gmail.com

-- 
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/CADcXZMx%2BqdsB99wAVK0J1cb%2BdbaJSLL4MvQ%2BwpDu6M_qoT_HnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upgrade 2.7 beta1 to rc1 - browser refresh and change detection not working

[Colin Alworth]

It is also possible that there is a stale copy of .java resources on your
classpath, such as in target/classes/ for a maven project - we've seen that
get in the way as well. Make sure that either target/classes/ isn't on your
classpath, or that it doesn't have another (stale) copy of whatever you are
trying to compile.
On Thu Oct 30 2014 at 10:40:52 AM Jens jens.nehlme...@gmail.com wrote:

 I assume you have deployed an old module.nocache.js file. Try a clean
 start by deleting your /war/modulename folder and restart DevMode. A new
 module.nocache.js file should be generated (could take a bit as the
 CodeServer needs to start before this file gets generated) which
 automatically recompiles your app each time you refresh the browser.

 -- 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/0254ed3a-fbff-4b8f-b7f3-31997d32c2d4%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/0254ed3a-fbff-4b8f-b7f3-31997d32c2d4%40googlegroups.com?utm_medium=emailutm_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/CADcXZMwR3WUSpEvVoGfW%2BYo%2B2LW_vMinRKJyxUsu4bW_hHROjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Possible compiler bug in 2.7 ignoring a set-property

[Colin Alworth]

I don't recall if inherited modules are loaded more than once - in other
words, if one of the higher up modules (like BaseGWT) already inherited
BaseBrowsers, then a later module added ie10 via extend-property, it might
not be possible to re-inherit BaseBrowsers and have it re-set user.agent
down to just those two.

I don't know if this is actually the case or not, but it might make sense,
since otherwise you could run in circles inheriting modules that inherit
each other. Instead, I always encourage developers to list their inherits
first, then their own specific overrides. Don't think of a module file like
a function call, since that could lead to recursion and other fun issues,
think of them more as dependencies.



On Wed Feb 04 2015 at 10:06:19 AM Jan Thewes janthe...@gmail.com wrote:

 Hey guys,

 I've found what I think is a bug in GWT2.7.
 We're trying to compile the attached file 'MyMegaModule.gwt.xml'
 The last inherit in this file is BaseBrowsers.gwt.xml - I've attached that
 too.
 In the BaseBrowsers.gwt.xml you can see that we only want gecko and safari
 compilations but when compiling we get an ie10 permutation too.
 There might be other inherits that are setting the user.agent property to
 something including the ie10 but because of our BaseBrowsers.gwt.xml being
 inherited as the last module we should only get gecko and safari, am I
 right?

 I've no idea how to fix this.

 Thx for any ideas!

 Cheers,
 Jan

 --
 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/ac5c7e23-fd85-46d6-883b-8f8600c496cb%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/ac5c7e23-fd85-46d6-883b-8f8600c496cb%40googlegroups.com?utm_medium=emailutm_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/CADcXZMw_tXtEtOBOuU2t_v2bf%3DAARYkOj%3DcTY78Mu2jWRaUL2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] support for JSR 310 / java.time created

[Colin Alworth]

Are you planning on being at either GWT.create event? I know several people
(including myself) who will be there and would be happy to help.

Otherwise, there are several contributors in ##gwt on irc.freenode.net who
would be able to help with this process.
On Mon Jan 19 2015 at 4:44:01 AM Salvador Diaz diaz.salva...@gmail.com
wrote:

 For those looking for the code, I found it was moved to an independent
 project, which I'm hoping should make it easier to integrate in the patch
 submission process:
 https://github.com/m-m-m/gwt-time

 I'm willing to take some time to move this forward, either working with
 Jörg or alone, could anyone walk me through the steps needed to make it
 happen ?


 On Wednesday, March 5, 2014 at 11:41:59 PM UTC+1, Daniel Kurka wrote:

 @Joerg could you start setting up a patch for review in gerrit?



 On Monday, December 9, 2013 10:20:54 PM UTC+1, Jörg Hohwiller wrote:

 http://code.google.com/p/google-web-toolkit/issues/detail?id=8486

  --
 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/42c41c35-0d05-4448-91f3-e2e0cc685f44%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/42c41c35-0d05-4448-91f3-e2e0cc685f44%40googlegroups.com?utm_medium=emailutm_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/CADcXZMzc_OHHNxLQSQ%3D6HJq6c%3DuQrjGzsD8BCb7P9OZxrko-SQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] What constitutes an acceptable emulated String.format implementation?

[Colin Alworth]

Its not that 3k is huge, its that it would be (to a developer, accustomed
to GWT's policies) massively larger than normally expected for built-in
methods. Just ran SOYC on a project (OBF but not closure), and the largest
java.lang.String method is 466 bytes, greater than twice the size of the
next biggest method. The entire class is only 1,749 bytes, and the entire
java.lang (for this project) is 10,535 bytes.

Adding String.format, once, using only %s to substitute in strings easily,
would add 30%.

On Mon Feb 09 2015 at 8:26:49 AM Benjamin DeLillo bpd9...@gmail.com wrote:

 Dan,

 Thanks for the response.

 sprintf.js is 3kB minified and 7.5kB uncompressed weighing in at just
 under 200 LoC, you mention this would be too big. Just how small would an
 implementation have to be to be acceptable? How large are other JRE
 emulation implementations by comparison? I spoke with Ray at GWT.Create
 2013 and his take on this was that although String.format was originally
 excluded from GWT for codesize reasons, that in today's browser/internet
 ecosystem the hit would be acceptable.

 I do agree that any less than complete implementation needs to have as
 obvious a failure mode as possible for when it diverges from String.format
 canon, and must be well documented and easy to find. How do other JRE
 emulation implementations handle this kind of divergence? Or do they avoid
 such divergence at all costs?



 On Monday, February 9, 2015 at 5:13:38 AM UTC-5, Daniel Kurka wrote:

 Hi Benjamin,

 thanks for reaching out to us. Answers are inline.


 On Sat, Feb 7, 2015 at 5:31 AM, Benjamin DeLillo bpd...@gmail.com
 wrote:

 For an implementation to be accepted would it have to conform to the entire 
 Java Formater spec? 
 http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html

 I think supporting the entire java spec is impossible since we do not
 have Locale working (for codesize reasons). So we would need to discuss
 what a good subset would be


 Would an implementation lacking the Date/Time conversions be acceptable?

 Would an implementation that wraps sprintf.js be acceptable (if the 
 licensing is compatible)? https://github.com/alexei/sprintf.js

 I briefly skimmed the lib and it seems huge, so I am inclined to say no.
 In general you have to think about that any application will have the hit
 of that method in their app as soon as they call String.format one time in
 their code base.



 What about a minimal positional substitution implementation and nothing 
 more?


 Right now any code that relies on String.format will not compile in GWT
 and thus give the author a clear indication of having a problem. Once we
 support a subset this compile error might be gone, but we will be
 introducing runtime errors for not supported features rather than compile
 time errors.

 One could try to deal with these (and this is bad from the compiler
 perspective), by looking at the parameters of String.format and only allow
 statically resolvable arguments for the format String that are supported by
 the emulation, but this is a very tight coupling of compiler and lib that
 we do not want in the compiler.

 So if we want to do a minimal support of String.format these are the
 kinds of problems we need to discuss.



  --
 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/bc6afdc0-eb87-
 4815-b076-6db912f8f94c%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/bc6afdc0-eb87-4815-b076-6db912f8f94c%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




 --
 Google Germany GmbH
 *Dienerstr. 12*
 *80331 München*

 Registergericht und -nummer: Hamburg, HRB 86891
 Sitz der Gesellschaft: Hamburg
 Geschäftsführer: Graham Law, Katherine Stephens

  --
 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/fa54c87b-c54b-4c8d-87f9-ff234c04cc35%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/fa54c87b-c54b-4c8d-87f9-ff234c04cc35%40googlegroups.com?utm_medium=emailutm_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 

Re: [gwt-contrib] Re: What constitutes an acceptable emulated String.format implementation?

[Colin Alworth]

I'd be strongly in favor of a StringFormat class - this could be
library-ized easily, letting someone opt in to even having it in their
project, or call it.

Since we're changing the API (though I assume keeping the 'format string'
language), you could take other steps to ensure small complied size and
best runtime performance. Consider SafeHtmlTemplates or Messages, with
their abilities to interpolate strings, but knowing the format string to
use at compile-time, not runtime.

This probably won't work in all cases (or be especially nice to use in the
other cases), but will be faster and smaller when compiled to JS.

On Tue Feb 10 2015 at 8:07:22 AM Benjamin DeLillo bpd9...@gmail.com wrote:

 If trying to provide a fairly complete duplicate of the JRE functionality
 is too much of a point of contention, would it be more acceptable to
 provide a simpler/lighter-weight string interpolation implementation behind
 e.g. GWT.format() or to follow the NumberFormat convention a StringFormat
 class?


 On Friday, February 6, 2015 at 11:31:32 PM UTC-5, Benjamin DeLillo wrote:

 For an implementation to be accepted would it have to conform to the entire 
 Java Formater spec? 
 http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html

 Would an implementation lacking the Date/Time conversions be acceptable?

 Would an implementation that wraps sprintf.js be acceptable (if the 
 licensing is compatible)? https://github.com/alexei/sprintf.js


 What about a minimal positional substitution implementation and nothing more?

  --
 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/9d1583ef-ae7b-41e2-9eca-207e8ef33062%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/9d1583ef-ae7b-41e2-9eca-207e8ef33062%40googlegroups.com?utm_medium=emailutm_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/CADcXZMw1W_q866X0R2h8eJGWzU2Wx%2B_u62i_MAVuthEGEbnWNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Java8 emulation

[Colin Alworth]

The trick seems to be that it is not going to be possible to add Java8 emul
code without actually using Java8 - while lambdas can be avoided, defender
methods cannot. If you need to provide a new interface like Consumer, the
supersource *must* have the `default` method(s), or it won't actually be
Consumer.

If it were just those types, it would be possible to move them into their
own module so developers would need to inherit's the Java8 module to get
access to them, but the Collection interface itself needs to be changed to
add `default StreamE stream()`, plus the implementation, or else all
implementors of Collection (and Set and List) need to have an
implementation added. Even then, Stream would need to be emulated, which
references Consumer, so we can't have it be a separate module...

...or am I over-complicating matters?

On Wed, Mar 25, 2015 at 10:20 AM John A. Tamplin j...@jaet.org wrote:

 On Wed, Mar 25, 2015 at 11:16 AM, Jens jens.nehlme...@gmail.com wrote:

 whats the current situation of adding Java8 emulations to GWT?

 I would like to fix the current emulation of @FunctionalInterface (wrong
 package and missing imports), add java.util.Optional[Int|Long|Double]
 emulation and like to see java.util.function interfaces in trunk committed.
 That would allow us to further work on stream API emulation which would be
 nice to have in GWT 2.8, right? Just having Java8 syntax support seems a
 little weak to me for a new release.


 Adding new classes should be pretty straightforward.


 Currently my patch for java.util.function can not be verified by Jenkins
 because it runs the presubmit task with sourceLevel 1.7 (and Java7 I
 think). So I assume that the next GWT release should be compatible to
 Java7.

 Does this mean that any emulation of Java8 APIs should be done using
 Java7 syntax ( = no lambdas in emulation code) ? What about default methods
 in emulated code when people use JDK 7 with GWT?


 That would be my vote - we don't want to force people to use Java8 just
 yet.

 --
 John A. Tamplin

 --
 You received this message because you are subscribed to the Google Groups
 GWT Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X-xtnTX_xXPPr4M9AsFP_qNQHZU_9k_VJP5o4ZjLYknWw%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X-xtnTX_xXPPr4M9AsFP_qNQHZU_9k_VJP5o4ZjLYknWw%40mail.gmail.com?utm_medium=emailutm_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/CADcXZMxJV4ES0SiMeDsMSaw9zrPCZhYq2sTkJoZVgcpxF59%2BHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Jsni on String methods in GWT 2.7

[Colin Alworth]

Getting offtopic, but there is absolutely no requirement that JSO methods
are public. See dom.client.Element for several examples of private methods.

On Mon, Mar 30, 2015 at 10:27 PM James Nelson ja...@wetheinter.net wrote:

 Ok, great.  Thanks for the heads up.  I was pretty sure that Strings had
 become native first-class objects.

 Since JSOs will all have public methods, I will be safe with the same fix
 for String (not using JSNI if not necessary).
 Given that java arrays only have one field, and that field does not work
 in JVM reflection, nor do any of the Object methods, I'll leave them alone
 (that's what java.lang.reflect.Array is for)...

 Added issue
 https://code.google.com/p/google-web-toolkit/issues/detail?id=9166 to
 track this.

 For posterity and search indexing, if anyone tries to use hashCode, equals
 or compareTo on String or Array in JSNI and are getting undefined reference
 errors, use a static method instead.

 --
 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/9bbd9127-65c9-4fa1-9743-a94fcd4f3bf4%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/9bbd9127-65c9-4fa1-9743-a94fcd4f3bf4%40googlegroups.com?utm_medium=emailutm_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/CADcXZMyfTkw5Kfm0DXeMLH8%3DXBwFzb1W3qO1xKmGQ%3DjT-w-YGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Open reviews

[Colin Alworth]

There is a document outlining which maintainers exist for various parts of
GWT, designed to suggest an initial reviewer or reviewers for a new
patch/bugfix/feature.

https://docs.google.com/document/d/1vyncxfuujIJ3L-PBLNM68tfeXRFZ4qDdnWEodblmvRg/edit

This list is in the top (stickied) post in gwt-contrib, and should be
consulted to see who should be assigned to check out a patch.

On Fri, May 15, 2015 at 2:23 PM Juan Pablo Gardella 
gardellajuanpa...@gmail.com wrote:

 Any thoughts? Who are able to take reviews?

 On 12 May 2015 at 18:35, Richard Wallis rdwal...@gmail.com wrote:

 Anyone want to review my patch to the scheduler?
 https://gwt-review.googlesource.com/#/c/11510/

 Also it would be good if patches automatically had someone assigned to
 review them.  If the patch falls outside a reviewer's domain then they can
 transfer it to someone else.


 On Tue, May 12, 2015 at 11:16 PM, Juan Pablo Gardella 
 gardellajuanpa...@gmail.com wrote:

 Hi contributors,

 I would like to thanks for your great work and for the passion that you
 put on GWT. I know you are very busy but it's frustrating to spend time in
 some patch and then nothing happen. There are a lot of open reviews
 https://gwt-review.googlesource.com/#/q/status:open. That kind of
 things prevent developers to spend time in patches in the future.

 I say that because I want more contributions for GWT.

 Regards,
 Juan

 --
 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/CA%2BkiFse4iTAoZUKzyaq-4iVFznXXkPM9k1nEfd6-tsQutuk7zg%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2BkiFse4iTAoZUKzyaq-4iVFznXXkPM9k1nEfd6-tsQutuk7zg%40mail.gmail.com?utm_medium=emailutm_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/CAEqaEVhfxgWe450NCqDxEh2ENZLksSxMY5nwj%3D8-9hR3e85zEQ%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEqaEVhfxgWe450NCqDxEh2ENZLksSxMY5nwj%3D8-9hR3e85zEQ%40mail.gmail.com?utm_medium=emailutm_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/CA%2BkiFsff3efEF6KSGD%2BdvwSY0mQnwvHG%3Djx8xR%2BmT6tAr0%3DY9A%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2BkiFsff3efEF6KSGD%2BdvwSY0mQnwvHG%3Djx8xR%2BmT6tAr0%3DY9A%40mail.gmail.com?utm_medium=emailutm_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/CADcXZMyybkBrELFL7%2BOcQ1kffQukSZC_RD6x%2Bc5wPGXtjR%2BzsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Java to WebAssembly Compiler

[Colin Alworth]

Without GC, I think its going to be a bit of a non-starter - the same
issues that apply to compiling to asm.js apply here too. I've heard a few
ideas floated around to just compile specific methods to asm.js, and those
same ideas seem that they could work, but the really hard part is isolating
these pieces of code, and at least for asm.js, you can actually take a
significant performance hit from moving data into (or even just allocating)
typed arrays. If you can tune the feature to how you'll need it (i.e. only
ask the compiler to turn it on if you'll keep them around for a long time
and have very hot code running through there) it seems worth it, but at
that point JSNI or JsInterop might almost be easier to talk to raw JS (or
WebAssembly) to guarantee that you get it right.

That said, GC is an eventual design goal in WebAssembly, so I think GWT or
something like GWT could make it an eventual target.

/2cents

On Mon, Jun 22, 2015 at 2:03 PM Joel Handwell joelhandw...@gmail.com
wrote:

 - Luke Wagner wrote a post on his blog to report that his team at Mozilla
 have started working with Chromium, Edge and WebKit engineers on creating a
 new standard, WebAssembly, that defines a portable, size- and
 load-time-efficient format and execution model specifically designed to
 serve as a compilation target for the Web.

 - Google's JF Bastien mentions
 https://github.com/WebAssembly/design/commit/34318807a17cb43d79e8cf5939319e5b4909dc6d
 GWT in the design document of WebAssembly as a better execution for
 languages and toolkits that are currently cross-compiled to the Web.

 Given this context, how do you think about considing building Java to
 WebAssembly compiler?

 --
 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/f9c423c0-bda2-4018-b7e1-9f56f3a34d73%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/f9c423c0-bda2-4018-b7e1-9f56f3a34d73%40googlegroups.com?utm_medium=emailutm_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/CADcXZMx%3D6Rr-rBdt%3Dym2uf9t-ouP9v-KvJxdErm94XNudbwbyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.8 RC1

[Colin Alworth]

Paul, do keep in mind that the latest in git (and the 2.8.0-SNAPSHOT in
maven) is fairly stable. Some projects (for example, everything that Google
makes) live off of trunk, and many projects upgrade to a snapshot, test
that things are sane, and then 'pin' that build internally to keep running
with it until they decide to update again.

On Wed, Oct 28, 2015 at 8:57 AM Seamus McMorrow 
wrote:

> To try to speed up the fix, maybe if people voted for the issue, it may
> help.
> I just cast my vote to get it fixed.
>
>
> On Wednesday, 28 October 2015 12:53:17 UTC, Paul Robinson wrote:
>>
>> Speaking for myself, a GWT 2.8.0 release that works, but uses too much
>> memory compiling code, to be followed by GWT 2.8.1 with the memory fix, is
>> better than waiting for an unknown amount of time until JDT is fixed.
>>
>> On Wed, Oct 28, 2015 at 8:46 AM, 'Goktug Gokdogan' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>
>>> Hey guys.
>>>
>>> We are planning to make the release cut by next Monday to start testing
>>> sooner. Hopefully by the time we will complete most of the critical pieces
>>> for JsInterop.
>>>
>>> Also FYI, JDT has a huge memory problem with Java8
>>>  so doing a final
>>> release without a fix may make the release less useful for a lot of people.
>>> Let's hope that gets fixed soon.
>>>
>>> --
>>> 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/CAN%3DyUA1Se5eNCNjwS5F8c-wzc7BYqd0rWY%2Bq--Yg9cP7353UnA%40mail.gmail.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/0856-c756-4493-936d-41be54f8d33d%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/CADcXZMyM%3DZut%3DHky4hcWunWZL0WWmH%2B0xNDY5KrshM8k4F48wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Bug in 2.8.0-Snapshot

[Colin Alworth]

As this isn't a NPE (or a type error, which I think is the JS equivalent),
the we're missing a step here. You are seeing an UmbrellaException thrown,
which means not that the handlermanager or event wiring broke, but that
your own handler threw the exception (i.e. the 'TypeError' described in the
wrapper).

That trace is kept in the umbrella exception, and will likely be necessary
to figure out what the real issue is.

Also, the stack below the anon function won't be useful, that's very likely
the wiring that calls into the widget event handling from the dom.

On Thu, Jul 9, 2015 at 10:08 PM Ali Akhtar ali.rac...@gmail.com wrote:

 In 2.8.0-SNAPSHOT, when the ValueChangeEvent is triggered for a dropdown,
 I'm encountering the following stack trace:

 Uncaught com.google.gwt.event.shared.UmbrellaException: Exception caught:
 Exception caught: (TypeError) : Cannot read property
 'java_util_LinkedList_size' of undefined


 com_google_gwt_event_shared_HandlerManager_$fireEvent__Lcom_google_gwt_event_shared_HandlerManager_2Lcom_google_gwt_event_shared_GwtEvent_2V


 com_google_gwt_user_client_ui_Widget_$onBrowserEvent__Lcom_google_gwt_user_client_ui_Widget_2Lcom_google_gwt_user_client_Event_2V

 _.onBrowserEvent__Lcom_google_gwt_user_client_Event_2V

 _.onBrowserEvent__Lcom_google_gwt_user_client_Event_2V


 com_google_gwt_user_client_impl_DOMImplStandard_dispatchEvent__Lcom_google_gwt_user_client_Event_2V

 (anonymous function)


 This only happens in production, in SDM it works without any issues.

 I'm not sure which line specifically causes this, because the stacktrace
 stops at the anonymous function. But, it seems to be around where I'm
 creating an autobean object. The first line of my event handler which shows
 a loading message, seems to get executed fine.

 Would appreciate a speedy resolution to this, as this is in production.
 Thanks.

 --
 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/f4b201e1-5a00-4681-a4ac-3505d7bbc291%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/f4b201e1-5a00-4681-a4ac-3505d7bbc291%40googlegroups.com?utm_medium=emailutm_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/CADcXZMxS%3D7pNHH%3DqHBsY3grOA3jUdq6P%2BPn2asgLGJmGJ-87Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.8.0-beta1 available for testing

[Colin Alworth]

If I could be permitted to slight restate what Julien just said: We will
make a note of it, as we have done in the past, such as when the default
moved from java6 to java7:
http://www.gwtproject.org/release-notes.html#Release_Notes_2_6_0_RC1. That
being said, we of course welcome any community assistance in maintaining
GWT, and documentation is an excellent place to get started and make
significant contributions without going through the code review process
that GWT requires.

Java6 has been EOL'd for almost three years, though technically Java7 has
also reached that stage (last April). As long as we hang on to support for
Java6, we would be unable to use new classes/methods/features of Java7 (and
Java8), excepting the use of something like retrolambda like Thomas
suggested. We would likewise welcome any testing in that area after
performing an automated change to the gwt-servlet.jar. If you find problems
or discover that it works perfectly, and if you share the build scripts you
used to achieve it, that would make it easier to include these changes into
the official release.

On Mon, Dec 7, 2015 at 8:47 AM Julien Dramaix 
wrote:

> Feel free to fill a patch for that :)
>
> On Mon, Dec 7, 2015 at 2:28 PM István Horváth  wrote:
>
>> it would nice to have if you update the release notes page with exact
>> dates on all of the version on both the links and the linked details too.
>>
>> http://www.gwtproject.org/release-notes.html
>>
>>
>> 2015. december 4., péntek 10:51:13 UTC+1 időpontban Daniel Kurka a
>> következőt írta:
>>>
>>> Hi all,
>>>
>>> we just finished testing for GWT 2.8.0-beta1. You can either download it
>>> from goo.gl/62SeR5 or from maven central.
>>>
>>> Release notes can be found here
>>> 
>>> .
>>>
>>> Please start testing and let us know about any issues you encounter by
>>> either discussion here or filing bugs on github
>>> .
>>>
>>> -Daniel
>>>
>> --
>> 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/06401611-3eeb-4647-9fca-69459939aa8d%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/CABb_3%3D5%3DYLe_WNJbvc48mmfRO8Ds1WqqtDwNvhhPD3C66DJHpQ%40mail.gmail.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/CADcXZMxguUkafyvfEG%3DwtuMOoCEfchvenxyfDWxi07D39nvs%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.8.0-beta1 available for testing

[Colin Alworth]

Sorry, I hadn't understood that your primary interest was in release dates,
but though it was more for compatibility with upstream or related tools on
release. That said, I think that the list of downloads at
https://code.google.com/p/google-web-toolkit/downloads/list may prove
useful for historical release dates.

On Mon, Dec 7, 2015 at 9:42 AM István Horváth  wrote:

> i not sure about this link has the correct dates:
> https://en.wikipedia.org/wiki/Google_Web_Toolkit
> also it lacks of 2.5.0 and 2.5.1
>
> 2015. december 7., hétfő 16:40:22 UTC+1 időpontban István Horváth a
> következőt írta:
>>
>> good, where can i find exact dates about release dates (full date, like
>> year month and day) from the beginning?
>>
>
>>
>> 2015. december 7., hétfő 15:47:50 UTC+1 időpontban Julien Dramaix a
>> következőt írta:
>>
> Feel free to fill a patch for that :)
>>>
>>> On Mon, Dec 7, 2015 at 2:28 PM István Horváth  wrote:
>>>
 it would nice to have if you update the release notes page with exact
 dates on all of the version on both the links and the linked details too.

 http://www.gwtproject.org/release-notes.html

>>> --
> 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/b1cddc19-926a-4304-a583-6b0312cc82a4%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/CADcXZMzpwm1O-H9bFWrHn1gmrBhX8mpB1zujr8e7SH4KGv%3DrmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.