[gwt-contrib] Re: Comment on RequestFactory_2_1_1 in google-web-toolkit
Comment by dain.kaplan: Is there an expected release date for 2.1.1? I very much want to use the server-side AutoBean code. For more information: http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] A couple of questions before getting started
Hi My name is Luis, I'm from Spain and I'm ready to contribute to GWT. I have checked out the trunk and configured my eclipse as said here: http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/README.txt. I have set the checkstyle and the error/warning configuration and then imported the gwt-user and gwt-dev projects. The problem is that I get 33 checkstyle problems and 3314 Java Problems (all warnings and the first 100 are raw type warnings) in revision 9344. is this ok? if yes, should this warnings be solved? And just in case, it's ok to send patches with warnings? (I guess the answer is NO). The other question is about the workspace encoding. I'm on a mac. Should I leave the MacRoman encoding for my workspace or should I change it to another like utf-8? Thank you! - Luis -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
Full disclosure - I am the one who has suggested a possible evolution of Activity. I was suggested the introduction of a mechanism to allow an existing Activity to be informed when the Place has changed but the Activity has not (e.g. when there is a change in Place tokens). I commented about how difficult it would be to add a method to Activity without introducing a break and Ray kindly started this thread. I agree with Amir about the concerns. The AbstractActivity class and the interface it implements has to have sensible, obvious, do-nothing implementation otherwise subclasses have to override the behavior they don't want and it all gets messy. Also, in Java we get to have one base class, so extending AbstractActivity precludes extending something else. Several APIs I've worked with have moved away from a design that requires developers to extend a particular class. e.g. JUnit Removal of the interface entirely would make mocking with frameworks like EasyMock more difficult. Although things like the EasyMock classextension make it possible to mock non-interfaces it's not ideal and obviously isn't an option in a GWT test case. Personally I'd like to try to keep the interface for these reasons. How about the documentation is beefed up on the interface to say You should extend AbstractActivity rather than implement Activity directly otherwise you may be broken if it doesn't already, but leave the interface in place for people who want to take on the risk of a break? I guess it depends on how much Activity is expected to change in future. In the case I have in mind to Activity the implementation would probably have an obvious no-op implementation, but without having talked about that it's hard to be sure. Luckily, I'm pretty sure that the use of AbstractActivity is what most people will have done anyway. I've just started looking at the Activity framework and this particular wrinkle was the first we hit, but I wonder how many more things the ActivityManager (and associated classes) would want to call on the Activity interface so the need to evolve Activity much further may not be required. I do agree that now would be a good time to do this kind of change, though, because it's only going to get harder. Neil. On 3 December 2010 05:39, Amir Kashani amirkash...@gmail.com wrote: We've adopted the new MVP framework pretty heavily in a couple of new projects and at this point, I don't think we've ever not used AbstractActivity. So, as long as the existing methods in Activity don't become inaccessible to non-GWT code (i.e. not package protected or final), I don't see a problem. My only concern is that while making it an abstract class makes it easier to evolve, it also make it easier to default behavior that the end-user may not want. If a mechanism isn't provided to override this behavior, then someone may end up having to roll their own MVP framework for an otherwise minor issue. With a something as powerful and complex as this framework, that'd be a real shame. So, *please please please,* be cautious with this power: reasonable default behavior and the ability to override. Thanks! - Amir On Thu, Dec 2, 2010 at 7:55 PM, Ray Ryan rj...@google.com wrote: We're making a few breaking changes in 2.1.1 to the new features introduced in 2.1. (We're not supposed to do that kind of thing, but are hoping to get away with it in this quick follow up release before there is much adoption.) I'd like to add a change to Activity to that list, in order to allow it to evolve in later releases when breakage of any kind won't be an option: I'd like to make Activity an abstract class instead of an interface, basically rename AbstractActivity. Any objections? rjrjr -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Fix external issues 5521, 5446, 5332, javadoc links (issue1186801)
Reviewers: rchandia, Description: Fix external issues 5521, 5446, 5332, javadoc links Please review this at http://gwt-code-reviews.appspot.com/1186801/show Affected files: M user/src/com/google/gwt/dom/client/OptionElement.java M user/src/com/google/gwt/dom/client/Touch.java M user/src/com/google/gwt/event/dom/client/TouchEvent.java M user/src/com/google/gwt/i18n/client/LocalizableResource.java M user/src/com/google/gwt/i18n/client/Messages.java M user/src/com/google/gwt/user/client/ui/ImageBundle.java M user/src/com/google/gwt/user/server/rpc/RPCServletUtils.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Comment on AutoBean in google-web-toolkit
Comment by larse...@gmail.com:
{{{
@Category(PersonCategory.class)
interface MyFactory {
// Would be illegal without a category providing an implementation of
doSomething()
AutoBeanPerson person();
}
}}}
Shouldn't this read
{{{
@Category(PersonCategory.class)
interface MyFactory extends AutoBeanFactory{
// Would be illegal without a category providing an implementation of
marry(AutoBeanPerson person, Person spouse)
AutoBeanPerson person();
}
}}}
For more information:
http://code.google.com/p/google-web-toolkit/wiki/AutoBean
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
Let me push harder for the abstract class. If the class is documented to
forbid non-trivial default implementations, there would be no need to mock
it, and no chance of breaking people who decide to use the interface
directly for whatever reason.
WRT to the single base class problem, I was initially going to propose that
we also add interface IsActivity { Activity asActivity(); } and make
Activity implement it. But I didn't see any immediate use for it, since
nothing at the moment accepts an Activity as an argument, and nothing
returns one except for ActivityMapper. If such a need appeared it would be
trivial to add.
You buying it? Is the loss of easyMock too much?
On Fri, Dec 3, 2010 at 12:36 AM, Neil Fuller nful...@google.com wrote:
Full disclosure - I am the one who has suggested a possible evolution of
Activity. I was suggested the introduction of a mechanism to allow an
existing Activity to be informed when the Place has changed but the Activity
has not (e.g. when there is a change in Place tokens). I commented about how
difficult it would be to add a method to Activity without introducing a
break and Ray kindly started this thread.
I agree with Amir about the concerns. The AbstractActivity class and the
interface it implements has to have sensible, obvious, do-nothing
implementation otherwise subclasses have to override the behavior they don't
want and it all gets messy. Also, in Java we get to have one base class, so
extending AbstractActivity precludes extending something else. Several APIs
I've worked with have moved away from a design that requires developers to
extend a particular class. e.g. JUnit
Removal of the interface entirely would make mocking with frameworks like
EasyMock more difficult. Although things like the EasyMock classextension
make it possible to mock non-interfaces it's not ideal and obviously isn't
an option in a GWT test case.
Personally I'd like to try to keep the interface for these reasons. How
about the documentation is beefed up on the interface to say You should
extend AbstractActivity rather than implement Activity directly otherwise
you may be broken if it doesn't already, but leave the interface in place
for people who want to take on the risk of a break? I guess it depends on
how much Activity is expected to change in future. In the case I have in
mind to Activity the implementation would probably have an obvious no-op
implementation, but without having talked about that it's hard to be sure.
Luckily, I'm pretty sure that the use of AbstractActivity is what most
people will have done anyway.
I've just started looking at the Activity framework and this particular
wrinkle was the first we hit, but I wonder how many more things the
ActivityManager (and associated classes) would want to call on the Activity
interface so the need to evolve Activity much further may not be required. I
do agree that now would be a good time to do this kind of change, though,
because it's only going to get harder.
Neil.
On 3 December 2010 05:39, Amir Kashani amirkash...@gmail.com wrote:
We've adopted the new MVP framework pretty heavily in a couple of new
projects and at this point, I don't think we've ever not used
AbstractActivity. So, as long as the existing methods in Activity don't
become inaccessible to non-GWT code (i.e. not package protected or final), I
don't see a problem.
My only concern is that while making it an abstract class makes it easier
to evolve, it also make it easier to default behavior that the end-user may
not want. If a mechanism isn't provided to override this behavior, then
someone may end up having to roll their own MVP framework for an otherwise
minor issue. With a something as powerful and complex as this framework,
that'd be a real shame. So, *please please please,* be cautious with
this power: reasonable default behavior and the ability to override.
Thanks!
- Amir
On Thu, Dec 2, 2010 at 7:55 PM, Ray Ryan rj...@google.com wrote:
We're making a few breaking changes in 2.1.1 to the new features
introduced in 2.1. (We're not supposed to do that kind of thing, but are
hoping to get away with it in this quick follow up release before there is
much adoption.)
I'd like to add a change to Activity to that list, in order to allow it
to evolve in later releases when breakage of any kind won't be an option:
I'd like to make Activity an abstract class instead of an interface,
basically rename AbstractActivity.
Any objections?
rjrjr
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W
9TQ
Registered in England Number: 3977902
--
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W
9TQ
Registered in England Number: 3977902
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
[gwt-contrib] Re: Fix external issues 5521, 5446, 5332, javadoc links (issue1186801)
LGTM http://gwt-code-reviews.appspot.com/1186801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] A couple of questions before getting started
On Thu, Dec 2, 2010 at 1:35 PM, Luis Solano luissolan...@gmail.com wrote: I have checked out the trunk and configured my eclipse as said here: http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/README.txt . I have set the checkstyle and the error/warning configuration and then imported the gwt-user and gwt-dev projects. The problem is that I get 33 checkstyle problems and 3314 Java Problems (all warnings and the first 100 are raw type warnings) in revision 9344. is this ok? if yes, should this warnings be solved? And just in case, it's ok to send patches with warnings? (I guess the answer is NO) It's sort of a known-issue broken-window. Some of them stem from third-party code that has come into GWT, such as Rhino or ASM. Removing warnings in original GWT code is generally a Good Thing. The other question is about the workspace encoding. I'm on a mac. Should I leave the MacRoman encoding for my workspace or should I change it to another like utf-8? All GWT java source is UTF-8, so definitely use that. Scott -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] A couple of questions before getting started
Some of them stem from third-party code that has come into GWT, such as Rhino or ASM. I've been crossing my fingers about this feature for awhile now: https://bugs.eclipse.org/bugs/show_bug.cgi?id=220928 (No idea if the 3rd party code is currently in separate source folders, but it might be worth moving it over to separate folders just to ignore the warnings, when/if this feature ever ships.) - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Undeprecate HandlerManager and TabPanel, neither of which is quite (issue1187801)
Reviewers: jlabanca, Description: Undeprecate HandlerManager and TabPanel, neither of which is quite ready to die yet. Please review this at http://gwt-code-reviews.appspot.com/1187801/show Affected files: M user/src/com/google/gwt/event/shared/HandlerManager.java M user/src/com/google/gwt/user/client/ui/TabPanel.java M user/src/com/google/gwt/user/client/ui/Widget.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Undeprecate HandlerManager and TabPanel, neither of which is quite (issue1187801)
John, there have been internal discussions about both of these un-deprecations. Joel wants TabPanel to be blessed again, and we lack any alternative to HandlerManager for widget developers so far. On 2010/12/03 18:47:12, rjrjr wrote: http://gwt-code-reviews.appspot.com/1187801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Undeprecate HandlerManager and TabPanel, neither of which is quite (issue1187801)
http://code.google.com/p/google-web-toolkit/issues/detail?id=5709 http://gwt-code-reviews.appspot.com/1187801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r9353 committed - Fixes two issues...
Revision: 9353
Author: rchan...@google.com
Date: Fri Dec 3 03:56:03 2010
Log: Fixes two issues
Issue 5460: Scaffold app expenses does not store decimal values
Issue 5663: DoubleParser rounds values to integers
Thanks to t.bro...@gmail.com
Review at http://gwt-code-reviews.appspot.com/1181802
http://code.google.com/p/google-web-toolkit/source/detail?r=9353
Modified:
/trunk/user/src/com/google/gwt/text/client/DoubleParser.java
/trunk/user/test/com/google/gwt/text/client/DoubleParserTest.java
===
--- /trunk/user/src/com/google/gwt/text/client/DoubleParser.java Fri Oct 8
06:15:38 2010
+++ /trunk/user/src/com/google/gwt/text/client/DoubleParser.java Fri Dec 3
03:56:03 2010
@@ -46,7 +46,7 @@
}
try {
- return
Math.rint(NumberFormat.getDecimalFormat().parse(object.toString()));
+ return NumberFormat.getDecimalFormat().parse(object.toString());
} catch (NumberFormatException e) {
throw new ParseException(e.getMessage(), 0);
}
===
--- /trunk/user/test/com/google/gwt/text/client/DoubleParserTest.java Tue
Oct 5 17:59:14 2010
+++ /trunk/user/test/com/google/gwt/text/client/DoubleParserTest.java Fri
Dec 3 03:56:03 2010
@@ -30,7 +30,7 @@
}
public void testOuroborus() throws ParseException {
-assertEquals(123,
DoubleRenderer.instance().render(DoubleParser.instance().parse(123)));
+assertEquals(123.5,
DoubleRenderer.instance().render(DoubleParser.instance().parse(123.5)));
}
public void testNull() throws ParseException {
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r9354 committed - In CompilingClassLoader, refuse to load a class if its compilation uni...
Revision: 9354
Author: con...@google.com
Date: Fri Dec 3 05:03:49 2010
Log: In CompilingClassLoader, refuse to load a class if its compilation
unit has errors.
Review at http://gwt-code-reviews.appspot.com/1167801
Review by: sco...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=9354
Modified:
/trunk/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
===
--- /trunk/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
Wed Dec 1 13:52:36 2010
+++ /trunk/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
Fri Dec 3 05:03:49 2010
@@ -1018,10 +1018,7 @@
// Get the bytes, compiling if necessary.
byte[] classBytes = findClassBytes(className);
-if (classBytes == null) {
- throw new ClassNotFoundException(className);
-}
-
+
if (HasAnnotation.hasAnnotation(classBytes, GwtScriptOnly.class)) {
scriptOnlyClasses.add(className);
maybeInitializeScriptOnlyClassLoader();
@@ -1113,7 +1110,7 @@
}
@SuppressWarnings(deprecation)
- private byte[] findClassBytes(String className) {
+ private byte[] findClassBytes(String className) throws
ClassNotFoundException {
if (JavaScriptHost.class.getName().equals(className)) {
// No need to rewrite.
return javaScriptHostBytes;
@@ -1136,6 +1133,12 @@
CompilationUnit unit = (compiledClass == null)
? getUnitForClassName(lookupClassName) : compiledClass.getUnit();
+
+if (unit != null unit.isError()) {
+ throw new ClassNotFoundException(Cannot load class + className
+ + because it has errors.);
+}
+
if (emmaAvailable) {
/*
* build the map for anonymous classes. Do so only if unit has
anonymous
@@ -1148,11 +1151,10 @@
unit.hasAnonymousClasses() jsniMethods != null
jsniMethods.size() 0 !unit.createdClassMapping()) {
if (!unit.constructAnonymousClassMappings(logger)) {
- logger.log(TreeLogger.ERROR,
+ throw new ClassNotFoundException(
Our heuristic for mapping anonymous classes between
compilers
+ failed. Unsafe to continue because the wrong jsni
code
+ could end up running. className = + className);
- return null;
}
}
}
@@ -1199,6 +1201,10 @@
}
classBytes = newBytes;
}
+
+if (classBytes == null) {
+ throw new ClassNotFoundException(className);
+}
return classBytes;
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r9355 committed - Adding methods to insert columns, get the column count, and get column...
Revision: 9355
Author: jlaba...@google.com
Date: Fri Dec 3 05:16:36 2010
Log: Adding methods to insert columns, get the column count, and get
columns by index in a CellTable. Thesemethods are very useful for changing
the visible Columns. Currently, users must remove all columns, then re-add
them just to insert a single column.
Review at http://gwt-code-reviews.appspot.com/1181801
Review by: sbruba...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=9355
Modified:
/trunk/user/src/com/google/gwt/user/cellview/client/CellTable.java
/trunk/user/test/com/google/gwt/user/cellview/client/CellTableTest.java
===
--- /trunk/user/src/com/google/gwt/user/cellview/client/CellTable.java Wed
Dec 1 05:40:20 2010
+++ /trunk/user/src/com/google/gwt/user/cellview/client/CellTable.java Fri
Dec 3 05:16:36 2010
@@ -592,91 +592,59 @@
}
/**
- * Adds a column to the table.
+ * Adds a column to the end of the table.
*
* @param col the column to be added
*/
public void addColumn(ColumnT, ? col) {
-addColumn(col, (Header?) null, (Header?) null);
+insertColumn(getColumnCount(), col);
}
/**
- * Adds a column to the table with an associated header.
+ * Adds a column to the end of the table with an associated header.
*
* @param col the column to be added
* @param header the associated {...@link Header}
*/
public void addColumn(ColumnT, ? col, Header? header) {
-addColumn(col, header, null);
+insertColumn(getColumnCount(), col, header);
}
/**
- * Adds a column to the table with an associated header and footer.
+ * Adds a column to the end of the table with an associated header and
footer.
*
* @param col the column to be added
* @param header the associated {...@link Header}
* @param footer the associated footer (as a {...@link Header} object)
*/
public void addColumn(ColumnT, ? col, Header? header, Header?
footer) {
-headers.add(header);
-footers.add(footer);
-columns.add(col);
-boolean wasinteractive = isInteractive;
-updateDependsOnSelection();
-
-// Move the keyboard selected column if the current column is not
-// interactive.
-if (!wasinteractive isInteractive) {
- keyboardSelectedColumn = columns.size() - 1;
-}
-
-// Sink events used by the new column.
-SetString consumedEvents = new HashSetString();
-{
- SetString cellEvents = col.getCell().getConsumedEvents();
- if (cellEvents != null) {
-consumedEvents.addAll(cellEvents);
- }
-}
-if (header != null) {
- SetString headerEvents = header.getCell().getConsumedEvents();
- if (headerEvents != null) {
-consumedEvents.addAll(headerEvents);
- }
-}
-if (footer != null) {
- SetString footerEvents = footer.getCell().getConsumedEvents();
- if (footerEvents != null) {
-consumedEvents.addAll(footerEvents);
- }
-}
-CellBasedWidgetImpl.get().sinkEvents(this, consumedEvents);
-
-redraw();
+insertColumn(getColumnCount(), col, header, footer);
}
/**
- * Adds a column to the table with an associated String header.
+ * Adds a column to the end of the table with an associated String
header.
*
* @param col the column to be added
* @param headerString the associated header text, as a String
*/
public void addColumn(ColumnT, ? col, String headerString) {
-addColumn(col, new TextHeader(headerString), null);
+insertColumn(getColumnCount(), col, headerString);
}
/**
- * Adds a column to the table with an associated {...@link SafeHtml} header.
+ * Adds a column to the end of the table with an associated {...@link
SafeHtml}
+ * header.
*
* @param col the column to be added
* @param headerHtml the associated header text, as safe HTML
*/
public void addColumn(ColumnT, ? col, SafeHtml headerHtml) {
-addColumn(col, new SafeHtmlHeader(headerHtml), null);
+insertColumn(getColumnCount(), col, headerHtml);
}
/**
- * Adds a column to the table with an associated String header and
footer.
+ * Adds a column to the end of the table with an associated String
header and
+ * footer.
*
* @param col the column to be added
* @param headerString the associated header text, as a String
@@ -684,12 +652,12 @@
*/
public void addColumn(ColumnT, ? col, String headerString,
String footerString) {
-addColumn(col, new TextHeader(headerString), new
TextHeader(footerString));
+insertColumn(getColumnCount(), col, headerString, footerString);
}
/**
- * Adds a column to the table with an associated {...@link SafeHtml} header
and
- * footer.
+ * Adds a column to the end of the table with an associated {...@link
SafeHtml}
+ * header and footer.
*
* @param col the column to be added
* @param headerHtml the associated header text, as
[gwt-contrib] [google-web-toolkit] r9356 committed - Fix external issues 5521, 5446, 5332, javadoc links...
Revision: 9356
Author: r...@google.com
Date: Fri Dec 3 07:31:58 2010
Log: Fix external issues 5521, 5446, 5332, javadoc links
Review at http://gwt-code-reviews.appspot.com/1186801
Review by: rchan...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=9356
Modified:
/trunk/user/src/com/google/gwt/dom/client/OptionElement.java
/trunk/user/src/com/google/gwt/dom/client/Touch.java
/trunk/user/src/com/google/gwt/event/dom/client/TouchEvent.java
/trunk/user/src/com/google/gwt/i18n/client/LocalizableResource.java
/trunk/user/src/com/google/gwt/i18n/client/Messages.java
/trunk/user/src/com/google/gwt/user/client/ui/ImageBundle.java
/trunk/user/src/com/google/gwt/user/server/rpc/RPCServletUtils.java
===
--- /trunk/user/src/com/google/gwt/dom/client/OptionElement.java Mon Jun 22
15:13:11 2009
+++ /trunk/user/src/com/google/gwt/dom/client/OptionElement.java Fri Dec 3
07:31:58 2010
@@ -124,7 +124,7 @@
* @see a
href=http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#adef-disabled;W3C
HTML Specification/a
*/
public final native void setDisabled(boolean disabled) /*-{
-return this.disabled = disabled;
+this.disabled = disabled;
}-*/;
/**
@@ -133,7 +133,7 @@
* @see a
href=http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#adef-label-OPTION;W3C
HTML Specification/a
*/
public final native void setLabel(String label) /*-{
-return this.label = label;
+this.label = label;
}-*/;
/**
===
--- /trunk/user/src/com/google/gwt/dom/client/Touch.java Tue Nov 23
11:35:12 2010
+++ /trunk/user/src/com/google/gwt/dom/client/Touch.java Fri Dec 3
07:31:58 2010
@@ -20,7 +20,7 @@
/**
* Class representing touches.
*
- * @see
http://developer.apple.com/library/safari/#documentation/UserExperience/Reference/TouchClassReference/Touch/Touch.html
+ * See {...@link a
href=http://developer.apple.com/library/safari/#documentation/UserExperience/Reference/TouchClassReference/Touch/Touch.html;Safari
Touch Documentation/a}
*/
public class Touch extends JavaScriptObject {
===
--- /trunk/user/src/com/google/gwt/event/dom/client/TouchEvent.java Tue Nov
23 11:35:12 2010
+++ /trunk/user/src/com/google/gwt/event/dom/client/TouchEvent.java Fri
Dec 3 07:31:58 2010
@@ -22,8 +22,7 @@
/**
* Abstract class representing touch events.
*
- * @see
http://developer.apple.com/library/safari/documentation/UserExperience/Reference/TouchEventClassReference/TouchEvent/TouchEvent.html
- *
+ * See {...@link a
href=http://developer.apple.com/library/safari/documentation/UserExperience/Reference/TouchEventClassReference/TouchEvent/TouchEvent.html;Safari
Touch Event Documentation/a}
* @param H handler type
*/
public abstract class TouchEventH extends EventHandler
===
--- /trunk/user/src/com/google/gwt/i18n/client/LocalizableResource.java Mon
Mar 2 23:51:53 2009
+++ /trunk/user/src/com/google/gwt/i18n/client/LocalizableResource.java Fri
Dec 3 07:31:58 2010
@@ -157,7 +157,7 @@
/**
* The key used for lookup of translated strings. If not present, the
- * key will be generated based on the {...@code @GenerateKeysUsing}
annotation,
+ * key will be generated based on the {...@code @GenerateKeys} annotation,
* or the unqualified method name if it is not present.
*/
@Retention(RetentionPolicy.RUNTIME)
===
--- /trunk/user/src/com/google/gwt/i18n/client/Messages.java Tue Oct 5
11:03:13 2010
+++ /trunk/user/src/com/google/gwt/i18n/client/Messages.java Fri Dec 3
07:31:58 2010
@@ -29,7 +29,7 @@
* extends codeMessages/code returns an instance of an automatically
* generated subclass that is implemented using message templates selected
based
* on locale. Message templates are based on a subset of the format used
by a
- *
href=http://java.sun.com/j2se/1.5.0/docs/api/java/text/MessageFormat.html;
+ *
href=http://download.oracle.com/javase/1.5.0/docs/api/java/text/MessageFormat.html;
* codeMessageFormat/code/a. Note in particular that single quotes
are
* used to quote other characters, and should be doubled for a literal
single
* quote.
===
--- /trunk/user/src/com/google/gwt/user/client/ui/ImageBundle.java Fri Mar
19 08:12:41 2010
+++ /trunk/user/src/com/google/gwt/user/client/ui/ImageBundle.java Fri Dec
3 07:31:58 2010
@@ -43,7 +43,7 @@
* codegif/code, or codejpg/code. If the image name contains '/'
* characters, it is assumed to be the name of a resource on the classpath,
* formatted as would be expected by code
- * a
href=http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)ClassLoader.getResource(String)/a.
+ * a
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
making it a class instead of an interface means we can't mock it anymore. On Thu, Dec 2, 2010 at 10:55 PM, Ray Ryan rj...@google.com wrote: We're making a few breaking changes in 2.1.1 to the new features introduced in 2.1. (We're not supposed to do that kind of thing, but are hoping to get away with it in this quick follow up release before there is much adoption.) I'd like to add a change to Activity to that list, in order to allow it to evolve in later releases when breakage of any kind won't be an option: I'd like to make Activity an abstract class instead of an interface, basically rename AbstractActivity. Any objections? rjrjr -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
Any part of my point is that making sure it remains a trivial class with only no-ops means you don't need to mock it. Is that a reasonable assumption? On Fri, Dec 3, 2010 at 11:11 AM, Patrick Julien pjul...@gmail.com wrote: making it a class instead of an interface means we can't mock it anymore. On Thu, Dec 2, 2010 at 10:55 PM, Ray Ryan rj...@google.com wrote: We're making a few breaking changes in 2.1.1 to the new features introduced in 2.1. (We're not supposed to do that kind of thing, but are hoping to get away with it in this quick follow up release before there is much adoption.) I'd like to add a change to Activity to that list, in order to allow it to evolve in later releases when breakage of any kind won't be an option: I'd like to make Activity an abstract class instead of an interface, basically rename AbstractActivity. Any objections? rjrjr -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
I don't know since I don't know what your plans are, will just have to trust you. That being said, the Activity interface is currently really nice and it doesn't tie us down to a single class for inheritance. On Fri, Dec 3, 2010 at 2:20 PM, Ray Ryan rj...@google.com wrote: Any part of my point is that making sure it remains a trivial class with only no-ops means you don't need to mock it. Is that a reasonable assumption? On Fri, Dec 3, 2010 at 11:11 AM, Patrick Julien pjul...@gmail.com wrote: making it a class instead of an interface means we can't mock it anymore. On Thu, Dec 2, 2010 at 10:55 PM, Ray Ryan rj...@google.com wrote: We're making a few breaking changes in 2.1.1 to the new features introduced in 2.1. (We're not supposed to do that kind of thing, but are hoping to get away with it in this quick follow up release before there is much adoption.) I'd like to add a change to Activity to that list, in order to allow it to evolve in later releases when breakage of any kind won't be an option: I'd like to make Activity an abstract class instead of an interface, basically rename AbstractActivity. Any objections? rjrjr -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
On Fri, Dec 3, 2010 at 2:58 PM, Patrick Julien pjul...@gmail.com wrote: I don't know since I don't know what your plans are, will just have to trust you. That being said, the Activity interface is currently really nice and it doesn't tie us down to a single class for inheritance. I have been very happy with the recent cases where I have used an interface for the API but provided a default implementation, with the admonishment that implementing the interface without extending the default implementation is likely to be broken in the future. That way the people that care more about being able to substitute alternate implementations or to use it without having to extend the implementation can implement the interface, and those that care more about not being broken by future updates can extend the default implementation. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
This is more in line with what we're doing. With what we experienced with the ramp up to 2.1.0, we only use the Activity interface, we don't use the default implementation and instead make our own for common classes of use cases. On Fri, Dec 3, 2010 at 3:02 PM, John Tamplin j...@google.com wrote: On Fri, Dec 3, 2010 at 2:58 PM, Patrick Julien pjul...@gmail.com wrote: I don't know since I don't know what your plans are, will just have to trust you. That being said, the Activity interface is currently really nice and it doesn't tie us down to a single class for inheritance. I have been very happy with the recent cases where I have used an interface for the API but provided a default implementation, with the admonishment that implementing the interface without extending the default implementation is likely to be broken in the future. That way the people that care more about being able to substitute alternate implementations or to use it without having to extend the implementation can implement the interface, and those that care more about not being broken by future updates can extend the default implementation. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
Patrick, you're the case in point. Because you don't use the abstract class, if we change the API later we will break your app. Were you unable to use the abstract class? If the Activity interface were documented to encourage you to do so, would you have? When we break your app, will you be okay with that? On Fri, Dec 3, 2010 at 12:13 PM, Patrick Julien pjul...@gmail.com wrote: This is more in line with what we're doing. With what we experienced with the ramp up to 2.1.0, we only use the Activity interface, we don't use the default implementation and instead make our own for common classes of use cases. On Fri, Dec 3, 2010 at 3:02 PM, John Tamplin j...@google.com wrote: On Fri, Dec 3, 2010 at 2:58 PM, Patrick Julien pjul...@gmail.com wrote: I don't know since I don't know what your plans are, will just have to trust you. That being said, the Activity interface is currently really nice and it doesn't tie us down to a single class for inheritance. I have been very happy with the recent cases where I have used an interface for the API but provided a default implementation, with the admonishment that implementing the interface without extending the default implementation is likely to be broken in the future. That way the people that care more about being able to substitute alternate implementations or to use it without having to extend the implementation can implement the interface, and those that care more about not being broken by future updates can extend the default implementation. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Undeprecate HandlerManager and TabPanel, neither of which is quite (issue1187801)
LGTM Just curious why we need to @SuppressWarnings in HandlerManager http://gwt-code-reviews.appspot.com/1187801/diff/1/2 File user/src/com/google/gwt/event/shared/HandlerManager.java (right): http://gwt-code-reviews.appspot.com/1187801/diff/1/2#newcode57 user/src/com/google/gwt/event/shared/HandlerManager.java:57: @SuppressWarnings(deprecation) Why is the suppresswarning needed? http://gwt-code-reviews.appspot.com/1187801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
I don't know what features are planned or contemplated beyond what Neil mentioned, but could the use of sub-interfaces help? For example, Neil's feature (+1 BTW) might use a PlaceAwareActivity which extends Activity? AbstractActivity can potentially implement them all new sub-interfaces. The downside being that other framework classes, such as ActivityManager would be littered with instanceof checks. - Amir On Fri, Dec 3, 2010 at 12:18 PM, Ray Ryan rj...@google.com wrote: Patrick, you're the case in point. Because you don't use the abstract class, if we change the API later we will break your app. Were you unable to use the abstract class? If the Activity interface were documented to encourage you to do so, would you have? When we break your app, will you be okay with that? On Fri, Dec 3, 2010 at 12:13 PM, Patrick Julien pjul...@gmail.com wrote: This is more in line with what we're doing. With what we experienced with the ramp up to 2.1.0, we only use the Activity interface, we don't use the default implementation and instead make our own for common classes of use cases. On Fri, Dec 3, 2010 at 3:02 PM, John Tamplin j...@google.com wrote: On Fri, Dec 3, 2010 at 2:58 PM, Patrick Julien pjul...@gmail.com wrote: I don't know since I don't know what your plans are, will just have to trust you. That being said, the Activity interface is currently really nice and it doesn't tie us down to a single class for inheritance. I have been very happy with the recent cases where I have used an interface for the API but provided a default implementation, with the admonishment that implementing the interface without extending the default implementation is likely to be broken in the future. That way the people that care more about being able to substitute alternate implementations or to use it without having to extend the implementation can implement the interface, and those that care more about not being broken by future updates can extend the default implementation. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
One more question for Patrick: would you be better able to use AbstractActivity if the IsActivity interface were available? On Fri, Dec 3, 2010 at 12:18 PM, Ray Ryan rj...@google.com wrote: Patrick, you're the case in point. Because you don't use the abstract class, if we change the API later we will break your app. Were you unable to use the abstract class? If the Activity interface were documented to encourage you to do so, would you have? When we break your app, will you be okay with that? On Fri, Dec 3, 2010 at 12:13 PM, Patrick Julien pjul...@gmail.com wrote: This is more in line with what we're doing. With what we experienced with the ramp up to 2.1.0, we only use the Activity interface, we don't use the default implementation and instead make our own for common classes of use cases. On Fri, Dec 3, 2010 at 3:02 PM, John Tamplin j...@google.com wrote: On Fri, Dec 3, 2010 at 2:58 PM, Patrick Julien pjul...@gmail.com wrote: I don't know since I don't know what your plans are, will just have to trust you. That being said, the Activity interface is currently really nice and it doesn't tie us down to a single class for inheritance. I have been very happy with the recent cases where I have used an interface for the API but provided a default implementation, with the admonishment that implementing the interface without extending the default implementation is likely to be broken in the future. That way the people that care more about being able to substitute alternate implementations or to use it without having to extend the implementation can implement the interface, and those that care more about not being broken by future updates can extend the default implementation. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Undeprecate HandlerManager and TabPanel, neither of which is quite (issue1187801)
Various package private methods on SimpleEventBus exist only for legacy support for HandlerManager, and are deprecated. I don't want new code calling them. On Fri, Dec 3, 2010 at 12:22 PM, jlaba...@google.com wrote: LGTM Just curious why we need to @SuppressWarnings in HandlerManager http://gwt-code-reviews.appspot.com/1187801/diff/1/2 File user/src/com/google/gwt/event/shared/HandlerManager.java (right): http://gwt-code-reviews.appspot.com/1187801/diff/1/2#newcode57 user/src/com/google/gwt/event/shared/HandlerManager.java:57: @SuppressWarnings(deprecation) Why is the suppresswarning needed? http://gwt-code-reviews.appspot.com/1187801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
On Fri, Dec 3, 2010 at 3:18 PM, Ray Ryan rj...@google.com wrote: Patrick, you're the case in point. Because you don't use the abstract class, if we change the API later we will break your app. I guess I don't understand how you're making it better then. I'm currently working on Android and I have two problems that I hope won't be introduced in GWT: 1. The activity class is huge. Anything that doesn't seem to fit somewhere else either goes in Context or Activity (with Activity inheriting from Context) 2. Activity isn't Guice friendly because the framework creates activities for you, we don't get absolute control of the ctors. It's driving me insane. It's nice we don't have to worry about creating activities and other system level objects but kind of sucks that we can't get any kind of support beyond that. Your argument about keeping the class simple helps reassure #1 won't come true... for now at least, I'm more worried about the implications of someone else becoming the steward of such a class. I can only hope #2 will remain like it is now in GWT and not like Android. Were you unable to use the abstract class? If the Activity interface were documented to encourage you to do so, would you have? When we break your app, will you be okay with that? The abstract class didn't provide anything useful so multiple abstract base classes were made. In all, I have list, detail and edit abstract base activities and each define a view interface. Each of those scenarios provided a better, more suitably precise implementation than what's already in AbstractActivity. So even if you add breaking changes to Activity here, and I'm assuming by changes, you mean new methods with a default implementation, otherwise an abstract class wouldn't do much better, I have at most 3 classes to fix. All other activities are rooted in one of those 3 and are pretty light. But again, I wanted to voice my concern, not really trying to change the tide. I don't really mind Activity becoming a class under the conditions you mentioned. At first, I was just a little bit worried of getting something that, sooner or later, would match the stature of android's activity class. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
On Fri, Dec 3, 2010 at 3:35 PM, Ray Ryan rj...@google.com wrote: One more question for Patrick: would you be better able to use AbstractActivity if the IsActivity interface were available? I don't want to speak for anybody else but not to me no. What AbstractActivity provides is so little that it's either sufficient or not. In my case, it's not. Introducing IsActivity doesn't make it any more useful to me. For list and edit, you can edit, so we need to take charge of all the Activity entry point in order to provide the user with a message about discarding changes. For details, it's fine, but it hasn't really saved us much now has it? I'm just surprised that you would want to make it an abstract class. If we were to re-live the gwt 2.1.0 development cycle, I would have to say that the activity package of classes was one of the most volatile out there. Why? Because making an activity that is both useful and generic for everyone out there is extremely hard and complex. AbstractActivity is certainly generic enough for everyone but how useful is it in its current implementation? If you want to improve on that, great, but how much experimentation would be involved in such a process? I'm just saying that anything added to an abstract Activity that works for all GWT users/applications would have to be out of this world crazy good or be benign like it currently is. That being said, I don't know what new additions you're planning. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adding methods to insert columns, get the column count, and get columns by index in a CellTable.... (issue1181801)
committed as r9355
http://gwt-code-reviews.appspot.com/1181801/diff/1/2
File user/src/com/google/gwt/user/cellview/client/CellTable.java
(right):
http://gwt-code-reviews.appspot.com/1181801/diff/1/2#newcode599
user/src/com/google/gwt/user/cellview/client/CellTable.java:599: public
void addColumn(ColumnT, ? col) {
On 2010/12/02 22:11:08, sbrubaker wrote:
Nit: Can we differentiate in the comments between functions named
addColumn
(which add the column to the end) and functions named insertColumn,
which allow
the user to indicate where to insert the column? It's not obvious
from the
existing comments.
Done.
http://gwt-code-reviews.appspot.com/1181801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Update MissingPlugin.html to reflect new Chrome platform support (issue1184801)
On 2010/12/03 00:21:35, conroy wrote: ping! i was hoping to push this today... http://gwt-code-reviews.appspot.com/1184801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Update MissingPlugin.html to reflect new Chrome platform support (issue1184801)
LGTM http://gwt-code-reviews.appspot.com/1184801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Rolling back r9354 due to some GWTTestCase breakages (issue1188801)
Reviewers: scottb, rjrjr,
Description:
Rolling back r9354 due to some GWTTestCase breakages
Please review this at http://gwt-code-reviews.appspot.com/1188801/show
Affected files:
M dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
Index: dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
===
--- dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
(revision 9356)
+++ dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
(working copy)
@@ -1018,7 +1018,10 @@
// Get the bytes, compiling if necessary.
byte[] classBytes = findClassBytes(className);
-
+if (classBytes == null) {
+ throw new ClassNotFoundException(className);
+}
+
if (HasAnnotation.hasAnnotation(classBytes, GwtScriptOnly.class)) {
scriptOnlyClasses.add(className);
maybeInitializeScriptOnlyClassLoader();
@@ -1110,7 +1113,7 @@
}
@SuppressWarnings(deprecation)
- private byte[] findClassBytes(String className) throws
ClassNotFoundException {
+ private byte[] findClassBytes(String className) {
if (JavaScriptHost.class.getName().equals(className)) {
// No need to rewrite.
return javaScriptHostBytes;
@@ -1133,12 +1136,6 @@
CompilationUnit unit = (compiledClass == null)
? getUnitForClassName(lookupClassName) : compiledClass.getUnit();
-
-if (unit != null unit.isError()) {
- throw new ClassNotFoundException(Cannot load class + className
- + because it has errors.);
-}
-
if (emmaAvailable) {
/*
* build the map for anonymous classes. Do so only if unit has
anonymous
@@ -1151,10 +1148,11 @@
unit.hasAnonymousClasses() jsniMethods != null
jsniMethods.size() 0 !unit.createdClassMapping()) {
if (!unit.constructAnonymousClassMappings(logger)) {
- throw new ClassNotFoundException(
+ logger.log(TreeLogger.ERROR,
Our heuristic for mapping anonymous classes between
compilers
+ failed. Unsafe to continue because the wrong jsni
code
+ could end up running. className = + className);
+ return null;
}
}
}
@@ -1200,10 +1198,6 @@
}
}
classBytes = newBytes;
-}
-
-if (classBytes == null) {
- throw new ClassNotFoundException(className);
}
return classBytes;
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Rolling back r9354 due to some GWTTestCase breakages (issue1188801)
LGTM
On Fri, Dec 3, 2010 at 3:57 PM, con...@google.com wrote:
Reviewers: scottb, rjrjr,
Description:
Rolling back r9354 due to some GWTTestCase breakages
Please review this at http://gwt-code-reviews.appspot.com/1188801/show
Affected files:
M dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
Index: dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
===
--- dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
(revision 9356)
+++ dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
(working copy)
@@ -1018,7 +1018,10 @@
// Get the bytes, compiling if necessary.
byte[] classBytes = findClassBytes(className);
-
+if (classBytes == null) {
+ throw new ClassNotFoundException(className);
+}
+
if (HasAnnotation.hasAnnotation(classBytes, GwtScriptOnly.class)) {
scriptOnlyClasses.add(className);
maybeInitializeScriptOnlyClassLoader();
@@ -1110,7 +1113,7 @@
}
@SuppressWarnings(deprecation)
- private byte[] findClassBytes(String className) throws
ClassNotFoundException {
+ private byte[] findClassBytes(String className) {
if (JavaScriptHost.class.getName().equals(className)) {
// No need to rewrite.
return javaScriptHostBytes;
@@ -1133,12 +1136,6 @@
CompilationUnit unit = (compiledClass == null)
? getUnitForClassName(lookupClassName) : compiledClass.getUnit();
-
-if (unit != null unit.isError()) {
- throw new ClassNotFoundException(Cannot load class + className
- + because it has errors.);
-}
-
if (emmaAvailable) {
/*
* build the map for anonymous classes. Do so only if unit has
anonymous
@@ -1151,10 +1148,11 @@
unit.hasAnonymousClasses() jsniMethods != null
jsniMethods.size() 0 !unit.createdClassMapping()) {
if (!unit.constructAnonymousClassMappings(logger)) {
- throw new ClassNotFoundException(
+ logger.log(TreeLogger.ERROR,
Our heuristic for mapping anonymous classes between
compilers
+ failed. Unsafe to continue because the wrong jsni code
+ could end up running. className = + className);
+ return null;
}
}
}
@@ -1200,10 +1198,6 @@
}
}
classBytes = newBytes;
-}
-
-if (classBytes == null) {
- throw new ClassNotFoundException(className);
}
return classBytes;
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Modifications to StackTraceDeobfuscator: (issue1189801)
Reviewers: unnurg, Description: Modifications to StackTraceDeobfuscator: - Introduces a new protected method, getSymbolMapInputStream(), to obtain a symbol map InputStream for a given permutation strong name, to be overridden by subclasses. - Makes the deobfuscateStackTrace() convenience method public - Multiple lookups for a given permutations's, non-existent or broken, symbol map file no longer results in repeated attempt to access or parse the file - Javadoc additions Please review this at http://gwt-code-reviews.appspot.com/1189801/show Affected files: M user/src/com/google/gwt/logging/server/StackTraceDeobfuscator.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Modifications to StackTraceDeobfuscator: (issue1189801)
http://gwt-code-reviews.appspot.com/1189801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
