It’s Friday…

 

How to waste a weekend

I spent half of Friday tracking down a GWT problem that caused problems in both Opera and IE. By trial and error I kind of isolated it to my use of syntactic sugar (yeah, I know…) Then I spent most of Saturday trying to come up with a pithy reproducible case. Here it is
(posted to http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/ae307a25041f3a7e/, reproducing here for my own reference):

Consider the following source (made with -style pretty):

package x.y.z;

import com.google.gwt.core.client.*;
import com.google.gwt.user.client.ui.*;

public class WastedWeekend extends Label implements EntryPoint {
public void onModuleLoad() {
foo();
}

void foo() {
Button[] stuff = new Button[1];
doNothing(stuff[0] = new Button());
}

void doNothing(Widget w) {
RootPanel.get().add(w);
}

The foo() function translates into the following:


function _$foo(_this$static){
var _stuff;
_stuff = _initDims('[Lcom.google.gwt.user.client.ui.Button;', [0],
[5], [1], null);
_$doNothing(_this$static, _stuff[0] = _$Button(new _Button()));

}

This is all well and good. But now let me change, in foo() the type of “stuff” to Label
(that is, the superclass of WastedWeekend). That is, as follows:


void foo() {
Label[] stuff = new Label[1];
doNothing(stuff[0] = new Label());

}

Now the translation is:


functionfunction _$foo(_this$static){
var _stuff;
_stuff = _initDims('[Lcom.google.gwt.user.client.ui.Label;', [0],
[7], [1], null);
_$doNothing(_this$static, _setCheck(_stuff, 0, _$Label(new
_Label())));

}

Notice the difference? What’s going on?

This is reproducible whenever this sample WastedWeekend class is the same subclass of the same
Widget as the stuff variable.
(I did not go into more details as far as inheritance tree, so I don’t know what happens if they are siblings or something)…

Now, should I spend Sunday trying to actually figure this out?

Some notes

  1. One can argue that a step from one VM into another should not, from debugger’s point of view, be a step within one thread, but a new thread should be open. But this involves too much interfacing with the debugger (thinking about how to tell it that it needs to register a ThreadStartEvent to open a new thread when it didn’t request it, e.g.), so I scrap the idea, but feel it worthy of noting.
  2. %#@#$%@#$%@^@@^%

    java.lang.ClassCastException: org.hrum.dbdb.DelegatingThreadReference cannot be cast to com.sun.tools.jdi.ThreadReferenceImpl

    Did I mention how this pisses me off?

  3. Ok, even though Dbdb needs Java 6, the proof-of-concept is not supporting
    new JDBC driver
    loading
    … Just a note to self…