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.com<javascript:>
> > 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.
