JavaScript and Embedded Objects

JavaScript and Embedded Objects - Issues with JavaScript-Driven Applets
(Page 5 of 15 )

Experienced programmers might be asking at this point why one would choose to embed a Java applet alongside JavaScript in a page. One reason might be to avoid having to re-implement code in JavaScript that is readily available in Java. Another reason is that many people feel that user interfaces written in (X)HTML/CSS are easier to implement than in Java (though some people believe the opposite!). One major benefit of using a Web-based interface to drive an embedded applet is that changes to the interface can be made without the hassle of recompiling the Java code.

Discovering Interfaces

Many new programmers wonder how to find out what “hooks” are made available by a particular applet. An easy way to find out is to examine the source code (the .java file) associated with the applet. If it is not available, you can use a for/in loop on the appropriate Applet object to print out its properties. Anything that is not usually a property of an Applet browser object is a part of the interface defined by the applet’s class. However, this method is discouraged because it gives you no information about the type of arguments the applet’s methods expect. Generally, it’s not a good idea to drive an applet from JavaScript unless you know for sure how the interface it exposes should be used.

Type Conversion

The issue of type conversion in method arguments has serious bearing on JavaScript-driven applets. While most primitive JavaScript types are easily converted to their Java counterparts, converting complicated objects can be problematic. If you need to pass user-defined or nontrivial browser objects to applets, close examination of each browser’s type conversion rules is required. A viable option is to convert the JavaScript object to a string before passing it to an applet. The applet can then manually reconstruct the object from the string. A better option might be to retrieve the objects directly using the Java classes mentioned in the following section.

Security

A final issue is the fact that most browsers’ security models will prevent an applet from performing an action at the behest of JavaScript that the script could not otherwise perform on its own. This makes sense when one considers that Java is (in theory) designed to protect the user from malicious code. Experimentation with the restrictions placed on JavaScriptdriven applets reveals inconsistent security policies among different browsers and versions.

Accessing JavaScript with Applets

Although it may come as a surprise, it is possible for Java applets to drive JavaScript. Internet Explorer, Netscape, and Mozilla-based browsers are capable of using the netscape Java package, which defines a family of class libraries for JavaScript interaction. In particular, the JSObject class ( netscape.javascript.JSObject ) allows an applet to retrieve and manipulate JavaScript objects in the current page. In addition, it affords an applet the ability to execute arbitrary JavaScript in the browser window as if it were a part of the page.

On the (X)HTML side of things, all that is required to enable this functionality is the addition of the mayscript attribute to the <applet> tag in question. The mayscript attribute is a nonstandard security feature used to prevent malicious applets from modifying the documents in which they are contained. Omitting this attribute (theoretically) prevents the applet from crossing over into “browser space,” though enforcement by browsers is spotty. While this is a powerful capability, Java-driven JavaScript is rarely used in practice.

Details about these classes can be found in Java documentation for the specific browsers.

This chapter is from JavaScript: The Complete Reference, second edition, by Thomas Powell and Fritz Schneider, McGraw-Hill/Osborne, ISBN: 0072253576). Check it out at your favorite bookstore today. Buy this book now.

blog comments powered by Disqus