[gwt-contrib] Add java.math and java.util.logging to list of packages to document (issue1358802)
Reviewers: jat,
Description:
Add java.math and java.util.logging to list of packages to document
Please review this at http://gwt-code-reviews.appspot.com/1358802/show
Affected files:
M build-tools/doctool/src/com/google/doctool/custom/FindPackages.java
Index: build-tools/doctool/src/com/google/doctool/custom/FindPackages.java
===
--- build-tools/doctool/src/com/google/doctool/custom/FindPackages.java
(revision 9736)
+++ build-tools/doctool/src/com/google/doctool/custom/FindPackages.java
(working copy)
@@ -52,7 +52,7 @@
* the LANG_PKGS property. Add packages here as needed.
*/
private static final String[] LANG_PKGS = {
- java.lang, java.lang.annotation, java.io, java.sql, java.util};
+java.lang, java.lang.annotation, java.math, java.io, java.sql,
java.util, java.util.logging};
/**
* User packages to include, regardless of exclusions. Add packages here
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add java.math and java.util.logging to list of packages to document (issue1358802)
LGTM http://gwt-code-reviews.appspot.com/1358802/diff/1/2 File build-tools/doctool/src/com/google/doctool/custom/FindPackages.java (right): http://gwt-code-reviews.appspot.com/1358802/diff/1/2#newcode51 build-tools/doctool/src/com/google/doctool/custom/FindPackages.java:51: * A list of emulated packages under java.lang, to be emitted as I assume this comment is incorrect and the output is as expected -- if so, please change the comment. http://gwt-code-reviews.appspot.com/1358802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add java.math and java.util.logging to list of packages to document (issue1358802)
http://gwt-code-reviews.appspot.com/1358802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Fixing HTMLTable#setWidget() to remove the widget or text when null is passed as the widget. Cu... (issue1358803)
Reviewers: rjrjr,
Description:
Fixing HTMLTable#setWidget() to remove the widget or text when null is
passed as the widget. Currently, the widget is not removed.
Please review this at http://gwt-code-reviews.appspot.com/1358803/show
Affected files:
M user/src/com/google/gwt/user/client/ui/HTMLTable.java
M user/test/com/google/gwt/user/client/ui/HTMLTableTestBase.java
Index: user/src/com/google/gwt/user/client/ui/HTMLTable.java
===
--- user/src/com/google/gwt/user/client/ui/HTMLTable.java (revision 9736)
+++ user/src/com/google/gwt/user/client/ui/HTMLTable.java (working copy)
@@ -1091,18 +1091,19 @@
* within the Grid's bounding box.
* /p
*
- * @param widget The widget to be added
+ * @param widget The widget to be added, or null to clear the cell
* @param row the cell's row
* @param column the cell's column
* @throws IndexOutOfBoundsException
*/
public void setWidget(int row, int column, Widget widget) {
prepareCell(row, column);
+
+// Removes any existing widget.
+Element td = cleanCell(row, column, true);
+
if (widget != null) {
widget.removeFromParent();
-
- // Removes any existing widget.
- Element td = cleanCell(row, column, true);
// Logical attach.
widgetMap.put(widget);
Index: user/test/com/google/gwt/user/client/ui/HTMLTableTestBase.java
===
--- user/test/com/google/gwt/user/client/ui/HTMLTableTestBase.java
(revision 9736)
+++ user/test/com/google/gwt/user/client/ui/HTMLTableTestBase.java (working
copy)
@@ -241,6 +241,29 @@
formatter.setWidth(0, 2, 100%);
}
+ public void testSetWidgetNull() {
+HTMLTable t = getTable(1, 2);
+
+// Set some text and a widget.
+Label content = new Label(widget);
+t.setText(0, 0, hello world);
+t.setWidget(0, 1, content);
+assertEquals(hello world, t.getText(0, 0));
+assertEquals(content, t.getWidget(0, 1));
+
+// Set the text cell to a null widget.
+t.setWidget(0, 0, null);
+assertEquals(text should be cleared when the widget is set to
null, ,
+t.getText(0, 0));
+assertEquals(widget should be cleared when set to null, content,
+t.getWidget(0, 1));
+
+// Set the widget cell to a null widget.
+t.setWidget(0, 1, null);
+assertEquals(, t.getText(0, 0));
+assertNull(t.getWidget(0, 1));
+ }
+
public void testSafeHtml() {
HTMLTable table = getTable(1, 1);
table.setHTML(0, 0, SafeHtmlUtils.fromSafeConstant(html));
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fixing HTMLTable#setWidget() to remove the widget or text when null is passed as the widget. Cu... (issue1358803)
LGTM http://gwt-code-reviews.appspot.com/1358803/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Initial add of JSON-RPC support to RequestFactory. (issue1355804)
LGTM
http://gwt-code-reviews.appspot.com/1355804/diff/1/3
File user/src/com/google/gwt/autobean/shared/AutoBeanCodex.java (right):
http://gwt-code-reviews.appspot.com/1355804/diff/1/3#newcode432
user/src/com/google/gwt/autobean/shared/AutoBeanCodex.java:432: public
static void decodeInto(Splittable data, AutoBean? bean) {
Yaay!
http://gwt-code-reviews.appspot.com/1355804/diff/1/4
File user/src/com/google/gwt/autobean/shared/ValueCodex.java (right):
http://gwt-code-reviews.appspot.com/1355804/diff/1/4#newcode91
user/src/com/google/gwt/autobean/shared/ValueCodex.java:91: public Date
decode(Class? clazz, String value) {
format
http://gwt-code-reviews.appspot.com/1355804/diff/1/4#newcode95
user/src/com/google/gwt/autobean/shared/ValueCodex.java:95: // XXX
Figure out how to decode iso 8601 dates in compatible manner
Is that really possible? Should we just declare this as a limitation of
the framework, that dates are longs and such is life? Or is iso 8601
part of the json rpc spec?
http://gwt-code-reviews.appspot.com/1355804/diff/1/7
File
user/src/com/google/gwt/requestfactory/rebind/model/RequestFactoryModel.java
(right):
http://gwt-code-reviews.appspot.com/1355804/diff/1/7#newcode351
user/src/com/google/gwt/requestfactory/rebind/model/RequestFactoryModel.java:351:
methodBuilder.addExtraSetter(maybeSetter);
Should you be posting an error here if the dialect is standard?
http://gwt-code-reviews.appspot.com/1355804/diff/1/12
File user/src/com/google/gwt/requestfactory/shared/JsonRpcContent.java
(right):
http://gwt-code-reviews.appspot.com/1355804/diff/1/12#newcode26
user/src/com/google/gwt/requestfactory/shared/JsonRpcContent.java:26: *
REST-style request.
Not a rest style request
http://gwt-code-reviews.appspot.com/1355804/diff/1/17
File
user/src/com/google/gwt/requestfactory/shared/impl/AbstractRequestContext.java
(right):
http://gwt-code-reviews.appspot.com/1355804/diff/1/17#newcode91
user/src/com/google/gwt/requestfactory/shared/impl/AbstractRequestContext.java:91:
interface DialectImpl {
Can the DialectImpl's be broken out into their own files? Or are they
just too inner for that?
http://gwt-code-reviews.appspot.com/1355804/diff/1/17#newcode126
user/src/com/google/gwt/requestfactory/shared/impl/AbstractRequestContext.java:126:
request.setVersion(2.0);
What's the magic number about?
http://gwt-code-reviews.appspot.com/1355804/diff/1/17#newcode131
user/src/com/google/gwt/requestfactory/shared/impl/AbstractRequestContext.java:131:
for (Map.EntryString, Object entry :
data.getNamedParameters().entrySet()) {
I know this would be a step backward, and has nothing to do with this
patch, but let me get it off my chest:
I can't shake the feeling some size and performance issues might go away
if autobean could generate facades backed by jso objects, more in the
style of the bad old RF implementation. Do lazy reification in getters;
convert back to jso on set; that kind of thing. In theory you'd be ready
for a simple call to stringify at a moment's notice.
Horrible to debug and maintain, but now you have acres of unit tests to
keep you sane. Maybe it's time?
I suppose it wouldn't help with your plague-of-visitors issue. I guess
one question is how much of the burden is acres of getFoo and setBar
methods. Might such an approach eliminate some of the visitors?
There, I'm done.
http://gwt-code-reviews.appspot.com/1355804/diff/1/17#newcode192
user/src/com/google/gwt/requestfactory/shared/impl/AbstractRequestContext.java:192:
class StandardPayloadDialect implements DialectImpl {
Correct to presume that nothing changed here?
http://gwt-code-reviews.appspot.com/1355804/diff/1/20
File user/src/com/google/gwt/requestfactory/shared/impl/RequestData.java
(right):
http://gwt-code-reviews.appspot.com/1355804/diff/1/20#newcode114
user/src/com/google/gwt/requestfactory/shared/impl/RequestData.java:114:
* GET-style REST request.
not rest
http://gwt-code-reviews.appspot.com/1355804/diff/1/21
File
user/src/com/google/gwt/requestfactory/shared/messages/JsonRpcRequest.java
(right):
http://gwt-code-reviews.appspot.com/1355804/diff/1/21#newcode24
user/src/com/google/gwt/requestfactory/shared/messages/JsonRpcRequest.java:24:
*
doc
http://gwt-code-reviews.appspot.com/1355804/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Provides a CachedCompilationUnit class to serialize a CompilationUnit. (issue1357801)
http://gwt-code-reviews.appspot.com/1357801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Provides a CachedCompilationUnit class to serialize a CompilationUnit. (issue1357801)
updated patch http://gwt-code-reviews.appspot.com/1357801/diff/4002/1013 File dev/core/src/com/google/gwt/dev/javac/CachedCompilationUnit.java (right): http://gwt-code-reviews.appspot.com/1357801/diff/4002/1013#newcode41 dev/core/src/com/google/gwt/dev/javac/CachedCompilationUnit.java:41: private final transient String inputSource; On 2011/02/14 20:39:08, scottb wrote: I assume what you're trying to avoid here is double-caching the same source... it's just a bunch of needless work, right? But I think there's another way to get there I would consider adding an additional constructor that takes a 'sourceToken' parameter. Override SourceFileCompilationUnit.writeReplace() to use that constructor instead, and you can avoid the byte[] - String - byte[] conversions and allocations that are going to happen. For GeneratedCompilationUnit, you can do something similar EXCEPT that currently, GeneratedUnitImpl uses a different instance of DiskCache, so you can't just copy the token. You'd need to do one of these things: a) Read GeneratedUnitImpl.cacheToken as bytes (to avoid the String conversion) and then write it back as bytes into the new cache. (When you later read it out as String, it works just fine.) b) Create a static singleton DiskCache that everyone shares, DiskCache.get() or DiskCache.INSTANCE or whatever. Have (at least) StandardGeneratorContext and CompilationUnit use the singleton DiskCache instance (maybe everyone should use it). c) Refactor diskCache to pass an object around instead of a long. The object would know what cache it came from. There are some interesting things we could do with this kind of implementation, such as GCing stuff that's no longer referenced. I chose to unify all instances of DiskCache into one (save in the unit test). Then I modified GeneratedUnit with an interface to fetch the disk cache token. http://gwt-code-reviews.appspot.com/1357801/diff/4002/1013#newcode59 dev/core/src/com/google/gwt/dev/javac/CachedCompilationUnit.java:59: this.problems = unit.getProblems(); On 2011/02/14 20:39:08, scottb wrote: Need to convert these to SerializableCategorizedProblems? Done. http://gwt-code-reviews.appspot.com/1357801/diff/4002/1016 File dev/core/src/com/google/gwt/dev/javac/Dependencies.java (right): http://gwt-code-reviews.appspot.com/1357801/diff/4002/1016#newcode132 dev/core/src/com/google/gwt/dev/javac/Dependencies.java:132: qualified.put(qualifiedRef, new DirectRef(null)); On 2011/02/14 20:39:08, scottb wrote: Might be simpler to just initialize a null value here and make DirectRef itself never contain null. Its not necessarily simpler because I had to put in more null checks, but making a DirectRef with no class is kind of pointless. Done. http://gwt-code-reviews.appspot.com/1357801/diff/4002/1016#newcode216 dev/core/src/com/google/gwt/dev/javac/Dependencies.java:216: private void readObject(ObjectInputStream inputStream) On 2011/02/14 20:39:08, scottb wrote: Kill this and writeObject, no need for custom serialization. Done. http://gwt-code-reviews.appspot.com/1357801/diff/4002/1016#newcode246 dev/core/src/com/google/gwt/dev/javac/Dependencies.java:246: Ref myRef = entry.getValue(); On 2011/02/14 20:39:08, scottb wrote: The logic flow seems a bit more complicated here, especially since a SerializedRef always returns null for a compiled class, so that the initial null == null test never works. If you go with the idea of a null Ref to denote a reference to nothing, you can essentially leave this method alone and just change structurallySame to take Ref mine and do a dynamic instanceof internally. It would also let you get rid of Ref.getCompiledClass() which only makes sense for a DirectRef. Done. http://gwt-code-reviews.appspot.com/1357801/diff/4002/1017 File dev/core/src/com/google/gwt/dev/javac/GWTProblem.java (right): http://gwt-code-reviews.appspot.com/1357801/diff/4002/1017#newcode89 dev/core/src/com/google/gwt/dev/javac/GWTProblem.java:89: return new SerializableCategorizedProblem(this); On 2011/02/14 20:39:08, scottb wrote: HelpInfo gets lost if you do this. Maybe just make GWTProblem extend SerializableCategorizedProblem? I did this, but I kind of cheated and instantiated DefaultProblem first to do the hard work of formatting the problem. http://gwt-code-reviews.appspot.com/1357801/diff/4002/1021 File dev/core/test/com/google/gwt/dev/javac/CompilationStateTest.java (right): http://gwt-code-reviews.appspot.com/1357801/diff/4002/1021#newcode338 dev/core/test/com/google/gwt/dev/javac/CompilationStateTest.java:338: deps.resolve(classMap); On 2011/02/14 20:39:08, scottb wrote: Actually, now that you've reimplemented Dependencies, we *don't* actually need to run resolve() anymore after deserialization, right? Done. http://gwt-code-reviews.appspot.com/1357801/diff/4002/1021#newcode349 dev/core/test/com/google/gwt/dev/javac/CompilationStateTest.java:349:
[gwt-contrib] [google-web-toolkit] r9737 committed - Fixing HTMLTable#setWidget() to remove the widget or text when null is...
Revision: 9737
Author: jlaba...@google.com
Date: Tue Feb 15 09:05:00 2011
Log: Fixing HTMLTable#setWidget() to remove the widget or text when null is
passed as the widget. Currently, the widget is not removed.
Review at http://gwt-code-reviews.appspot.com/1358803
Review by: rj...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=9737
Modified:
/trunk/user/src/com/google/gwt/user/client/ui/HTMLTable.java
/trunk/user/test/com/google/gwt/user/client/ui/HTMLTableTestBase.java
===
--- /trunk/user/src/com/google/gwt/user/client/ui/HTMLTable.java Tue Sep 21
07:53:19 2010
+++ /trunk/user/src/com/google/gwt/user/client/ui/HTMLTable.java Tue Feb 15
09:05:00 2011
@@ -1091,19 +1091,20 @@
* within the Grid's bounding box.
* /p
*
- * @param widget The widget to be added
+ * @param widget The widget to be added, or null to clear the cell
* @param row the cell's row
* @param column the cell's column
* @throws IndexOutOfBoundsException
*/
public void setWidget(int row, int column, Widget widget) {
prepareCell(row, column);
+
+// Removes any existing widget.
+Element td = cleanCell(row, column, true);
+
if (widget != null) {
widget.removeFromParent();
- // Removes any existing widget.
- Element td = cleanCell(row, column, true);
-
// Logical attach.
widgetMap.put(widget);
===
--- /trunk/user/test/com/google/gwt/user/client/ui/HTMLTableTestBase.java
Wed Jan 19 08:59:29 2011
+++ /trunk/user/test/com/google/gwt/user/client/ui/HTMLTableTestBase.java
Tue Feb 15 09:05:00 2011
@@ -240,6 +240,29 @@
formatter.setHorizontalAlignment(1, 1,
HasHorizontalAlignment.ALIGN_RIGHT);
formatter.setWidth(0, 2, 100%);
}
+
+ public void testSetWidgetNull() {
+HTMLTable t = getTable(1, 2);
+
+// Set some text and a widget.
+Label content = new Label(widget);
+t.setText(0, 0, hello world);
+t.setWidget(0, 1, content);
+assertEquals(hello world, t.getText(0, 0));
+assertEquals(content, t.getWidget(0, 1));
+
+// Set the text cell to a null widget.
+t.setWidget(0, 0, null);
+assertEquals(text should be cleared when the widget is set to
null, ,
+t.getText(0, 0));
+assertEquals(widget should be cleared when set to null, content,
+t.getWidget(0, 1));
+
+// Set the widget cell to a null widget.
+t.setWidget(0, 1, null);
+assertEquals(, t.getText(0, 0));
+assertNull(t.getWidget(0, 1));
+ }
public void testSafeHtml() {
HTMLTable table = getTable(1, 1);
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fixing HTMLTable#setWidget() to remove the widget or text when null is passed as the widget. Cu... (issue1358803)
committed as r9737 http://gwt-code-reviews.appspot.com/1358803/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Clean up warnings (issue1357807)
Thanks for cleaning this up. LGTM for the validation cod.e http://gwt-code-reviews.appspot.com/1357807/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
Reviewers: jat, fabiomfv, knorton,
Description:
Change the DevModeOptions page to use the xs linker due to recent Chrome
extension permissions changes
Please review this at http://gwt-code-reviews.appspot.com/1356803/show
Affected files:
M
plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml
M plugins/npapi/prebuilt/gwt-dev-plugin/manifest.json
Index:
plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml
===
---
plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml
(revision 9720)
+++
plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml
(working copy)
@@ -9,6 +9,7 @@
!-- TARGETING WEBKIT ONLY --
set-property name='user.agent' value='safari' /
+ add-linker name=xs /
!-- Specify the paths for translatable code--
source path='client'/
Index: plugins/npapi/prebuilt/gwt-dev-plugin/manifest.json
===
--- plugins/npapi/prebuilt/gwt-dev-plugin/manifest.json (revision 9720)
+++ plugins/npapi/prebuilt/gwt-dev-plugin/manifest.json (working copy)
@@ -1,6 +1,6 @@
{
name: GWT Developer Plugin,
- version: 1.0.9646,
+ version: 1.0.9737,
description: A plugin to enable debugging with GWT's Development
Mode,
update_url: https://dl-ssl.google.com/gwt/plugins/chrome/updates.xml;,
icons: {
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
lgtm and the horse I rode in on. http://gwt-code-reviews.appspot.com/1356803/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
http://gwt-code-reviews.appspot.com/1356803/diff/1/2 File plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml (right): http://gwt-code-reviews.appspot.com/1356803/diff/1/2#newcode12 plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml:12: add-linker name=xs / I think you want to use xsiframe instead, as it is intended to be the one-size-fits-all linker. Talk to unnurg if you have any difficulties using it instead. http://gwt-code-reviews.appspot.com/1356803/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
Sorry, didn't see your comment in time for the commit. I just used the same fix Kelly applied in SpeedTracer. I don't think it really matters strongly either way. On Tue, Feb 15, 2011 at 3:56 PM, j...@google.com wrote: http://gwt-code-reviews.appspot.com/1356803/diff/1/2 File plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml (right): http://gwt-code-reviews.appspot.com/1356803/diff/1/2#newcode12 plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml:12: add-linker name=xs / I think you want to use xsiframe instead, as it is intended to be the one-size-fits-all linker. Talk to unnurg if you have any difficulties using it instead. http://gwt-code-reviews.appspot.com/1356803/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
On Tue, Feb 15, 2011 at 4:03 PM, Chris Conroy con...@google.com wrote: Sorry, didn't see your comment in time for the commit. I just used the same fix Kelly applied in SpeedTracer. I don't think it really matters strongly either way. As I understand it, the xs linker will soon be deprecated since the xsiframe linker provides a superset of its functionality. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r9738 committed - Change the DevModeOptions page to use the xs linker due to recent Chro...
Revision: 9738
Author: con...@google.com
Date: Tue Feb 15 10:02:10 2011
Log: Change the DevModeOptions page to use the xs linker due to recent
Chrome extension permissions changes
Review at http://gwt-code-reviews.appspot.com/1356803
http://code.google.com/p/google-web-toolkit/source/detail?r=9738
Modified:
/trunk/plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml
/trunk/plugins/npapi/prebuilt/gwt-dev-plugin/manifest.json
/trunk/plugins/npapi/prebuilt/gwt-dev-plugin.crx
===
---
/trunk/plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml
Tue Nov 23 05:51:12 2010
+++
/trunk/plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml
Tue Feb 15 10:02:10 2011
@@ -9,6 +9,7 @@
!-- TARGETING WEBKIT ONLY --
set-property name='user.agent' value='safari' /
+ add-linker name=xs /
!-- Specify the paths for translatable code--
source path='client'/
===
--- /trunk/plugins/npapi/prebuilt/gwt-dev-plugin/manifest.json Fri Jan 28
05:16:50 2011
+++ /trunk/plugins/npapi/prebuilt/gwt-dev-plugin/manifest.json Tue Feb 15
10:02:10 2011
@@ -1,6 +1,6 @@
{
name: GWT Developer Plugin,
- version: 1.0.9646,
+ version: 1.0.9737,
description: A plugin to enable debugging with GWT's Development
Mode,
update_url: https://dl-ssl.google.com/gwt/plugins/chrome/updates.xml;,
icons: {
===
--- /trunk/plugins/npapi/prebuilt/gwt-dev-plugin.crx Fri Jan 28 05:16:50
2011
+++ /trunk/plugins/npapi/prebuilt/gwt-dev-plugin.crx Tue Feb 15 10:02:10
2011
Binary file, no diff available.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
All google3 projects are being switched to xsiframe in a few weeks (currently blocked by lack of a Blaze push). Deprecation/deletions of other linkers for regular GWT will soon follow, but to be honest, will be a GWT 3.0 thing at the very earliest. It's not a burning issue, but I do recommend that you do not switch to the xs linker at this point. It doesn't install in an iframe, and switching from being iframe installed vs. not has proven painful for some teams. Right now - if you're using the std linker (default), your compliant with being installed in an iframe, so if you start using xs, pick up some code dependencies that assume non-iframe, and then need to switch back to iframe based (xsiframe), you may see some issues. Or maybe not It's also possible that xs does not support DevMode - I can't remember off the top of my head. If you care about that, then xsiframe definitely does support it. - Unnur On Tue, Feb 15, 2011 at 1:09 PM, John Tamplin j...@google.com wrote: On Tue, Feb 15, 2011 at 4:03 PM, Chris Conroy con...@google.com wrote: Sorry, didn't see your comment in time for the commit. I just used the same fix Kelly applied in SpeedTracer. I don't think it really matters strongly either way. As I understand it, the xs linker will soon be deprecated since the xsiframe linker provides a superset of its functionality. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RequestFactory access from Android
Thanks Bob, do you mind if I file an issue to formally request this?
At this stage, I have it compiling but unable to parse requests on the server
On Tue, Feb 15, 2011 at 1:09 PM, BobV b...@google.com wrote:
RequestFactoryMagic works on Android, but you'll need to do some build
hacking to get RF it to compile against the Android SDK.
Here's what I did as an experiment:
1) Extract autobean/{shared, server}/** and requestfactory{shared,
server/testing}/** from gwt-user.jar.
1a) There are a few other build dependencies to tease out.
2) Write a RequestTransport that uses java.net.HttpUrlConnection or
the Apache HttpClient libs.
3) IIRC, there's one or two minor API incompatibilities in the
org.json APIs built into the ADK, but they're simple to fix.
Being able to put together a self-contained requestfactory-client.jar
would go a long way to improving code re-use for GWT devs who want
Android clients (and hopefully the other way around).
--
Bob Vawter
Google Web Toolkit Team
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
xsiframe is fine if it works. But you'll have to check it because these are not the normal xs restrictions. On Tue, Feb 15, 2011 at 4:28 PM, Unnur Gretarsdottir unn...@google.comwrote: All google3 projects are being switched to xsiframe in a few weeks (currently blocked by lack of a Blaze push). Deprecation/deletions of other linkers for regular GWT will soon follow, but to be honest, will be a GWT 3.0 thing at the very earliest. It's not a burning issue, but I do recommend that you do not switch to the xs linker at this point. It doesn't install in an iframe, and switching from being iframe installed vs. not has proven painful for some teams. Right now - if you're using the std linker (default), your compliant with being installed in an iframe, so if you start using xs, pick up some code dependencies that assume non-iframe, and then need to switch back to iframe based (xsiframe), you may see some issues. Or maybe not It's also possible that xs does not support DevMode - I can't remember off the top of my head. If you care about that, then xsiframe definitely does support it. - Unnur On Tue, Feb 15, 2011 at 1:09 PM, John Tamplin j...@google.com wrote: On Tue, Feb 15, 2011 at 4:03 PM, Chris Conroy con...@google.com wrote: Sorry, didn't see your comment in time for the commit. I just used the same fix Kelly applied in SpeedTracer. I don't think it really matters strongly either way. As I understand it, the xs linker will soon be deprecated since the xsiframe linker provides a superset of its functionality. -- John A. Tamplin Software Engineer (GWT), Google -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r9739 committed - Scratch that, use the xsiframe linker per jat's suggestion...
Revision: 9739
Author: gwt.mirror...@gmail.com
Date: Tue Feb 15 10:45:05 2011
Log: Scratch that, use the xsiframe linker per jat's suggestion
Review by: j...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=9739
Modified:
/trunk/plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml
/trunk/plugins/npapi/prebuilt/gwt-dev-plugin/manifest.json
/trunk/plugins/npapi/prebuilt/gwt-dev-plugin.crx
===
---
/trunk/plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml
Tue Feb 15 10:02:10 2011
+++
/trunk/plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml
Tue Feb 15 10:45:05 2011
@@ -9,7 +9,7 @@
!-- TARGETING WEBKIT ONLY --
set-property name='user.agent' value='safari' /
- add-linker name=xs /
+ add-linker name=xsiframe /
!-- Specify the paths for translatable code--
source path='client'/
===
--- /trunk/plugins/npapi/prebuilt/gwt-dev-plugin/manifest.json Tue Feb 15
10:02:10 2011
+++ /trunk/plugins/npapi/prebuilt/gwt-dev-plugin/manifest.json Tue Feb 15
10:45:05 2011
@@ -1,6 +1,6 @@
{
name: GWT Developer Plugin,
- version: 1.0.9737,
+ version: 1.0.9738,
description: A plugin to enable debugging with GWT's Development
Mode,
update_url: https://dl-ssl.google.com/gwt/plugins/chrome/updates.xml;,
icons: {
===
--- /trunk/plugins/npapi/prebuilt/gwt-dev-plugin.crx Tue Feb 15 10:02:10
2011
+++ /trunk/plugins/npapi/prebuilt/gwt-dev-plugin.crx Tue Feb 15 10:45:05
2011
Binary file, no diff available.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
Actually, it does work. On Tue, Feb 15, 2011 at 4:49 PM, Kelly Norton knor...@google.com wrote: I could be wrong, but I don't think the xsiframe linker is going to work here. On Tue, Feb 15, 2011 at 4:46 PM, Kelly Norton knor...@google.com wrote: xsiframe is fine if it works. But you'll have to check it because these are not the normal xs restrictions. On Tue, Feb 15, 2011 at 4:28 PM, Unnur Gretarsdottir unn...@google.com wrote: All google3 projects are being switched to xsiframe in a few weeks (currently blocked by lack of a Blaze push). Deprecation/deletions of other linkers for regular GWT will soon follow, but to be honest, will be a GWT 3.0 thing at the very earliest. It's not a burning issue, but I do recommend that you do not switch to the xs linker at this point. It doesn't install in an iframe, and switching from being iframe installed vs. not has proven painful for some teams. Right now - if you're using the std linker (default), your compliant with being installed in an iframe, so if you start using xs, pick up some code dependencies that assume non-iframe, and then need to switch back to iframe based (xsiframe), you may see some issues. Or maybe not It's also possible that xs does not support DevMode - I can't remember off the top of my head. If you care about that, then xsiframe definitely does support it. - Unnur On Tue, Feb 15, 2011 at 1:09 PM, John Tamplin j...@google.com wrote: On Tue, Feb 15, 2011 at 4:03 PM, Chris Conroy con...@google.com wrote: Sorry, didn't see your comment in time for the commit. I just used the same fix Kelly applied in SpeedTracer. I don't think it really matters strongly either way. As I understand it, the xs linker will soon be deprecated since the xsiframe linker provides a superset of its functionality. -- John A. Tamplin Software Engineer (GWT), Google -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
I actually don't have a really strong opinion here - if it's not easy and you guys want to punt on it for now, that's fine with me - we can deal with it, along with everything else, when the time comes. I would be curious as to why it won't work though, since we do, long term, want the xsiframe linker to meet all needs (with the exception of script tags in the gwt.xml), so it'd be good to be aware of what shortcomings it currently has. - Unnur On Tue, Feb 15, 2011 at 1:49 PM, Kelly Norton knor...@google.com wrote: I could be wrong, but I don't think the xsiframe linker is going to work here. On Tue, Feb 15, 2011 at 4:46 PM, Kelly Norton knor...@google.com wrote: xsiframe is fine if it works. But you'll have to check it because these are not the normal xs restrictions. On Tue, Feb 15, 2011 at 4:28 PM, Unnur Gretarsdottir unn...@google.com wrote: All google3 projects are being switched to xsiframe in a few weeks (currently blocked by lack of a Blaze push). Deprecation/deletions of other linkers for regular GWT will soon follow, but to be honest, will be a GWT 3.0 thing at the very earliest. It's not a burning issue, but I do recommend that you do not switch to the xs linker at this point. It doesn't install in an iframe, and switching from being iframe installed vs. not has proven painful for some teams. Right now - if you're using the std linker (default), your compliant with being installed in an iframe, so if you start using xs, pick up some code dependencies that assume non-iframe, and then need to switch back to iframe based (xsiframe), you may see some issues. Or maybe not It's also possible that xs does not support DevMode - I can't remember off the top of my head. If you care about that, then xsiframe definitely does support it. - Unnur On Tue, Feb 15, 2011 at 1:09 PM, John Tamplin j...@google.com wrote: On Tue, Feb 15, 2011 at 4:03 PM, Chris Conroy con...@google.com wrote: Sorry, didn't see your comment in time for the commit. I just used the same fix Kelly applied in SpeedTracer. I don't think it really matters strongly either way. As I understand it, the xs linker will soon be deprecated since the xsiframe linker provides a superset of its functionality. -- John A. Tamplin Software Engineer (GWT), Google -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
Awesome. good to know. I need to figure out how it manages to work. On Tue, Feb 15, 2011 at 4:52 PM, Chris Conroy con...@google.com wrote: Actually, it does work. On Tue, Feb 15, 2011 at 4:49 PM, Kelly Norton knor...@google.com wrote: I could be wrong, but I don't think the xsiframe linker is going to work here. On Tue, Feb 15, 2011 at 4:46 PM, Kelly Norton knor...@google.com wrote: xsiframe is fine if it works. But you'll have to check it because these are not the normal xs restrictions. On Tue, Feb 15, 2011 at 4:28 PM, Unnur Gretarsdottir unn...@google.com wrote: All google3 projects are being switched to xsiframe in a few weeks (currently blocked by lack of a Blaze push). Deprecation/deletions of other linkers for regular GWT will soon follow, but to be honest, will be a GWT 3.0 thing at the very earliest. It's not a burning issue, but I do recommend that you do not switch to the xs linker at this point. It doesn't install in an iframe, and switching from being iframe installed vs. not has proven painful for some teams. Right now - if you're using the std linker (default), your compliant with being installed in an iframe, so if you start using xs, pick up some code dependencies that assume non-iframe, and then need to switch back to iframe based (xsiframe), you may see some issues. Or maybe not It's also possible that xs does not support DevMode - I can't remember off the top of my head. If you care about that, then xsiframe definitely does support it. - Unnur On Tue, Feb 15, 2011 at 1:09 PM, John Tamplin j...@google.com wrote: On Tue, Feb 15, 2011 at 4:03 PM, Chris Conroy con...@google.com wrote: Sorry, didn't see your comment in time for the commit. I just used the same fix Kelly applied in SpeedTracer. I don't think it really matters strongly either way. As I understand it, the xs linker will soon be deprecated since the xsiframe linker provides a superset of its functionality. -- John A. Tamplin Software Engineer (GWT), Google -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Provides a CachedCompilationUnit class to serialize a CompilationUnit. (issue1357801)
Sweet, I think we're almost there. Mostly nits.
http://gwt-code-reviews.appspot.com/1357801/diff/4002/1014
File dev/core/src/com/google/gwt/dev/javac/CompilationUnit.java (right):
http://gwt-code-reviews.appspot.com/1357801/diff/4002/1014#newcode341
dev/core/src/com/google/gwt/dev/javac/CompilationUnit.java:341: }
Rather than deleting it, I would leave it as abstract to force
subclasses to implement it.
http://gwt-code-reviews.appspot.com/1357801/diff/4002/1021
File dev/core/test/com/google/gwt/dev/javac/CompilationStateTest.java
(right):
http://gwt-code-reviews.appspot.com/1357801/diff/4002/1021#newcode526
dev/core/test/com/google/gwt/dev/javac/CompilationStateTest.java:526:
String f2 = parseJs(function() + jsniFunction.getBody().toSource());
What I meant involved parsing 'expected' as a block rather than a
function, but no big deal.
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1028
File dev/core/src/com/google/gwt/dev/javac/CachedCompilationUnit.java
(right):
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1028#newcode44
dev/core/src/com/google/gwt/dev/javac/CachedCompilationUnit.java:44:
private transient byte[] sourceCode = null;
Can we just keep sourceToken and kill the other two source fields? It's
simpler and ensures lowest memory use. The 1-arg constructor can just
call this(unit, diskCache.writeString(unit.getSource()));
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1031
File dev/core/src/com/google/gwt/dev/javac/CompiledClass.java (right):
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1031#newcode101
dev/core/src/com/google/gwt/dev/javac/CompiledClass.java:101: public
String getSignatureHash() {
Javadoc doesn't match the impl.. leave a TODO in the javadoc?
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1032
File dev/core/src/com/google/gwt/dev/javac/Dependencies.java (right):
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1032#newcode71
dev/core/src/com/google/gwt/dev/javac/Dependencies.java:71: abstract
static class Ref implements Serializable {
I'd also add getInternalName()... that would allow you to kill some
casts + calls to getCompiledClass() in test code.
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1032#newcode204
dev/core/src/com/google/gwt/dev/javac/Dependencies.java:204: private
void readObject(ObjectInputStream inputStream)
Still needs to die.
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1034
File dev/core/src/com/google/gwt/dev/javac/GeneratedUnit.java (right):
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1034#newcode28
dev/core/src/com/google/gwt/dev/javac/GeneratedUnit.java:28: * through.
If this unit is not to be serialized, return -1.
Returns the source code as a token for {@link DiskCache#INSTANCE}, or
-1 if the source is not cached.
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1037
File
dev/core/src/com/google/gwt/dev/javac/SourceFileCompilationUnit.java
(right):
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1037#newcode99
dev/core/src/com/google/gwt/dev/javac/SourceFileCompilationUnit.java:99:
return new CachedCompilationUnit(this, sourceCode);
Just call getSource() to force the token to get initialized.
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1038
File dev/core/src/com/google/gwt/dev/javac/StandardGeneratorContext.java
(right):
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1038#newcode138
dev/core/src/com/google/gwt/dev/javac/StandardGeneratorContext.java:138:
return sourceToken;
I'd copy the IllegalStateException code from getSource().
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1040
File dev/core/src/com/google/gwt/dev/util/DiskCache.java (right):
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1040#newcode64
dev/core/src/com/google/gwt/dev/util/DiskCache.java:64: * Use this
singleton if you need to access the Disk cache.
A global, shared DiskCache. maybe?
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1043
File
dev/core/test/com/google/gwt/dev/javac/CompilationStateTestBase.java
(right):
http://gwt-code-reviews.appspot.com/1357801/diff/2017/1043#newcode81
dev/core/test/com/google/gwt/dev/javac/CompilationStateTestBase.java:81:
public long getSourceToken() {
Sort order.
http://gwt-code-reviews.appspot.com/1357801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Phase 1 of I18n Rewrite - support extended plurals/etc for export to property/etc files (issue1355802)
Thanks for taking a look.
Regarding your general comments, the overall structure of the visitors
is modeled after ASM visitors. The default visitor which provides
do-nothing implementations of all the visitors is also straight from
ASM, and provides an easy way to implement just what you want and also
provides future compatibility so if a method is added to an interface
your code will keep working as long as there is a reasonable default
implementation.
For the specifics of why the particular break-down was chosen, please
look at the three implementations of the visitor API --
LocalizableGeneratorVisitor and PropertyCatalogFactory here and the
internal implementation. I don't think your proposed simplification is
sufficient for all three needs.
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4024
File
user/src/com/google/gwt/i18n/rebind/AbstractLocalizableImplCreator.java
(right):
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4024#newcode64
user/src/com/google/gwt/i18n/rebind/AbstractLocalizableImplCreator.java:64:
public static class MessageCatalogContextImpl
Ok. It didn't seem useful outside of this case, which is why I made it
a static inner class.
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4024#newcode313
user/src/com/google/gwt/i18n/rebind/AbstractLocalizableImplCreator.java:313:
if (msgCatFactory != null) {
On 2011/02/16 00:13:34, rjrjr wrote:
This method is already awfully tall Can these two cases be factored
out into
separate methods?
Ok, though it will take a *lot* of parameters :)
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4026
File user/src/com/google/gwt/i18n/rebind/TypeOracleMessage.java (right):
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4026#newcode47
user/src/com/google/gwt/i18n/rebind/TypeOracleMessage.java:47: * An
implementation of the {@link Message} API on top of type oracle.
On 2011/02/16 00:13:34, rjrjr wrote:
Now is the time to make unit tests of these things. It's pretty easy
to set up a
mock type oracle environment these days, via CompilationStateBuilder
and
JavaResourceBase.getStandardResources().
As an example, look at
com.google.gwt.uibinder.elementparsers.ElementParserTester, used by
DockLayoutPanelParserTest
Ok, thanks.
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4026#newcode49
user/src/com/google/gwt/i18n/rebind/TypeOracleMessage.java:49: public
class TypeOracleMessage extends AbstractMessage implements Message {
On 2011/02/16 00:13:34, rjrjr wrote:
redundant implements. This happens all over the place.
Done.
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4026#newcode244
user/src/com/google/gwt/i18n/rebind/TypeOracleMessage.java:244:
JClassType list = oracle.findType(java.util.List);
On 2011/02/16 00:13:34, rjrjr wrote:
Why strings instead of List.class.getCanonicalName(), etc.?
Done.
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4030
File
user/src/com/google/gwt/i18n/rebind/format/MessageCatalogFactory.java
(right):
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4030#newcode44
user/src/com/google/gwt/i18n/rebind/format/MessageCatalogFactory.java:44:
interface MessageCatalogContext {
On 2011/02/16 00:13:34, rjrjr wrote:
Why nest these interfaces?
They are only used in the context of MessageCatalogFactory, so it seems
more useful to define them here rather than separate classes and make
you figure out what they are used by.
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4030#newcode71
user/src/com/google/gwt/i18n/rebind/format/MessageCatalogFactory.java:71:
void close() throws IOException;
On 2011/02/16 00:13:34, rjrjr wrote:
Why redeclare?
I personally have found it useful to declare these explicitly to make it
clear what contract an implementation has to fulfill. I agree with the
IDE's help it is of limited value, so if you prefer I will remove it.
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4042
File user/src/com/google/gwt/i18n/server/AbstractMessage.java (right):
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4042#newcode55
user/src/com/google/gwt/i18n/server/AbstractMessage.java:55: public
abstract class AbstractParameter implements Parameter {
On 2011/02/16 00:13:34, rjrjr wrote:
Does this actually need to be an inner class? All it uses is
localeFactory, why
not just pass that in to its constructor?
For subclasses, they will generally need more information from the
*Message class. I originally had it separate, and then found in my
implementations I had to just pass the corresponding *Message
implementation into the *Parameter implementation, so I figured just
make it a non-static class and let the compiler do that for me.
http://gwt-code-reviews.appspot.com/1355802/diff/4012/4042#newcode283
user/src/com/google/gwt/i18n/server/AbstractMessage.java:283: public
void accept(MessageVisitor mv, MessageTranslation trans)
On 2011/02/16 00:13:34, rjrjr wrote:
Why is this public? Why does it exist at all, if mv and trans
