[gwt-contrib] Static fields on JavaScriptObjects
Hello Everyone, I am a little confused about some issues I encountered on the issue tracker and need some help. This one is about a static field on a JSO: https://code.google.com/p/google-web-toolkit/issues/detail?id=8060 From the docs: Overlay types cannot have instance fields. The fields would have no place to live in web mode. Programmers should instead make an explicit wrapper class and put the fields there. JavaScriptObjects are created in JavaScriptCode (this is why they need a at least protected constructor). Do we have a clinit for JSOs or am I assuming correctly that this is a misuse of a JSO? -Daniel -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
On Sat, Mar 16, 2013 at 3:09 PM, Daniel Kurka kurka.dan...@gmail.comwrote: I am a little confused about some issues I encountered on the issue tracker and need some help. This one is about a static field on a JSO: https://code.google.com/p/google-web-toolkit/issues/detail?id=8060 From the docs: Overlay types cannot have instance fields. The fields would have no place to live in web mode. Programmers should instead make an explicit wrapper class and put the fields there. JavaScriptObjects are created in JavaScriptCode (this is why they need a at least protected constructor). Do we have a clinit for JSOs or am I assuming correctly that this is a misuse of a JSO? JSOs can't have clinits, since generally they are created by pure JS code, and in particular it is likely code outside of GWT's control. You conceivably could allow default-initialized static fields (which would basically just be namespaced globals), but I'm not sure what the point is. I suppose you could also allow static finals that are just compile-time constants (hoisting initializers to always happen has been discussed, but could potentially execute expensive code at startup), but I think it is better to leave it out than to have only partial support. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
Thanks John for clearing this up. This was exactly what I had in mind. I will close the issue AsDesigned, maybe we should document this is little better. -Daniel Am 16.03.2013 um 20:40 schrieb John A. Tamplin j...@jaet.org: On Sat, Mar 16, 2013 at 3:09 PM, Daniel Kurka kurka.dan...@gmail.com wrote: I am a little confused about some issues I encountered on the issue tracker and need some help. This one is about a static field on a JSO: https://code.google.com/p/google-web-toolkit/issues/detail?id=8060 From the docs: Overlay types cannot have instance fields. The fields would have no place to live in web mode. Programmers should instead make an explicit wrapper class and put the fields there. JavaScriptObjects are created in JavaScriptCode (this is why they need a at least protected constructor). Do we have a clinit for JSOs or am I assuming correctly that this is a misuse of a JSO? JSOs can't have clinits, since generally they are created by pure JS code, and in particular it is likely code outside of GWT's control. You conceivably could allow default-initialized static fields (which would basically just be namespaced globals), but I'm not sure what the point is. I suppose you could also allow static finals that are just compile-time constants (hoisting initializers to always happen has been discussed, but could potentially execute expensive code at startup), but I think it is better to leave it out than to have only partial support. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
The problem with this answer is that the failure is silent and surprising for Java developers, and that the optimizations can make it even more so. If I recall correctly, calling a static method in the same type from an instance method is not enough to get the static initializer called - an optimization prunes the clinit. I have a patch that restores clinits from instance methods, but I'm out of reach of it at the moment. I haven't made a code review yet in the interest of adding tests for this case. If we do decide that cl units should be pruned, we should stop cutting them from other newly 'static' methods - at least in that case bit must be a bug. If not that, then emit a warning? On Mar 16, 2013 1:44 PM, Daniel Kurka kurka.dan...@gmail.com wrote: Thanks John for clearing this up. This was exactly what I had in mind. I will close the issue AsDesigned, maybe we should document this is little better. -Daniel Am 16.03.2013 um 20:40 schrieb John A. Tamplin j...@jaet.org: On Sat, Mar 16, 2013 at 3:09 PM, Daniel Kurka kurka.dan...@gmail.comwrote: I am a little confused about some issues I encountered on the issue tracker and need some help. This one is about a static field on a JSO: https://code.google.com/p/google-web-toolkit/issues/detail?id=8060 From the docs: Overlay types cannot have instance fields. The fields would have no place to live in web mode. Programmers should instead make an explicit wrapper class and put the fields there. JavaScriptObjects are created in JavaScriptCode (this is why they need a at least protected constructor). Do we have a clinit for JSOs or am I assuming correctly that this is a misuse of a JSO? JSOs can't have clinits, since generally they are created by pure JS code, and in particular it is likely code outside of GWT's control. You conceivably could allow default-initialized static fields (which would basically just be namespaced globals), but I'm not sure what the point is. I suppose you could also allow static finals that are just compile-time constants (hoisting initializers to always happen has been discussed, but could potentially execute expensive code at startup), but I think it is better to leave it out than to have only partial support. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
On Sat, Mar 16, 2013 at 5:30 PM, Colin Alworth niloc...@gmail.com wrote: The problem with this answer is that the failure is silent and surprising for Java developers, and that the optimizations can make it even more so. If I recall correctly, calling a static method in the same type from an instance method is not enough to get the static initializer called - an optimization prunes the clinit. I have a patch that restores clinits from instance methods, but I'm out of reach of it at the moment. I haven't made a code review yet in the interest of adding tests for this case. I don't see how you can add clinits on a JSO -- the point is it is a plain JS object under the hood (ignoring all the magic to make it work in DevMode). If you call a method or access a field from pure JS, how can it know to call the clinit? If we do decide that cl units should be pruned, we should stop cutting them from other newly 'static' methods - at least in that case bit must be a bug. If not that, then emit a warning? I'm fine with making it an error. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
Am 16.03.2013 um 22:43 schrieb John A. Tamplin j...@jaet.org: On Sat, Mar 16, 2013 at 5:30 PM, Colin Alworth niloc...@gmail.com wrote: The problem with this answer is that the failure is silent and surprising for Java developers, and that the optimizations can make it even more so. If I recall correctly, calling a static method in the same type from an instance method is not enough to get the static initializer called - an optimization prunes the clinit. I have a patch that restores clinits from instance methods, but I'm out of reach of it at the moment. I haven't made a code review yet in the interest of adding tests for this case. I don't see how you can add clinits on a JSO -- the point is it is a plain JS object under the hood (ignoring all the magic to make it work in DevMode). If you call a method or access a field from pure JS, how can it know to call the clinit? If we do decide that cl units should be pruned, we should stop cutting them from other newly 'static' methods - at least in that case bit must be a bug. If not that, then emit a warning? I'm fine with making it an error. This should be an error. You can easily build a wrapper if you need fields. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Static fields on JavaScriptObjects
If you call a method or access a field from pure JS, you aren't going to
get the JSO implementation -
com.google.gwt.dom.client.Element.removeClassName(String) doesn't exist in
the underlying browser, so we build it in Java, and talk to methods/fields
which *do* exist in the browser. In other cases we dispatch to static
methods that exist elsewhere in GWT. You can't call it from pure JS, so how
it works or what it needs shouldn't be considered when looking at how JSO
should behave and what code should be emitted.
There are many static fields which exist in existing JSOs already, but most
(all?) are final, and are Strings or other primitives, so are already
constants, not just fields. In the linked bug, an array is being kept, and
it isn't initialized in time. I've only found one case of a static field in
a JSO, and the docs suggest that it is optimized for dev mode.
Hypothetically, if Document were subclassed (it isn't final) and get() were
invoked by an instance method (consider referring to another document from
within an iframe), this issue could be tickled if it weren't for that
'optimization':
/**
* We cache Document.nativeGet() in DevMode, because crossing the JSNI
* boundary thousands of times just to read a constant value is slow.
*/
private static Document doc;
/**
* Gets the default document. This is the document in which the module is
* running.
*
* @return the default document
*/
public static Document get() {
if (GWT.isScript()) {
return nativeGet();
}
// No need to be MT-safe. Single-threaded JS code.
if (doc == null) {
doc = nativeGet();
}
return doc;
}
I recognize that the primary intent of JavaScriptObject is to offer a Java
API to a JavaScript object, but there are plenty of cases where that JSOs
are used to achieve other points, or contain logic beyond what might
normally be necessary. Ray Cromwell wrote a post a few years ago that
encouraged using JSOs to 'cheat' the Java type system a bit -
http://timepedia.blogspot.com/2009/04/gwts-type-system-is-more-powerful-than.html
- these examples don't make use of fields, but it seems a logical next step
to add a little logic to some of these psuedo-categories.
To look at my own use case, GXT extends Element as XElement to allow Java
method calls to cache some values as XElement is used. We've worked around
this by moving those to a static inner non-JSO type - they remain private,
static, and final, and behave as expected with this workaround.
So, with all of this in mind, a change to make this 'as designed' will
warn/error on any static field that is not a) final and b)
String/primitive, and on any static block? Or, can we consider the utility
of the JSO class to be something that is actually meant to be used only
from Java, so we don't care what happens to the underlying JavaScript
object, and how that continues to behave as JS normally would?
On Saturday, March 16, 2013 4:43:13 PM UTC-5, John A. Tamplin wrote:
On Sat, Mar 16, 2013 at 5:30 PM, Colin Alworth nilo...@gmail.comjavascript:
wrote:
The problem with this answer is that the failure is silent and surprising
for Java developers, and that the optimizations can make it even more so.
If I recall correctly, calling a static method in the same type from an
instance method is not enough to get the static initializer called - an
optimization prunes the clinit.
I have a patch that restores clinits from instance methods, but I'm out
of reach of it at the moment. I haven't made a code review yet in the
interest of adding tests for this case.
I don't see how you can add clinits on a JSO -- the point is it is a plain
JS object under the hood (ignoring all the magic to make it work in
DevMode). If you call a method or access a field from pure JS, how can it
know to call the clinit?
If we do decide that cl units should be pruned, we should stop cutting
them from other newly 'static' methods - at least in that case bit must be
a bug. If not that, then emit a warning?
I'm fine with making it an error.
--
John A. Tamplin
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
