Mozilla/mozilla/js/rhino/docs/javaone.html
2006-11-10 15:27:40 +00:00

101 lines
5.0 KiB
HTML

<!-- ***** BEGIN LICENSE BLOCK *****
- Version: MPL 1.1/GPL 2.0
-
- The contents of this file are subject to the Mozilla Public License Version
- 1.1 (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
- http://www.mozilla.org/MPL/
-
- Software distributed under the License is distributed on an "AS IS" basis,
- WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
- for the specific language governing rights and limitations under the
- License.
-
- The Original Code is Rhino code, released May 6, 1999.
-
- The Initial Developer of the Original Code is
- Netscape Communications Corporation.
- Portions created by the Initial Developer are Copyright (C) 1997-1999
- the Initial Developer. All Rights Reserved.
-
- Contributor(s):
-
- Alternatively, the contents of this file may be used under the terms of
- the GNU General Public License Version 2 or later (the "GPL"), in which
- case the provisions of the GPL are applicable instead of those above. If
- you wish to allow use of your version of this file only under the terms of
- the GPL and not to allow others to use your version of this file under the
- MPL, indicate your decision by deleting the provisions above and replacing
- them with the notice and other provisions required by the GPL. If you do
- not delete the provisions above, a recipient may use your version of this
- file under either the MPL or the GPL.
-
- ***** END LICENSE BLOCK ***** -->
<!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>