Followup to JavaOne session on Rhino

This page is intended to follow up on the JavaOne session on "Rhino: JavaScript for the Java Platform". I hope it will be useful whether or not you actually attended the talk.

Slides

Slides (PDF file, 1112246 bytes) can be downloaded from Sun's site.

More on Q & A

Following the talk there was an excellent question and answer session where many attendees asked good questions and offered useful suggestions. I'll follow up on some of those here. I'll start a thread on the newsgroup netscape.public.mozilla.jseng so people can ask addition questions or comments there.

Java classes visible to scripts

One attendee raised the point that many embeddings may not want scripts to be able to access all Java classes. This is an excellent point, and I've implemented an addition to the SecuritySupport class that allows embedders to choose which classes are exposed to scripts.

Easier "importing" of Java classes

Another attendee suggested that the current method of referring to Java classes (like java.lang.String or Packages.org.mozilla.javascript.Context) could be improved. I've implemented a set of changes that make importing easier, but I'm not convinced that adding them is the right thing to do due to some drawbacks.

To see what I've done, take a look at the javadoc for the ImporterTopLevel class. You'll see that it's now possible to make function calls to "import" Java classes so that they can be referred to without qualification. I didn't use the word "import" because that's a keyword in JavaScript.

There are a few drawbacks to this implemenation. First, there is a runtime cost associated with every lookup of a top-level variable. The problem is that it's not possible to use the Java runtime to determine the set of classes from a given package. Instead, importing the package "java.util" saves the package name in a special list and every access to the global scope that fails to find a matching variable causes the runtime to see if there is a class by that name in the "java.util" package. Even for lookups that succeed there is an additional method call.

Another drawback to this implementation is namespace pollution: now "importClass" and "importPackage" have special meaning. It's still possible to substitute your own variables for these functions, but it's still possible that program behavior could change.

So I'm interested in people's opinion: Is this benefit worth the costs?