303460 - Enhance Rhino's shell to execute compiled script .class files from command line

Status: RESOLVED FIXED

(Rhino Graveyard :: Core, defect)

Description

[Patrick Beard]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412.6 (KHTML, like Gecko) Safari/412.2
Build Identifier: 

Rhino provides an ahead of time compiler that creates a .class file that encapsulates a compiled 
JavaScript. Currently the only EASY way to run these directly from the command line is like this:

jsc script.js
java script

It would be nice to be able to load multiple scripts into the same shell like this:

jsc script1.js script2.js script3.js
js script1.class script2.class script3.class

This would let you use a mixture of interpreted and compiled scripts.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Patrick Beard]

Attachment: Patch to Main.java to execute compiled script .class files.

Comment 2

[Igor Bukanov]

(In reply to comment #1)
> Created an attachment (id=191627) [edit]
> Patch to Main.java to execute compiled script .class files.
> 

3 problems:

1. The patch ignore requested security restrictions: Use
SecurityController.createLoader(cx.getApplicationClassLoader(), securityDomain),
not new DefiningClassLoader()!

2. The does not report errors properly. That has to be done in the same way as
evaluateScript does. 

3. The patch does not handle urls which shell allows to use for scripts.

Comment 3

[Patrick Beard]

Attachment: Patch to Main.java to execute compiled script .class files. v2

Updated the patch to address your requirements. Added a new method,
evaluateCompiledScript(), which maps errors in a similar way to
evaluateScript(), and also supports URLs. We might want to revisit
processFileSecure() to always map filenames to URLs, rather than going through
a code path that almost always generates a MalformedURLException.

Comment 4

[Patrick Beard]

Attachment: Patch to Main.java to execute compiled script .class files. v3

This version correctly computes the name of the class using the leaf name of
the URL path.

Comment 5

[Igor Bukanov]

Attachment: Patch version with uniform treatment of file/url guessing

I changed the patch to treat file-or-url arguments uniformly both for *.js and
.class. The new version assumes that the argument is URL if it includes ':' or
filename if it does not.

Comment 6

[Patrick Beard]

My only concern was that on DOS/Windows, absolute path names will always include a ':' character, and 
will thus take the exception when failing to convert to a URL...

Comment 7

[Patrick Beard]

Perhaps ensuring that there's at least 2 or more characters in the string in front of the ':' character would 
be better. Or comparing against a list of known URL schemes. What was wrong with my approach of 
assuming path, then validating with File.exists()?

Comment 8

[Igor Bukanov]

(In reply to comment #7)
> Perhaps ensuring that there's at least 2 or more characters in the string in
front of the ':' character would 
> be better.

Right, I forgot about Windows paths. It is enough to assume that protocol should
be at least 2 chars IMO as with one-letter protocols c:yyy would be inherently
ambiguous.

> What was wrong with my approach of 
> assuming path, then validating with File.exists()?

When security manager prevents accessing file system calling File.exist would
through sn exception even if the URL can be accessed.

Comment 9

[Igor Bukanov]

Attachment: Windows paths are paths and execution cleanup.

1. The patch assume that path is URL if protocol is at least 2 letter long.

2. The patch uses shared code to read both source and compiled scripts and for
script execution using explicit Context.compileString to get Script from the
source.

Comment 10

[Igor Bukanov]

I committed the last patch. It would be nice to extend it to extract script
class name from the bytecode itself to allow package names in the compiled
scripts and to detected class/source based on the file context, not name, but
that is for a separated bug.