pjs/js/rhino/docs/javaone.html

67 строки
3.4 KiB
HTML
Исходник Обычный вид История

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Norris Boyd">
<meta name="GENERATOR" content="Mozilla/4.6 [en] (WinNT; U) [Netscape]">
<meta name="KeyWords" content="Rhino, JavaScript, Java">
<title>Followup to JavaOne</title>
</head>
<body bgcolor="#FFFFFF">
<center>
<h1>
Followup to JavaOne session on Rhino</h1></center>
This page is intended to follow up on the <a href="http://www.javasoft.com/javaone/">JavaOne</a>
session on <a href="http://industry.java.sun.com/javaone/99/event/0,1768,629,00.html">"Rhino:
JavaScript for the Java Platform"</a>. I hope it will be useful whether
or not you actually attended the talk.
<br>&nbsp;
<h2>
Slides</h2>
<a href="http://industry.java.sun.com/javaone/99/pdfs/e629.pdf">Slides</a>
(PDF file, 1112246 bytes)&nbsp; can be downloaded from Sun's site.
<br>&nbsp;
<br>&nbsp;
<h2>
More on Q &amp; A</h2>
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 <a href="news://news.mozilla.org/netscape.public.mozilla.jseng">netscape.public.mozilla.jseng</a>
so people can ask addition questions or comments there.
<h3>
Java classes visible to scripts</h3>
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 <a href="apidocs/org/mozilla/javascript/SecuritySupport.html">SecuritySupport</a>
class that allows embedders to choose which classes are exposed to scripts.
<h3>
Easier "importing" of Java classes</h3>
Another attendee suggested that the current method of referring to Java
classes (like <tt>java.lang.String</tt> or <tt>Packages.org.mozilla.javascript.Context</tt>)
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.
<p>To see what I've done, take a look at the javadoc for the <a href="apidocs/org/mozilla/javascript/ImporterTopLevel.html">ImporterTopLevel</a>
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.
<p>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.
<p>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.
<p>So I'm interested in people's opinion: Is this benefit worth the costs?
<p>
<hr WIDTH="100%">
<br><a href="index.html">back to top</a>
</body>
</html>