Rhino and applet issues

[Qu0ll]

I have a couple of questions related to running Rhino in an applet.

1. Does running Rhino in an applet mean that compilation of scripts to byte
codes is not possible? I am guessing yes.
2. Does running Rhino in an applet mean that all scripts will be run with
optimisation level of -1 i.e. no optimisation?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Andrew Thompson]

I have a couple of questions related to running Rhino in an applet.

1. Does running Rhino in an applet mean that compilation of scripts to byte
codes is not possible?  I am guessing yes.

I am unfamiliar with Rhino, but was curious. What
makes you guess that? What does Rhino do that you
suspect cannot be done in an applet, and why?

 

[Arne Vajhøj]

I am unfamiliar with Rhino, but was curious. What
makes you guess that? What does Rhino do that you
suspect cannot be done in an applet, and why?

Rhino is the callable JavaScript interpreter written
in Java (http://www.mozilla.org/rhino/).

Arne

 

[Roedy Green]

Rhino is the callable JavaScript interpreter written
in Java (http://www.mozilla.org/rhino/).

If it is written in Java, about the only thing it could do that would
make it not work is trigger a security exception by reading or writing
a local file for example. You would have to sign your applet and
provide for permissions to do the dangerous things it might want to
do.

See http://mindprod.com/jgloss/signedapplets.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change."
~ Charles Darwin

 

[Qu0ll]

I am unfamiliar with Rhino, but was curious. What
makes you guess that? What does Rhino do that you
suspect cannot be done in an applet, and why?

Well I was assuming that it's not possible to compile a script to byte codes
and then run them on the JVM without accessing the local file system. Are
you saying that this can be done in memory?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Andrew Thompson]

Well I was assuming that it's not possible to compile a script to byte codes
and then run them on the JVM without accessing the local file system.

Well, since you *mention that* I might add..

.. Are
you saying that this can be done in memory?

...if Rhino can do that using input / output streams,
then it can do that using ByteArrayInput/OutputStream -
and do the compilation entirely in memory.

 

[Qu0ll]

Well, since you *mention that* I might add..


..if Rhino can do that using input / output streams,
then it can do that using ByteArrayInput/OutputStream -
and do the compilation entirely in memory.

It can probably compile it but how would it then run it?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Andrew Thompson]

(Rhino in sandbox)

It can probably compile it but how would it then run it?

Using one of the ClassLoader.defineClass()* methods
that accepts a byte[].

* E.G.
<http://java.sun.com/javase/6/docs/api/java/lang/
ClassLoader.html#defineClass(java.lang.String,%20byte[],%20int,%20int)

http://java.sun.com/javase/6/docs/a...fineClass(java.lang.String, byte[], int, int)

If you launch/instantiate the compiled the class
from a sandboxed applet, it will be sandboxed as
well.

 

[Qu0ll]

(Rhino in sandbox)

It can probably compile it but how would it then run it?

Using one of the ClassLoader.defineClass()* methods
that accepts a byte[].

* E.G.
<http://java.sun.com/javase/6/docs/api/java/lang/
ClassLoader.html#defineClass(java.lang.String,%20byte[],%20int,%20int)

http://java.sun.com/javase/6/docs/a...fineClass(java.lang.String, byte[], int, int)

If you launch/instantiate the compiled the class
from a sandboxed applet, it will be sandboxed as
well.

I thought you couldn't use ClassLoader in an applet.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Andrew Thompson]

On Apr 24, 5:01 pm, "Qu0ll" <[email protected]> wrote:

(Rhino in sandbox)

Using one of the ClassLoader.defineClass()* methods
that accepts a byte[].

....
I thought you couldn't use ClassLoader in an applet.

Applets use class loaders all the time.

Getting an URLClassLoader (from memory) required a
trusted applet, but I had not tried stamping out a
Class from bytes in either a trusted, or sandboxed
applet.

So I think it comes down to..
"What happened when you tried it?"

 

[Qu0ll]

On Apr 24, 5:01 pm, "Qu0ll" <[email protected]> wrote:

(Rhino in sandbox)

It can probably compile it but how would it then run it?

Using one of the ClassLoader.defineClass()* methods
that accepts a byte[].

...
I thought you couldn't use ClassLoader in an applet.

Applets use class loaders all the time.

Getting an URLClassLoader (from memory) required a
trusted applet, but I had not tried stamping out a
Class from bytes in either a trusted, or sandboxed
applet.

So I think it comes down to..
"What happened when you tried it?"

As you probably guessed, I haven't tried it. I don't know if Rhino does its
compiling in memory or not. I was just hoping someone who knew about Rhino
could help me with an investigation into the possible use of Rhino in an
applet.

I know that Batik (the Java SVG toolkit) uses Rhino and works in an applet
but I have heard (and I can't recall exactly where) that the scripts are not
compiled for some reason. I was wanting to know if this is a limitation of
Rhino or something to do with the way Batik uses it.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Qu0ll]

On Apr 24, 5:01 pm, "Qu0ll" <[email protected]> wrote:

(Rhino in sandbox)

It can probably compile it but how would it then run it?

Using one of the ClassLoader.defineClass()* methods
that accepts a byte[].

...
I thought you couldn't use ClassLoader in an applet.

Applets use class loaders all the time.

Getting an URLClassLoader (from memory) required a
trusted applet, but I had not tried stamping out a
Class from bytes in either a trusted, or sandboxed
applet.

Thinking about this, if it were possible to do this then the server could
feasibly compile any class it wanted, transmit the byte codes to the applet
and then have objects of that class instantiated in the applet even when the
applet initially knows nothing about that class. Although that would
obviously be extremely useful, I have never heard that such a technique was
feasible and therefore I assume it can't be done.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Lew]

Thinking about this, if it were possible to do this then the server
could feasibly compile any class it wanted, transmit the byte codes to
the applet and then have objects of that class instantiated in the
applet even when the applet initially knows nothing about that class.
Although that would obviously be extremely useful, I have never heard
that such a technique was feasible and therefore I assume it can't be done.

I have never heard that such a technique was infeasible and therefore I assume
it can be done.

It's just standard class loading. How do you think applets obtain bytecode
from their servers?

What research did you do into this matter?

 

[Qu0ll]

I have never heard that such a technique was infeasible and therefore I
assume it can be done.

It's just standard class loading. How do you think applets obtain
bytecode from their servers?

What research did you do into this matter?

I have had a lot to do with applets over the last few years, participated in
the Sun applet forum and this forum, spoken to colleagues and read many
books on the subject but have never heard of such a technique in practice.
If feasible it would mean that you could load entire modules of your applet
on an as-required basis simply by having the server transmit the class files
when you need them. Whilst it is possible to dynamically load JARs to some
extent, it is problematic and for some reason the code that is loaded in
this way seems to execute a lot slower than code in the applet JAR. This
has been discussed a number of times.

The other reason why I doubt its feasibility is because (it appears) Rhino
can't do it. Surely the Rhino developers would be able to get this to work
if it really were possible.

I for one would love this to be possible. Of course you rarely need to load
just one class at a time so proper implementation of dynamic JAR loading
would be even better.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Lew]

I have had a lot to do with applets over the last few years,
participated in the Sun applet forum and this forum, spoken to
colleagues and read many books on the subject but have never heard of
such a technique in practice. If feasible it would mean that you could
load entire modules of your applet on an as-required basis simply by
having the server transmit the class files when you need them.

Isn't that exactly what applets already do?

Whilst it is possible to dynamically load JARs to some extent, it is
problematic and for some reason the code that is loaded in this way
seems to execute a lot slower than code in the applet JAR. This has
been discussed a number of times.

Isn't it true that applets can load classes on demand from their server and
always have been able to do so?

Slow does not mean infeasible. I wonder about the claim of slow running,
though. Once code is loaded, how in the world would the JVM distinguish it to
run it slower? Is there a "recent immigrant" prejudice against newly
enfranchised bytecode?

Can you point us to any data on these matters? What you are saying
contradicts what I've heard about applets for the last ten-plus years.

 

[Qu0ll]

I have never heard that such a technique was infeasible and therefore I
assume it can be done.

It's just standard class loading. How do you think applets obtain
bytecode from their servers?

What research did you do into this matter?

I now see why this is impossible. The various defineClass() methods in
ClassLoader are all marked "protected final" and the class loader used in an
applet is of type sun.plugin2.applet.Applet2ClassLoader which has no public
or protected constructors. I can't see any way to extend it so that I can
call defineClass().

Can anyone see a way around this?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]