Do you plan to put all native methods in there (including
java.io,java.net) ? Or only this requiring direct vm support
(java.lang.reflect, Class)?
gnu.vm.VirtualMachine has to check privilages. It's functions need to be
public to be accessed from other packages and thus can be misused by
malicious code. Security checking would have to be done in public
methods of gnu.vm.VirtualMachine and if passed, call package native
methods (defined abstract in actual gnu.vm.VM..) to do real job.
But then VM would have to check if no code from outside sources is
loaded into gnu.vm package - in other case it can be used as trampoline
to call native funs using package scope methods.
For me, subclassing gnu.vm.VM is not a safe idea (unless you want to
force vm implementors to include security checking in native code). Just
defining private native methods in it would do...but what is the reason
for having such class then ?
What is your plan to solve security problem ?
Artur
