[gwt-contrib] OOphm in trunk ?
Hi, I have been following the OOPHM issue for a while now, more specifically this one http://code.google.com/p/google-web-toolkit/issues/detail?id=135#makechanges I checked out and built the oophm branch and got it to work, I checked out and built trunk and found no oophm The wiki page linked to from the issue above says that oophm is in trunk and won't be available for 1.6 but I can't help noticing that when I build trunk there is no trace of oophm (no trace of any xpi file at least) my understanding is that : * oophm only exists here http://code.google.com/p/google-web-toolkit/source/browse/#svn/branches/oophm * the oophm branch was made from a 1.5 code base and won't be updated to 1.6 but will eventually be merged into trunk Am I correct ? Is there something preventing the merge of oophm back into trunk that I have missed ? thanks --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: OOphm in trunk ?
On Wed, Apr 22, 2009 at 1:35 AM, Jean wrote: > I have been following the OOPHM issue for a while now, more > specifically this one > http://code.google.com/p/google-web-toolkit/issues/detail?id=135#makechanges > > I checked out and built the oophm branch and got it to work, I checked > out and built trunk and found no oophm > > The wiki page linked to from the issue above says that oophm is in > trunk and won't be available for 1.6 but I can't help noticing that > when I build trunk there is no trace of oophm (no trace of any xpi > file at least) > > my understanding is that : > * oophm only exists here > http://code.google.com/p/google-web-toolkit/source/browse/#svn/branches/oophm > * the oophm branch was made from a 1.5 code base and won't be updated > to 1.6 but will eventually be merged into trunk > > Am I correct ? Is there something preventing the merge of oophm back > into trunk that I have missed ? > We didn't want to put all the different platform libraries/etc needed to build the Firefox extension multi-platform into the main GWT repository since few people would actually need to rebuild the plugin. It will probably wind up as a separate code.google.com project, but for now it exists only in the branch. To use OOPHM, simple follow the instructions at http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM which includes links to the binaries you need to install (which are in fact pulled from branches/oophm). -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5268 - Don't read stack frames from the input, since they aren't required and are incorrect
On Tue, Apr 21, 2009 at 8:01 PM, wrote: > Don't read stack frames from the input, since they aren't required and are > incorrect after rewriting Stack frames are incorrect after rewriting? What's the deal with that? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5268 - Don't read stack frames from the input, since they aren't required and are incorrect
On Wed, Apr 22, 2009 at 10:50 AM, Scott Blum wrote: > On Tue, Apr 21, 2009 at 8:01 PM, wrote: > >> Don't read stack frames from the input, since they aren't required and are >> incorrect after rewriting > > > Stack frames are incorrect after rewriting? What's the deal with that? > Sorry, it should have been stack maps, not frames, which are used by the 1.6 verifier if present so it doesn't have to build up maps of what is on the stack at each bytecode offset. I was getting errors trying to analyze a rewritten class while trying to track down the IncompatibleClassChangeError in IHM, and javap would throw an exception trying to read beyond the end of the file while ASM would get an IndexOutOfBoundsException trying to parse the included frame data. Our rewriters do nothing to handle changing the stack maps as the code is changed, so they can be incorrect. After talking with Toby, the stack maps are optional, and doing the work at runtime to calculate them is almost certainly slower than just letting the old verifier compute them. If we were to allow our bytecode rewriting to take place outside of hosted mode startup, such as a separate build step, then it might make sense to recompute them. Until then, it is easier to just drop them. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r5268 - Don't read stack frames from the input, since they aren't required and are incorrect
Gotcha. It'd be good to record this in a comment for posterity. On Wed, Apr 22, 2009 at 11:08 AM, John Tamplin wrote: > On Wed, Apr 22, 2009 at 10:50 AM, Scott Blum wrote: > >> On Tue, Apr 21, 2009 at 8:01 PM, wrote: >> >>> Don't read stack frames from the input, since they aren't required and >>> are >>> incorrect after rewriting >> >> >> Stack frames are incorrect after rewriting? What's the deal with that? >> > > Sorry, it should have been stack maps, not frames, which are used by the > 1.6 verifier if present so it doesn't have to build up maps of what is on > the stack at each bytecode offset. > > I was getting errors trying to analyze a rewritten class while trying to > track down the IncompatibleClassChangeError in IHM, and javap would throw an > exception trying to read beyond the end of the file while ASM would get an > IndexOutOfBoundsException trying to parse the included frame data. Our > rewriters do nothing to handle changing the stack maps as the code is > changed, so they can be incorrect. > > After talking with Toby, the stack maps are optional, and doing the work at > runtime to calculate them is almost certainly slower than just letting the > old verifier compute them. If we were to allow our bytecode rewriting to > take place outside of hosted mode startup, such as a separate build step, > then it might make sense to recompute them. Until then, it is easier to > just drop them. > > -- > John A. Tamplin > Software Engineer (GWT), Google > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] java script Error with IE7 and GWT 1.6.4
Hello,
I have an error in some popup windows used to update data. It's not a
systematic (!) error but not so difficult to produce in my
environnement with a popup panel displaying some enabled or disabled
textbox, listbox and a close button. I only display data (using
setText, setEnabled, setFocus).
JS code line in error (pretty mode) is :
function is(o){
if (o.nodeType) { // ERROR => in french "objet requis"
return o.nodeType == 1;
}
return false;
}
may be a call from "function $eventTargetsPopup(this$static,
event_0)"
The message "objet requis" (required object) let me think that o is
null or is not a valid object.
There's no problem using the same code with Opera or Firefox. The
"same" application (before updating to GWT 1.6, mainly replacing
listeners) seems to works fine with IE and GWT 1.5
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: subtree logging for problems
Thanks. Typo fixed, submit at r5269. On Tue, Apr 21, 2009 at 6:27 PM, Lex Spoon wrote: > LGTM. There's a typo in ProblemReport: "accessir". > > -Lex > > > On 4/21/09, Freeland Abbott wrote: > > Here's the promised follow-on to my earlier, fixing the subtype logging > to > > be a subtree logger. > > > > I'm still bothered by the multiple entries for "E extends > java.lang.Object", > > but I'm not sure which is the better way to fix it... I think I would > like > > to change JType constructors and/or .equals, to generalize to e.g. "id1 > > extends java.lang.Object" or "id1 extends Map > implements ValType>", but I'm not sure how such a change might impact > other > > uses of JType and children elsewhere... I would like to think it was > > beneficial. > > > > The other, more localized approach would be to change the TIC map key > from > > JClassType to String, and to do the identifier-abstraction as types were > > stringified in STOB, only. Thoughts? > > > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: subtree logging for problems
Would you be willing to drop a "before" and "after" example of the output for those of watching from the stands? On Wed, Apr 22, 2009 at 1:55 PM, Freeland Abbott wrote: > Thanks. Typo fixed, submit at r5269. > > > On Tue, Apr 21, 2009 at 6:27 PM, Lex Spoon wrote: > >> LGTM. There's a typo in ProblemReport: "accessir". >> >> -Lex >> >> >> On 4/21/09, Freeland Abbott wrote: >> > Here's the promised follow-on to my earlier, fixing the subtype logging >> to >> > be a subtree logger. >> > >> > I'm still bothered by the multiple entries for "E extends >> java.lang.Object", >> > but I'm not sure which is the better way to fix it... I think I would >> like >> > to change JType constructors and/or .equals, to generalize to e.g. "id1 >> > extends java.lang.Object" or "id1 extends Map> > implements ValType>", but I'm not sure how such a change might impact >> other >> > uses of JType and children elsewhere... I would like to think it was >> > beneficial. >> > >> > The other, more localized approach would be to change the TIC map key >> from >> > JClassType to String, and to do the identifier-abstraction as types were >> > stringified in STOB, only. Thoughts? >> > >> > >> > >> > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: subtree logging for problems
>From this patch (the bigger impact is my earlier one, which already had at least the "after" form thrashed on), the new, sublogger-using format is: [java] Compiling module com.google.gwt.sample.broken.Broken [java]Scanning for additional dependencies: file:/C:/Documents%20and%20Settings/fabbott/My%20Documents/GWT/gwt-trunk/samples/broken/src/com/google/gwt/sample/broken/client/BrokenRpc.java [java] Computing all possible rebind results for 'com.google.gwt.sample.broken.client.BrokenRpcService' [java] Rebinding com.google.gwt.sample.broken.client.BrokenRpcService [java] Invoking [java]Generating client proxy for remote service interface 'com.google.gwt.sample.broken.client.BrokenRpcService' [java] [ERROR] com.google.gwt.sample.broken.client.AbstractTopInterface has no available instantiable subtypes. (reached via com.google.gwt.sample.broken.client.AbstractTopInterface) [java] [ERROR]subtype com.google.gwt.sample.broken.client.AbstractTopInterface is not instantiable [java] [ERROR]subtype com.google.gwt.sample.broken.client.AbstractSerializableChildClass is not instantiable [java] [ERROR]subtype com.google.gwt.sample.broken.client.ConcreteSerializableChildClassNoCtor is not default instantiable (it must have a zero-argument constructor or no constructors at all) and has no custom serializer. (reached via com.google.gwt.sample.broken.client.AbstractTopInterface) [java] [ERROR]subtype com.google.gwt.sample.broken.client.AbstractNonSerializableClass is not instantiable [java] [ERROR]subtype com.google.gwt.sample.broken.client.AbstractSerializableClass is not instantiable [java] [ERROR] com.google.gwt.sample.broken.client.ConcreteSerializableChildClassNoCtor is not default instantiable (it must have a zero-argument constructor or no constructors at all) and has no custom serializer. (reached via com.google.gwt.sample.broken.client.AbstractTopInterface) [java][ERROR] Errors in 'file:/C:/Documents%20and%20Settings/fabbott/My%20Documents/GWT/gwt-trunk/samples/broken/src/com/google/gwt/sample/broken/client/BrokenRpc.java' [java] [ERROR] Line 144: Failed to resolve 'com.google.gwt.sample.broken.client.BrokenRpcService' via deferred binding [java][ERROR] Cannot proceed due to previous errors And the before, in which the sub-entries were glommed into the top-level one as a multi-line entry (because there was no Problem structure, merely a single String entry), was: [java] Compiling module com.google.gwt.sample.broken.Broken [java]Scanning for additional dependencies: file:/C:/Documents%20and%20Settings/fabbott/My%20Documents/GWT/gwt-trunk/samples/broken/src/com/google/gwt/sample/broken/client/BrokenRpc.java [java] Computing all possible rebind results for 'com.google.gwt.sample.broken.client.BrokenRpcService' [java] Rebinding com.google.gwt.sample.broken.client.BrokenRpcService [java] Invoking [java]Generating client proxy for remote service interface 'com.google.gwt.sample.broken.client.BrokenRpcService' [java] [ERROR] com.google.gwt.sample.broken.client.AbstractTopInterface has no available instantiable subtypes. (reached via com.google.gwt.sample.broken.client.AbstractTopInterface) [java] subtype com.google.gwt.sample.broken.client.AbstractTopInterface is not instantiable [java] subtype com.google.gwt.sample.broken.client.AbstractSerializableChildClass is not instantiable [java] subtype com.google.gwt.sample.broken.client.ConcreteSerializableChildClassNoCtor is not default instantiable (it must have a zero-argument constructor or no constructors at all) and has no custom serializer. (reached via com.google.gwt.sample.broken.client.AbstractTopInterface) [java] subtype com.google.gwt.sample.broken.client.AbstractNonSerializableClass is not instantiable [java] subtype com.google.gwt.sample.broken.client.AbstractSerializableClass is not instantiable [java] [ERROR] com.google.gwt.sample.broken.client.ConcreteSerializableChildClassNoCtor is not default instantiable (it must have a zero-argument constructor or no constructors at all) and has no custom serializer. (reached via com.google.gwt.sample.broken.client.AbstractTopInterface) [java][ERROR] Errors in 'file:/C:/Documents%20and%20Settings/fabbott/My%20Documents/GWT/gwt-trunk/samples/broken/src/com/google/gwt/sample/broken/client/BrokenRpc.java' [java] [ERROR] Line 144: Failed to resolve 'com.google.gwt.sample.broken.client.BrokenRpcService' via deferred binding [java][ERROR] Cannot proceed due to previous errors On Wed, Apr 22, 2009 at 1:58 PM, Bruce Johnson wrote: > Would you be w
[gwt-contrib] Re: cross site RPC through iframes
2009/4/21 Ray Cromwell : > > It wouldn't be hard to do it using this: > > http://timepedia.blogspot.com/2008/07/cross-domain-formpanel-submissions-in.html > http://development.lombardi.com/?p=611 Thank you very much, window.name hack looks really nice. I will look into making it possible to use GWT RPC through it easily. -- Best Regards, Piotr Jaroszyński --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5269 - Adapting ProblemReport.build to use a sublogger for child messages (e.g. the subtypes tri...
Author: fabb...@google.com
Date: Wed Apr 22 10:54:17 2009
New Revision: 5269
Modified:
trunk/user/src/com/google/gwt/user/rebind/rpc/ProblemReport.java
trunk/user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilder.java
Log:
Adapting ProblemReport.build to use a sublogger for child messages (e.g.
the subtypes tried for an instantiable type).
Review by: spoon
Modified: trunk/user/src/com/google/gwt/user/rebind/rpc/ProblemReport.java
==
--- trunk/user/src/com/google/gwt/user/rebind/rpc/ProblemReport.java
(original)
+++ trunk/user/src/com/google/gwt/user/rebind/rpc/ProblemReport.javaWed
Apr 22 10:54:17 2009
@@ -44,9 +44,43 @@
*/
public enum Priority { FATAL, DEFAULT, AUXILIARY}
- private Map> allProblems;
- private Map> auxiliaries;
- private Map> fatalProblems;
+ /**
+ * An individual report, which may require multiple entries (expressed as
+ * logs under a branchpoint), but relates to an individual issue.
+ */
+ public class Problem {
+private String message;
+private List childMessages;
+
+private Problem(String message, String[] children) {
+ this.message = message;
+ // most problems don't have sub-messages, so init at zero size
+ childMessages = new ArrayList(children.length);
+ for (int i = 0; i < children.length; i++) {
+childMessages.add(children[i]);
+ }
+}
+
+public void addChild(String message) {
+ childMessages.add(message);
+}
+
+public String getPrimaryMessage() {
+ return message;
+}
+
+public Iterable getSubMessages() {
+ return childMessages;
+}
+
+public boolean hasSubMessages() {
+ return !childMessages.isEmpty();
+}
+ }
+
+ private Map> allProblems;
+ private Map> auxiliaries;
+ private Map> fatalProblems;
private JClassType contextType;
/**
@@ -61,9 +95,9 @@
o2.getParameterizedQualifiedSourceName());
}
};
-allProblems = new TreeMap>(comparator);
-auxiliaries = new TreeMap>(comparator);
-fatalProblems = new TreeMap>(comparator);
+allProblems = new TreeMap>(comparator);
+auxiliaries = new TreeMap>(comparator);
+fatalProblems = new TreeMap>(comparator);
contextType = null;
}
@@ -77,7 +111,7 @@
* @param extraLines additional continuation lines for the message,
usually
*for additional explanations.
*/
- public void add(JClassType type, String message, Priority priority,
+ public Problem add(JClassType type, String message, Priority priority,
String... extraLines) {
String contextString = "";
if (contextType != null) {
@@ -85,62 +119,34 @@
contextType.getParameterizedQualifiedSourceName() + ")";
}
message = message + contextString;
-for (String line : extraLines) {
- message = message + "\n " + line;
-}
+Problem entry = new Problem(message, extraLines);
if (priority == Priority.AUXILIARY) {
- addToMap(type, message, auxiliaries);
- return;
+ addToMap(type, entry, auxiliaries);
+ return entry;
}
// both FATAL and DEFAULT problems go in allProblems...
-addToMap(type, message, allProblems);
+addToMap(type, entry, allProblems);
// only FATAL problems go in fatalProblems...
if (priority == Priority.FATAL) {
- addToMap(type, message, fatalProblems);
+ addToMap(type, entry, fatalProblems);
}
+return entry;
}
- /**
- * Returns list of auxiliary "problems" logged against a given type.
- *
- * @param type type to fetch problems for
- * @return {...@code null} if no auxiliaries were logged. Otherwise, a list
- * of strings describing messages, including the context in which the
- * problem was found.
- */
- public List getAuxiliaryMessagesForType(JClassType type) {
-List list = auxiliaries.get(type);
+ public String getWorstMessageForType(JClassType type) {
+List list = fatalProblems.get(type);
if (list == null) {
- list = new ArrayList(0);
+ list = allProblems.get(type);
+ if (list == null) {
+list = auxiliaries.get(type);
+ }
}
-return list;
- }
-
- /**
- * Returns list of problems logged against a given type.
- *
- * @param type type to fetch problems for
- * @return {...@code null} if no problems were logged. Otherwise, a list
- * of strings describing problems, including the context in which the
- * problem was found.
- */
- public List getProblemsForType(JClassType type) {
-List list = allProblems.get(type);
if (list == null) {
- list = new ArrayList(0);
+ return null;
}
-return list;
- }
-
- /**
- * Returns the number of types against which problems were reported.
- *
- * @return number of problematic types
- */
- public int getProblemTypeCount() {
-return allProblems.size();
[gwt-contrib] Re: Fix for issue 3569 (LongLib.shr)
[+gwtc] LGTM, although I had to do some work to convince myself it was safe. You might consider updating the comment; what I find more quickly understandable and verifiable is something like: If n<32, a[HIGH]/shiftFact is guaranteed to be an integer already. For n>32, a[HIGH]/shiftFact will have fractional bits, but we need to discard them as they shift away. (We will end up discarding all of a[LOW] in this case, as it divides out to entirely fractional.) I assume the branch to test for high-n (and work only with a[HIGH] if so) is much more expensive than the savings by avoiding the division. On Wed, Apr 22, 2009 at 3:57 PM, Lex Spoon wrote: > Freeland, would you have time to review this short patch to LongLib? > > http://gwt-code-reviews.appspot.com/28801 > > -Lex > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Fix for issue 3569 (LongLib.shr)
On Wed, Apr 22, 2009 at 4:28 PM, Freeland Abbott wrote: > [+gwtc] > > LGTM, although I had to do some work to convince myself it was safe. > > You might consider updating the comment; what I find more quickly > understandable and verifiable is something like: > > If n<32, a[HIGH]/shiftFact is guaranteed to be an integer already. For > n>32, a[HIGH]/shiftFact will have fractional bits, but we need to discard > them as they shift away. (We will end up discarding all of a[LOW] in this > case, as it divides out to entirely fractional.) That's a much clearer explanation. Changed. > I assume the branch to test for high-n (and work only with a[HIGH] if so) is > much more expensive than the savings by avoiding the division. I hadn't thought of that. The difference in speed shouldn't be much in comparison to the create() call, which is pretty expensive. So, it's just a matter of which version is simpler. I'm honestly not sure which is simpler. I have gone ahead and put it in, at r5270, just to close the bug. If you think the version with a branch would be clearer, then let's change it. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5270 - Fixes issue 3569. LongLib.shr gave incorrect results
Author: sp...@google.com
Date: Wed Apr 22 14:15:18 2009
New Revision: 5270
Modified:
trunk/dev/core/super/com/google/gwt/lang/LongLib.java
trunk/dev/core/test/com/google/gwt/lang/LongLibTestBase.java
Log:
Fixes issue 3569. LongLib.shr gave incorrect results
when the shift amount was greater than 32. This revision adds
two new test cases and modifies LongLib.shr to handle them.
Review by: fabbott
Modified: trunk/dev/core/super/com/google/gwt/lang/LongLib.java
==
--- trunk/dev/core/super/com/google/gwt/lang/LongLib.java (original)
+++ trunk/dev/core/super/com/google/gwt/lang/LongLib.java Wed Apr 22
14:15:18 2009
@@ -394,8 +394,17 @@
public static double[] shr(double[] a, int n) {
n &= 63;
double shiftFact = pwrAsDouble(n);
-double newHigh = a[HIGH] / shiftFact;
+double newHigh = Math.floor(a[HIGH] / shiftFact);
double newLow = Math.floor(a[LOW] / shiftFact);
+
+/*
+ * Doing the above floors separately on each component is safe. If
n<32,
+ * a[HIGH]/shiftFact is guaranteed to be an integer already. For n>32,
+ * a[HIGH]/shiftFact will have fractional bits, but we need to discard
them
+ * as they shift away. We will end up discarding all of a[LOW] in this
case,
+ * as it divides out to entirely fractional.
+ */
+
return create(newLow, newHigh);
}
Modified: trunk/dev/core/test/com/google/gwt/lang/LongLibTestBase.java
==
--- trunk/dev/core/test/com/google/gwt/lang/LongLibTestBase.java
(original)
+++ trunk/dev/core/test/com/google/gwt/lang/LongLibTestBase.javaWed Apr
22
14:15:18 2009
@@ -272,10 +272,13 @@
longFromBits(0x92341234, 0x45674567), 10));
assertEquals(longFromBits(0xffe48d04, 0x8d1159d1), LongLib.shr(
longFromBits(0x92341234, 0x45674567), 10));
+assertEquals(LongLib.fromInt(67108863),
LongLib.shr(longFromBits(0xFFF,
+0x), 34));
assertEquals(longFromBits(0x248d04, 0x8d1159d1),
LongLib.shru(longFromBits(
0x92341234, 0x45674567), 10));
assertEquals(LongLib.fromInt(-1), LongLib.shr(LongLib.fromInt(-1),
10));
+assertEquals(LongLib.fromInt(-1), LongLib.shr(LongLib.fromInt(-1),
63));
assertEquals(LongLib.fromInt(-1 << 5),
LongLib.shl(LongLib.fromInt(-1), 5));
assertEquals(LongLib.fromInt(-1), LongLib.shl(LongLib.fromInt(-1), 0));
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Fix failed assert in UIObject#toString
Reviewers: jlabanca,
Description:
Fixes issue 3586
Please review this at http://gwt-code-reviews.appspot.com/29801
Affected files:
user/src/com/google/gwt/user/client/ui/UIObject.java
user/test/com/google/gwt/user/client/ui/UIObjectTest.java
Index: user/src/com/google/gwt/user/client/ui/UIObject.java
===
--- user/src/com/google/gwt/user/client/ui/UIObject.java(revision 5255)
+++ user/src/com/google/gwt/user/client/ui/UIObject.java(working copy)
@@ -16,8 +16,8 @@
package com.google.gwt.user.client.ui;
import com.google.gwt.core.client.GWT;
+import com.google.gwt.dom.client.Element;
import com.google.gwt.user.client.DOM;
-import com.google.gwt.dom.client.Element;
/**
* The superclass for all user-interface objects. It simply wraps a DOM
element,
@@ -723,7 +723,7 @@
*/
@Override
public String toString() {
-if (getElement() == null) {
+if (element == null) {
return "(null handle)";
}
return DOM.toString(getElement());
Index: user/test/com/google/gwt/user/client/ui/UIObjectTest.java
===
--- user/test/com/google/gwt/user/client/ui/UIObjectTest.java (revision
5255)
+++ user/test/com/google/gwt/user/client/ui/UIObjectTest.java (working copy)
@@ -15,6 +15,8 @@
*/
package com.google.gwt.user.client.ui;
+import com.google.gwt.dom.client.Document;
+import com.google.gwt.dom.client.SpanElement;
import com.google.gwt.junit.client.GWTTestCase;
import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Element;
@@ -70,6 +72,14 @@
public String getModuleName() {
return "com.google.gwt.user.DebugTest";
}
+
+ public void testToString() {
+UIObject u = new UIObject(){};
+assertEquals("(null handle)", u.toString());
+SpanElement span = Document.get().createSpanElement();
+u.setElement(span);
+assertEquals(span.toString(), u.toString());
+ }
public void testAccidentalPrimary() {
MyObject o = new MyObject();
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5271 - Add comment explaining why we skip stack map frames.
Author: j...@google.com
Date: Wed Apr 22 16:13:54 2009
New Revision: 5271
Modified:
changes/jat/ihm/dev/core/src/com/google/gwt/dev/shell/rewrite/HostedModeClassRewriter.java
Log:
Add comment explaining why we skip stack map frames.
Modified:
changes/jat/ihm/dev/core/src/com/google/gwt/dev/shell/rewrite/HostedModeClassRewriter.java
==
---
changes/jat/ihm/dev/core/src/com/google/gwt/dev/shell/rewrite/HostedModeClassRewriter.java
(original)
+++
changes/jat/ihm/dev/core/src/com/google/gwt/dev/shell/rewrite/HostedModeClassRewriter.java
Wed Apr 22 16:13:54 2009
@@ -219,6 +219,13 @@
v = new ForceClassVersion15(v);
}
+/*
+ * We want to skip reading the stack map frames since we don't modify
them
+ * to reflect the changes made by our rewriters. Leaving them in can
+ * confuse ASM, javap, and potentially the jvm. Also, doing the work
at
+ * runtime to compute the proper stack maps is almost certainly going
to be
+ * slower than just letting the JVM's bytecode verifier do that itself.
+ */
new ClassReader(classBytes).accept(v, ClassReader.SKIP_FRAMES);
byte[] result = writer.toByteArray();
//System.err.println("Rewritten output for " + className);
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5272 - Patch replaces tab chars with 2 spaces and fixes some formatting.
Author: amitman...@google.com Date: Wed Apr 22 16:56:07 2009 New Revision: 5272 Modified: trunk/distro-source/core/src/release_notes.html Log: Patch replaces tab chars with 2 spaces and fixes some formatting. Patch by: amitmanjhi Review by: rjrjr Modified: trunk/distro-source/core/src/release_notes.html == --- trunk/distro-source/core/src/release_notes.html (original) +++ trunk/distro-source/core/src/release_notes.html Wed Apr 22 16:56:07 2009 @@ -28,21 +28,21 @@ Google Web Toolkit Release Notes - @GWT_VERSION@ - 1.5.3 - 1.5.2 - 1.5.1 (RC2) - 1.5.0 (RC) - 1.4.60 - 1.4.59 (RC2) - 1.4.10 (RC) - 1.3.3 - 1.3.1 (RC) - 1.2.22 - 1.2.21 (RC) - 1.1.10 - 1.1.0 (RC) - 1.0.21 +@GWT_VERSION@ +1.5.3 +1.5.2 +1.5.1 (RC2) +1.5.0 (RC) +1.4.60 +1.4.59 (RC2) +1.4.10 (RC) +1.3.3 +1.3.1 (RC) +1.2.22 +1.2.21 (RC) +1.1.10 +1.1.0 (RC) +1.0.21 @@ -125,7 +125,7 @@ Added support for the contextmenu event, which allows users to detect and override the browser's default context menu Improved performance of NumberFormat - Added support for altering the number of decimals in a currency in NumberFormat +Added support for altering the number of decimals in a currency in NumberFormat Improved performance of Animations Improved the appearance of the default GWT style themes Improved the Showcase sample with more robust examples and more language translations @@ -158,12 +158,12 @@ This release has only a couple of minor changes from 1.4.59. - Fixed a bug in the benchmarking that prevented source code from showing up in reports. - Fixed a bug in the hosted mode servlet context emulation where getResource() would fail to - find a file in a module's public path. - Compiler output files of the form module.cache.html used to contain html - intended as a helpful note to a developer. This message has now been removed because screen - readers and some browsers would display this content to end users. +Fixed a bug in the benchmarking that prevented source code from showing up in reports. +Fixed a bug in the hosted mode servlet context emulation where getResource() would fail to +find a file in a module's public path. +Compiler output files of the form module.cache.html used to contain html +intended as a helpful note to a developer. This message has now been removed because screen +readers and some browsers would display this content to end users. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Java source transformation
> Now, MyBean does not implement interface X, but a generator/AOP
> interceptor could make a subclass of MyBean that has interface X
> implement. IIRC, GWT RPC just invokes the default constructor, so
> there's no way to intercept this and substitute a replacement.
Yeah, that is an interesting question. However, wouldn't the AOP be
happening before you send the object over the wire? You wouldn't
really care about any interception at that point
--
Arthur Kalmenson
On Wed, Apr 22, 2009 at 12:28 AM, Ray Cromwell wrote:
>
> On Tue, Apr 21, 2009 at 7:11 PM, Arthur Kalmenson
> wrote:
>>
>> Hmm, but don't you normally send some kind of Model or domain object
>> over the wire and not something that would need to be injected with
>> dependencies by Gin?
>
>
> I think what he's saying is that he might have an RPC method like this:
>
> public interface MyService extends RemoteService {
> MyBean getBean();
> }
>
> Now, MyBean does not implement interface X, but a generator/AOP
> interceptor could make a subclass of MyBean that has interface X
> implement. IIRC, GWT RPC just invokes the default constructor, so
> there's no way to intercept this and substitute a replacement.
>
> I think the other thing he might want to do is intercept client-side
> UI classes and make them call addPropertyChangeListener() on a model
> object based on certain invocations.
>
> -Ray
>
>> And Bruce, that's an interesting example. I was thinking how one would
>> implement AOP in GWT, perhaps it's not as hard as I originally
>> thought. Is there a way to extend this example to dynamically create
>> proxies for any class that'll be advised by some aspect?
>>
>> Also, Nicolas, AFAIK, the GWT team (bobv) is working on a data binding
>> (and validation?) framework. I'm hoping something will hit the
>> incubator soon so we can all jump on board and help out. It'd
>> definitely have saved us thousands of lines of glue code ;).
>>
>> P.S. Sorry about not writing up that how-to for GWTMockUtilities,
>> Bruce. I'll try to do it some time this week.
>>
>> Best regards,
>> --
>> Arthur Kalmenson
>>
>>
>>
>> On Tue, Apr 21, 2009 at 2:58 PM, Ray Cromwell wrote:
>>>
>>> Interesting question. Gin auto-creates RPC interfaces as well, for
>>> example, if you have:
>>>
>>> public interface MyFoo extends Ginjector {
>>> MyServiceAsync getService();
>>> }
>>>
>>> then Gin implicitly looks for MyService.class and invokes
>>> GWT.create(MyService.class) when calling getService(). Since Gin is
>>> handling the creation, I'm not sure if it handles RPC methods with
>>> classes have have @Inject annotations, but you could probably setup a
>>> separate binding. The de-serialization logic in RPC is not likely to
>>> allow Gin interception, since it apparently uses default constructors
>>> to create classes, and what you want it to do is delegate the
>>> construction to some injectable mechanism (e.g. to substitute your own
>>> subclasses)
>>>
>>> It doesn't sound impossible to make this work, and is probably easier
>>> to get right than trying to make new Foo() interceptable by the
>>> compiler. I would join the Gin groups and ask the guys there about it.
>>>
>>> -Ray
>>>
>>>
>>> On Tue, Apr 21, 2009 at 11:49 AM, nicolas de loof
>>> wrote:
Sounds a good solution.
How would this solve the use case "data returned by RPC call" ?
2009/4/21 Ray Cromwell
>
> I really think Guice-style dependency injection is the way to go to
> solve this problem, rather than trying to emulate Java
> Proxies/Classloader in the compiler. If you use Guice/Gin, then in Gin
> you can inject GWT.create-d versions, and in JUnit-mode, you can use
> regular Guice injection. The code use is 99% between GWT and non-GWT
> versions test versions, with the exception of the
> Guice-config/Injector creation.
>
> Because of the way Gin works transitively, you only need a single
> GWT.create() and this is isolated to your startup code while in your
> JUnit version, you kick off a Guice-injected class instead.
>
> -Ray
>
> On Tue, Apr 21, 2009 at 11:28 AM, nicolas de loof
> wrote:
> > A simple example : databinding
> > Lets consider I want to bind some Label text to some model Bean value.
> > Gwt
> > Label widget "text" can be accessed as a javaBean property, so this
> > sound a
> > typical java.beans.binding use-case
> > This requires my model bean to support PropertyChangeListeners. As I'm
> > lazy
> > I'd like a generator to create an "enhanced" model class with such
> > support
> > for the "value" property.
> > I can get this to work today if my model Bean is created using
> > GWT.create(),
> > but this makes my code GWT-dependant and not testable in "standalone"
> > junit.
> > If the generator "enhanced" class is used even when I use " new Model()
> > " or
> > get a Model bean from RPC, my code can be easily unit tested.
> >
[gwt-contrib] Re: Java source transformation
IMHO, The interesting case is not AOP of outgoing objects, but AOP of
incoming objects (return values from RPC). This might even help some
of the GWT/GAE/JDO issues, where you could AOP enhance an incoming
model object to track dirty modification of fields. This is not
unlike the JRE serialization mechanisms like readResolve() this allow
replacement.
-Ray
On Wed, Apr 22, 2009 at 7:19 PM, Arthur Kalmenson wrote:
>
>> Now, MyBean does not implement interface X, but a generator/AOP
>> interceptor could make a subclass of MyBean that has interface X
>> implement. IIRC, GWT RPC just invokes the default constructor, so
>> there's no way to intercept this and substitute a replacement.
>
> Yeah, that is an interesting question. However, wouldn't the AOP be
> happening before you send the object over the wire? You wouldn't
> really care about any interception at that point
>
> --
> Arthur Kalmenson
>
>
>
> On Wed, Apr 22, 2009 at 12:28 AM, Ray Cromwell wrote:
>>
>> On Tue, Apr 21, 2009 at 7:11 PM, Arthur Kalmenson
>> wrote:
>>>
>>> Hmm, but don't you normally send some kind of Model or domain object
>>> over the wire and not something that would need to be injected with
>>> dependencies by Gin?
>>
>>
>> I think what he's saying is that he might have an RPC method like this:
>>
>> public interface MyService extends RemoteService {
>> MyBean getBean();
>> }
>>
>> Now, MyBean does not implement interface X, but a generator/AOP
>> interceptor could make a subclass of MyBean that has interface X
>> implement. IIRC, GWT RPC just invokes the default constructor, so
>> there's no way to intercept this and substitute a replacement.
>>
>> I think the other thing he might want to do is intercept client-side
>> UI classes and make them call addPropertyChangeListener() on a model
>> object based on certain invocations.
>>
>> -Ray
>>
>>> And Bruce, that's an interesting example. I was thinking how one would
>>> implement AOP in GWT, perhaps it's not as hard as I originally
>>> thought. Is there a way to extend this example to dynamically create
>>> proxies for any class that'll be advised by some aspect?
>>>
>>> Also, Nicolas, AFAIK, the GWT team (bobv) is working on a data binding
>>> (and validation?) framework. I'm hoping something will hit the
>>> incubator soon so we can all jump on board and help out. It'd
>>> definitely have saved us thousands of lines of glue code ;).
>>>
>>> P.S. Sorry about not writing up that how-to for GWTMockUtilities,
>>> Bruce. I'll try to do it some time this week.
>>>
>>> Best regards,
>>> --
>>> Arthur Kalmenson
>>>
>>>
>>>
>>> On Tue, Apr 21, 2009 at 2:58 PM, Ray Cromwell wrote:
Interesting question. Gin auto-creates RPC interfaces as well, for
example, if you have:
public interface MyFoo extends Ginjector {
MyServiceAsync getService();
}
then Gin implicitly looks for MyService.class and invokes
GWT.create(MyService.class) when calling getService(). Since Gin is
handling the creation, I'm not sure if it handles RPC methods with
classes have have @Inject annotations, but you could probably setup a
separate binding. The de-serialization logic in RPC is not likely to
allow Gin interception, since it apparently uses default constructors
to create classes, and what you want it to do is delegate the
construction to some injectable mechanism (e.g. to substitute your own
subclasses)
It doesn't sound impossible to make this work, and is probably easier
to get right than trying to make new Foo() interceptable by the
compiler. I would join the Gin groups and ask the guys there about it.
-Ray
On Tue, Apr 21, 2009 at 11:49 AM, nicolas de loof
wrote:
> Sounds a good solution.
> How would this solve the use case "data returned by RPC call" ?
>
> 2009/4/21 Ray Cromwell
>>
>> I really think Guice-style dependency injection is the way to go to
>> solve this problem, rather than trying to emulate Java
>> Proxies/Classloader in the compiler. If you use Guice/Gin, then in Gin
>> you can inject GWT.create-d versions, and in JUnit-mode, you can use
>> regular Guice injection. The code use is 99% between GWT and non-GWT
>> versions test versions, with the exception of the
>> Guice-config/Injector creation.
>>
>> Because of the way Gin works transitively, you only need a single
>> GWT.create() and this is isolated to your startup code while in your
>> JUnit version, you kick off a Guice-injected class instead.
>>
>> -Ray
>>
>> On Tue, Apr 21, 2009 at 11:28 AM, nicolas de loof
>> wrote:
>> > A simple example : databinding
>> > Lets consider I want to bind some Label text to some model Bean value.
>> > Gwt
>> > Label widget "text" can be accessed as a javaBean property, so this
>> > sound a
>> > typical java.beans.binding use-case
>> > This requires my mode
[gwt-contrib] Re: subtree logging for problems
For the record, the original (pre-5256) output would have been (noting lack of specificity of error, which was my poor usability itch, as well as the several levels of nested logging that have been removed and other internal cleanup per Lex's encouragement): [java] Compiling module com.google.gwt.sample.broken.Broken [java]Scanning for additional dependencies: file:/C:/Documents%20and%20Settings/fabbott/My%20Documents/GWT/gwt-trunk/samples/broken/src/com/google/gwt/sample/broken/client/BrokenRpc.java [java] Computing all possible rebind results for 'com.google.gwt.sample.broken.client.BrokenRpcService' [java] Rebinding com.google.gwt.sample.broken.client.BrokenRpcService [java] Invoking [java]Generating client proxy for remote service interface 'com.google.gwt.sample.broken.client.BrokenRpcService' [java] Analyzing 'com.google.gwt.sample.broken.client.BrokenRpcService' for serializable types [java] Analyzing methods: [java] public abstract java.lang.String getString(com.google.gwt.sample.broken.client.AbstractTopInterface obj) throws com.google.gwt.sample.broken.client.BrokenRpcException [java]Parameter: com.google.gwt.sample.broken.client.AbstractTopInterface obj [java] com.google.gwt.sample.broken.client.AbstractTopInterface [java] [ERROR] Type 'com.google.gwt.sample.broken.client.AbstractTopInterface' was not serializable and has no concrete serializable subtypes [java][ERROR] Errors in 'file:/C:/Documents%20and%20Settings/fabbott/My%20Documents/GWT/gwt-trunk/samples/broken/src/com/google/gwt/sample/broken/client/BrokenRpc.java' [java] [ERROR] Line 144: Failed to resolve 'com.google.gwt.sample.broken.client.BrokenRpcService' via deferred binding [java][ERROR] Cannot proceed due to previous errors On Wed, Apr 22, 2009 at 2:06 PM, Freeland Abbott wrote: > From this patch (the bigger impact is my earlier one, which already had at > least the "after" form thrashed on), the new, sublogger-using format is: > [java] Compiling module com.google.gwt.sample.broken.Broken > [java]Scanning for additional dependencies: > file:/C:/Documents%20and%20Settings/fabbott/My%20Documents/GWT/gwt-trunk/samples/broken/src/com/google/gwt/sample/broken/client/BrokenRpc.java > [java] Computing all possible rebind results for > 'com.google.gwt.sample.broken.client.BrokenRpcService' > [java] Rebinding > com.google.gwt.sample.broken.client.BrokenRpcService > [java] Invoking class='com.google.gwt.user.rebind.rpc.ServiceInterfaceProxyGenerator'/> > [java]Generating client proxy for remote service > interface 'com.google.gwt.sample.broken.client.BrokenRpcService' > [java] [ERROR] > com.google.gwt.sample.broken.client.AbstractTopInterface has no available > instantiable subtypes. (reached via > com.google.gwt.sample.broken.client.AbstractTopInterface) > [java] [ERROR]subtype > com.google.gwt.sample.broken.client.AbstractTopInterface is not instantiable > [java] [ERROR]subtype > com.google.gwt.sample.broken.client.AbstractSerializableChildClass is not > instantiable > [java] [ERROR]subtype > com.google.gwt.sample.broken.client.ConcreteSerializableChildClassNoCtor is > not default instantiable (it must have a zero-argument constructor or no > constructors at all) and has no custom serializer. (reached via > com.google.gwt.sample.broken.client.AbstractTopInterface) > [java] [ERROR]subtype > com.google.gwt.sample.broken.client.AbstractNonSerializableClass is not > instantiable > [java] [ERROR]subtype > com.google.gwt.sample.broken.client.AbstractSerializableClass is not > instantiable > [java] [ERROR] > com.google.gwt.sample.broken.client.ConcreteSerializableChildClassNoCtor is > not default instantiable (it must have a zero-argument constructor or no > constructors at all) and has no custom serializer. (reached via > com.google.gwt.sample.broken.client.AbstractTopInterface) > [java][ERROR] Errors in > 'file:/C:/Documents%20and%20Settings/fabbott/My%20Documents/GWT/gwt-trunk/samples/broken/src/com/google/gwt/sample/broken/client/BrokenRpc.java' > [java] [ERROR] Line 144: Failed to resolve > 'com.google.gwt.sample.broken.client.BrokenRpcService' via deferred binding > [java][ERROR] Cannot proceed due to previous errors > > And the before, in which the sub-entries were glommed into the top-level > one as a multi-line entry (because there was no Problem structure, merely a > single String entry), was: > > [java] Compiling module com.google.gwt.sample.broken.Broken > [java]
[gwt-contrib] Re: Java source transformation
To implement Interceptors in gwt one does just needs to follow the
same general patterns that exist in real java and aop.
I have already done interceptors / aop for gwt as part of my own di
module in gwt. One does not need interceptors in gwt a lot of extra
behind the scenes classes are needed both generated and framework to
make it work.
1/ To intercept one class you need to subclass the target.
2/ every public method needs to include some stuff to handle firing of
said interceptors.
3/ if u want the interceptors to be able to truly intercept and be
able to modify parameters, veto the call to the target substitute a
different return value etc a lot of extra code is needed. If u want
too see am example download my project and run the test cases with the
gen flag on.
Supporting other dynamic mechanisms like reflection are also possible
but the amount of generated stuff required bloats your javascript by
significant amounts.
One of the goals of gwt is to produce minimalist code and this goes
against this mantra.
On 23/04/2009, at 12:19 PM, Arthur Kalmenson
wrote:
>
>> Now, MyBean does not implement interface X, but a generator/AOP
>> interceptor could make a subclass of MyBean that has interface X
>> implement. IIRC, GWT RPC just invokes the default constructor, so
>> there's no way to intercept this and substitute a replacement.
>
> Yeah, that is an interesting question. However, wouldn't the AOP be
> happening before you send the object over the wire? You wouldn't
> really care about any interception at that point
>
> --
> Arthur Kalmenson
>
>
>
> On Wed, Apr 22, 2009 at 12:28 AM, Ray Cromwell
> wrote:
>>
>> On Tue, Apr 21, 2009 at 7:11 PM, Arthur Kalmenson > > wrote:
>>>
>>> Hmm, but don't you normally send some kind of Model or domain object
>>> over the wire and not something that would need to be injected with
>>> dependencies by Gin?
>>
>>
>> I think what he's saying is that he might have an RPC method like
>> this:
>>
>> public interface MyService extends RemoteService {
>> MyBean getBean();
>> }
>>
>> Now, MyBean does not implement interface X, but a generator/AOP
>> interceptor could make a subclass of MyBean that has interface X
>> implement. IIRC, GWT RPC just invokes the default constructor, so
>> there's no way to intercept this and substitute a replacement.
>>
>> I think the other thing he might want to do is intercept client-side
>> UI classes and make them call addPropertyChangeListener() on a model
>> object based on certain invocations.
>>
>> -Ray
>>
>>> And Bruce, that's an interesting example. I was thinking how one
>>> would
>>> implement AOP in GWT, perhaps it's not as hard as I originally
>>> thought. Is there a way to extend this example to dynamically create
>>> proxies for any class that'll be advised by some aspect?
>>>
>>> Also, Nicolas, AFAIK, the GWT team (bobv) is working on a data
>>> binding
>>> (and validation?) framework. I'm hoping something will hit the
>>> incubator soon so we can all jump on board and help out. It'd
>>> definitely have saved us thousands of lines of glue code ;).
>>>
>>> P.S. Sorry about not writing up that how-to for GWTMockUtilities,
>>> Bruce. I'll try to do it some time this week.
>>>
>>> Best regards,
>>> --
>>> Arthur Kalmenson
>>>
>>>
>>>
>>> On Tue, Apr 21, 2009 at 2:58 PM, Ray Cromwell
>>> wrote:
Interesting question. Gin auto-creates RPC interfaces as well, for
example, if you have:
public interface MyFoo extends Ginjector {
MyServiceAsync getService();
}
then Gin implicitly looks for MyService.class and invokes
GWT.create(MyService.class) when calling getService(). Since Gin is
handling the creation, I'm not sure if it handles RPC methods with
classes have have @Inject annotations, but you could probably
setup a
separate binding. The de-serialization logic in RPC is not likely
to
allow Gin interception, since it apparently uses default
constructors
to create classes, and what you want it to do is delegate the
construction to some injectable mechanism (e.g. to substitute
your own
subclasses)
It doesn't sound impossible to make this work, and is probably
easier
to get right than trying to make new Foo() interceptable by the
compiler. I would join the Gin groups and ask the guys there
about it.
-Ray
On Tue, Apr 21, 2009 at 11:49 AM, nicolas de loof
wrote:
> Sounds a good solution.
> How would this solve the use case "data returned by RPC call" ?
>
> 2009/4/21 Ray Cromwell
>>
>> I really think Guice-style dependency injection is the way to
>> go to
>> solve this problem, rather than trying to emulate Java
>> Proxies/Classloader in the compiler. If you use Guice/Gin, then
>> in Gin
>> you can inject GWT.create-d versions, and in JUnit-mode, you
>> can use
>> re
