Re: [openvrml-develop] Status update: modularization

[Braden M. <br...@en...>]

On Mon, 2006-10-23 at 00:30 +0200, Josip Almasi wrote:
> Braden McDaniel wrote:
> > At this point I have successfully ported the JavaScript scripting 
> > backend to a dynamically loaded module; it seems to be working just 
> > fine. I would like to take this opportunity to fix the long-ailing Java 
> > scripting engine. I'm just now getting an idea of what I'm in for.
> > 
> > It hasn't been compiling for a while; but that's not the worst of the 
> > problems. It is currently written assuming that all Java scripts in a 
> > world would share the same VM. I don't think that's desirable; and I'm 
> > even less sure that it's workable: it's my understanding that each 
> > vrml.node.Script subclass will need to have its base URI added to the 
> > classpath; and surely different Scripts need to run in isolation from 
> > one another.
> 
> Oh I'm not that sure about that classpath thing. IIRC from the spec, 
> each script needs to have access to full usual java stuff. Like, 
> standard J2SE API.

I see no obvious way to avoid access to the Java standard libraries--and
as you note, I wouldn't want that anyway.

You have the opportunity to set the classpath when starting the VM via
JNI. The semantics of this are the same as the -cp command line argument
to the java runtime executable; i.e., it overrides the CLASSPATH
environment variable.

As such, I'll get the value of CLASSPATH from the environment and
prepend it to the setting passed to the VM.

> The catch is, other components, 'optional' packages may be available 
> too. Like, JMF, J3D, JavaComm etc. We usually enable them by placing 
> them into jre/lib/ext or adding to runtime by java -Djava.ext.dirs=...
> So that's why I call them 'usual' - whatever this specific JVM has 
> installed.
> And you can use that to your advantage - just exec jvm with 
> -Djava.ext.dirs=scripts dir(s). IIRC it has to be defined during JVM 
> bootstrap.
> As for isolating scripts from one another, I think this could be handled 
> by java security manager/policy. Like, you can forbid reflection so an 
> object can't inspect others.

A quick experiment demonstrates for me that applets on the same Web page
run in the same VM. While I question the soundness of that design, I
know (at least one reason) why they did it: the VM has historically been
a pig and it's only relatively recently that Sun has begun to optimize
concurrently running VMs to share resources.

> > So, proceeding with the assumption that we need a VM-per-Script node, 
> > the JNI documentation says that you can have no more than one VM per 
> > thread. That means that the openvrml::script subclass in the Java script 
> >   engine needs to spawn its own thread and function more-or-less as an 
> > active object. This is nontrivial code, none of which is in place.
> 
> I say drop VM-per-Script idea.
> One interpreter to host scripts, that's ok.
> I'll gladly help you with that, in fact I think we can use VRSpaceLoader 
> for starters. That's what it does, loads classes in runtime...
> As for thread-per-script model... sure, it has to be done that way.
> So, say, you spawn a jvm and send/receive events thru a pipe or...?
> Suppose you send events like 'script <id> <eventname> <eventvalue>'.
> There's more vrspace code to handle it, but it's around already.
> And yes it's not trivial...;)

At the moment, I'm just planning on running the VM in OpenVRML's main
(rendering) thread. I could give the VM its own thread if I need to--and
in that case I'd simply use something along the lines of an active
object pattern to transmit data--no separate process, so no pipes.

As for loading the classes, I'm under the impression that I can just use
URLClassLoader for that. I think I can construct one of these via JNI
and tell it to construct an instance of the vrml.node.Script subclass.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>