Notice the following points about the data conversions illustrated in Figure 19.2.
Also notice these points about the conversions illustrated in Figure 19.3.
var r = new java.awt.Rectangle(0,0,5,5); var w = r.width; // This is a Number object, not a primitive number. var new_w = w + 1; // Oops! new_w is now "51", not 6, as expected.
var r = new java.awt.Rectangle(0,0,5,5); var w = r.width.valueOf(); // Now we've got a primitive number. var new_w = w + 1; // This time, new_w is 6, as desired.
var w = r.width - 0; // Now we've got a primitive number.
Finally, when Java objects are read from Java fields (but not when they are read as the return value of a Java method), the returned value behaves in all respects like a JavaObject, except that passing it to the getClass() function fails with an error: "getClass expects a Java object argument". To work around this problem, to obtain a JavaObject object that getClass() recognizes as such, you can use code like the following:
var o = java.lang.System.out; // This should be a JavaObject var c = getClass(o); // ...but this causes an error. var p = new Object(o); // This is the workaround var c = getClass(p); // ...this works now.
var ambiguous = o.f; // Is it a JavaMethod or JavaObject? // It depends on how we use it in the future! ambiguous(); // Hmm...we must have meant the method. s += ambiguous; // In this case, we must have meant the field.
Notice that this ambiguity only arises when reading Java fields; there is no possibility of it when reading the return values of Java methods. Thus the differences the way values are read arises from the JavaSlot conversion process when Java field values are read.