Java is a strongly typed language with a relatively large number of data types. JavaScript is an untyped language with a relatively small number of types. Because of these major structural differences in the two languages, one of the central responsibilities of LiveConnect is data conversion. When JavaScript sets a Java class or instance field or passes an argument to a Java method, a JavaScript value must be converted to an equivalent Java value. And when JavaScript reads a Java class or instance field or obtains the return value of Java method, that Java value must be converted into a compatible JavaScript value.[2]
[2] In addition, data conversion must also happen when Java reads or writes a JavaScript field or invokes a JavaScript method. These conversions are done differently, however, and will be described later in the chapter when we explain how to use JavaScript from Java. For now, we're only considering the data conversion that happens when JavaScript code interacts with Java, not the other way around.
Figure 19.2 and Figure 19.3 illustrate how data conversion is performed when JavaScript writes Java values and when it reads them.
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.
In addition to the note above, there is a very important concept that must be made clear in order for you to fully understand Figure 19.2 and Figure 19.3. This is the idea of "wrapper" objects. While conversions between most JavaScript and Java primitive types are possible, conversions between object types are not, in general, possible. This is why LiveConnect defines the JavaObject object in JavaScript--it represents a Java object that cannot be directly converted to a JavaScript object. In a sense, a JavaObject is a JavaScript "wrapper" around a Java object. When JavaScript reads a Java value (a field or the return value of a method), Java objects are "wrapped" and JavaScript sees a JavaObject.
A similar thing happens when JavaScript writes a JavaScript object into a Java field or passes a JavaScript object to a Java method. There is no way to convert the JavaScript object to a Java object, so the object gets wrapped. Just as the JavaScript wrapper for a Java object is a JavaObject, the Java wrapper for a JavaScript object is the Java class netscape.javascript.JSObject.
It gets interesting when these wrapper objects are passed back. If JavaScript writes a JavaObject into a Java field or passes it to Java method, then LiveConnect first "unwraps" the object, converting the JavaObject back into the Java object that it represents. And similarly, if JavaScript reads a Java field or gets the return value of a Java method that is an instance of netscape.javascript.JSObject, then that JSObject is also unwrapped to reveal and return the original JavaScript object.
In Navigator 3.0, LiveConnect returns slightly different data types when a value is read from a Java field than it does when the same value is read as the return value of a Java method. Figure 19.3 shows that all Java primitive numeric types and instances of java.lang.Double are returned as primitive JavaScript numbers or as Number objects. When the numeric return value of a method is read, it is returned as a primitive JavaScript number. But when a numeric value is read from a field, it is returned as a Number object.
Recall that Number objects in JavaScript behave almost the same, but not exactly, as primitive JavaScript numbers. One important difference is that Number objects, like all JavaScript objects, use the + operator for string concatenation rather than addition. So code like the following can yield unexpected results:
var r =index.html new java.awt.Rectangle(0,0,5,5); var w = r.width; // This is a Number object, not a primitive number. var new_w =index.html w + 1; // Oops! new_w is now "51", not 6, as expected.
var r =index.html new java.awt.Rectangle(0,0,5,5); var w = r.width.valueOf(); // Now we've got a primitive number. var new_w =index.html w + 1; // This time, new_w is 6, as desired.
var w =index.html r.width - 0; // Now we've got a primitive number.
The same discrepancy occurs when Java primitive Boolean values and instances of java.lang.Boolean are read from Java fields--they are returned as JavaScript Boolean objects even though the same Java value would have been returned as a primitive Boolean value if it had been the return value of a method. You can work around this with the valueOf() method, as above.
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 =index.html java.lang.System.out; // This should be a JavaObject var c =index.html getClass(o); // ...but this causes an error. var p =index.html new Object(o); // This is the workaround var c =index.html getClass(p); // ...this works now.
The fact that values are returned differently when read from a field than when read as method return values is not exactly a bug in LiveConnect; it is more of a misfeature, and it is one that the designers of LiveConnect may not be able to correct in future versions of Navigator. It stems from a subtle incompatibility between Java and JavaScript. In Java methods are not data types as they are in JavaScript, so it is perfectly legal to define a method that has the same name as a field. JavaScript, however, allows us to treat methods, including Java methods, as variables that we can manipulate, and so it is not possible to use the same name for a JavaScript property and a method.
We run into a problem when we try to use a Java class has a field and a method by the same name. Suppose that a JavaObject o refers to an instance of such a class, and the name shared by the field and the method is f. Then the JavaScript expression o.f is ambiguous; JavaScript does not know whether we are referring to the method or the field. Consider this code:
var ambiguous =index.html 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 +=index.html 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.
file: /Techref/language/java/script/definitive/ch19_03.htm, 16KB, , updated: 2019/10/14 16:00, local time: 2024/8/22 06:10,
18.226.87.165:LOG IN
|
©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions? <A HREF="http://piclist.com/tecHREF/language/java/script/definitive/ch19_03.htm"> [Chapter 19] 19.3 LiveConnect Data Conversion</A> |
Did you find what you needed? |
![]() o List host: MIT, Site host massmind.org, Top posters @none found - Page Editors: James Newton, David Cary, and YOU! * Roman Black of Black Robotics donates from sales of Linistep stepper controller kits. * Ashley Roll of Digital Nemesis donates from sales of RCL-1 RS232 to TTL converters. * Monthly Subscribers: Gregg Rew. on-going support is MOST appreciated! * Contributors: Richard Seriani, Sr. |
Ashley Roll has put together a really nice little unit here. Leave off the MAX232 and keep these handy for the few times you need true RS232! |
.