GWT 2.6.0 change from 2.5.1: member variables no longer initialized to null in prototype

[Jonathan McPherson]

Hi,

We recently upgraded from GWT 2.5.1 to 2.6.0, and have noticed a difference in behavior that's caused a few problems for us. 

Member variables of Java classes that had object types (e.g. String) formerly had the value 'null' if they had not been initialized. GWT implemented the null by adding to the corresponding JavaScript object prototype. For instance.

class foo

{

    private String bar;

    private boolean baz = true;  

}

generates something like this in 2.5.1:

defineSeed(...., foo_0)

_.bar = null;

_.baz = true;

But something like this in 2.6.0:

defineSeed(...., foo_0)

_.baz = true;

The result is that the raw value of any member variable that hasn't been assigned is now the undefined value rather than null. 

Was this behavior change intentional? Is there any way of disabling the behavior? We're primarily concerned about interoperability (wherein we pass member variable values to 3rd party libraries that don't like 'undefined') and JSNI (wherein we often test with === null). 

Jonathan.

[Thomas Broyer]

[+cc rluble]

On Tuesday, March 25, 2014 1:10:12 AM UTC+1, Jonathan McPherson wrote:

Hi,

We recently upgraded from GWT 2.5.1 to 2.6.0, and have noticed a difference in behavior that's caused a few problems for us. 

Member variables of Java classes that had object types (e.g. String) formerly had the value 'null' if they had not been initialized. GWT implemented the null by adding to the corresponding JavaScript object prototype. For instance.

class foo

{

    private String bar;

    private boolean baz = true;  

}

generates something like this in 2.5.1:

defineSeed(...., foo_0)

_.bar = null;

_.baz = true;

But something like this in 2.6.0:

defineSeed(...., foo_0)

_.baz = true;

The result is that the raw value of any member variable that hasn't been assigned is now the undefined value rather than null. 

Was this behavior change intentional?

Yes: https://gwt-review.googlesource.com/3760

 

Is there any way of disabling the behavior? We're primarily concerned about interoperability (wherein we pass member variable values to 3rd party libraries that don't like 'undefined') and JSNI (wherein we often test with === null).

AFAICT, there's (almost) no reason to use "=== null" in JSNI; you should use "== null" instead (and "===" for everything else than null/undefined)