On 11/14/06, Carl Witty cwitty@newtonlabs.com wrote:>
"... we can provide (audited) java classes for anything performance critical..." Really? Including fluid dynamics simulators, rigid-body kinematics with collision detection, Game of Life simulators, and chess-playing programs? These are just a few possibilities for (the performance-critical part of) educational applets that I came up with off the top of my head; I'm sure there are many more.
Um. I promise that Game of Life will not be a problem. I've coded a game of life simulation in freeking qbasic on a 286 which was faster than the screen refresh rate.
Fluid dynamics, rigid-body kinematics, and chess... I'm not sure if you are more confused by how slow 'not performance critical' is or if you have totally unrealistic expectations about what is needed to educate people. People not only learned but conducted serious science with software in these fields on the computers of a decade ago, even with interpreted languages far slower than what we'd use today... I wouldn't expect a modern interpreted language to be any slower...
When I played with jython before it was about half the speed of cpython (without psyco) on the same code, with a simmlar difference compared to raw java.
Moreover, I hope you realize that the limiting factor for any of this will be authoring the code. If a poor security model or editing model keeps us from tapping into the public at large we will not do well.
The JVM-based interpreter may still be the right thing to do, but people need to be aware that there are whole realms of creative educational possibilities that are far less feasible with that approach.
I don't understand your argument. Java classes + an available interpreter can not be slower than java classes alone.
How does a Java applet go about asking for more privileges? Is that something we can easily audit to avoid (for instance, by checking .class files to make sure they only use standard Java classes and methods that are in a whitelist, not to include reflection)?
It's not easy to audit if we're working with bytecode, ... if we're working with sourcecode thats another matter.
If the embedded-in-JVM interpreters let you interact with Java, then you will probably be able to write scripts that ask for more privileges; and that can't be fixed by outlawing reflection, since the interpreter has to use reflection. For this reason, compiled Java may actually be easier to secure than an interpreter.
You control what methods they can access by what you choose to expose, and you don't like the interpreter otherwise much with the VM. This is why jython is currently a non-starter (and in general, python has been difficult to lock down).
Can we write our own security manager, ensure that all calls to uploaded .class files are "wrapped" by our security manager, and implement our own restrictive security policy that way?
You have to have signed code to hook in as a security manager.. but lets assume we could:
This would do nothing to stop mistery meat code from displaying penises every second tuesday. The only way to handle that is to keep size down, readability up, and always work with source.
In any case, it's pointless to debate what loft applications we'd exclude with a particular implementation when none of these pieces of software currently exist.