The Java bytecode verifier ensures that no object references are forged,
so that no area of computer memory can be accessed unless allocated, by
the Java environment, as an object. Java code is not assembly language
that executes directly on the computer; it is a set of interpreted
bytecodes, in which there are no pointers, only "object references"
which cannot be forged by any set of bytecodes which passes the
verifier, and which can be created only by the Java equivalent of an OS,
which is prewritten for your computer and which is not loaded over the
net. Java *applications* *may* be allowed to access pre-written (not
net-loaded) native methods for executing commands such as "rm -rf
$HOME", but Java *applets*, which are loaded automatically, can't do
that.
Java is a virtual world. The bytecode verifier ensures that the Java
bytecodes stay within the virtual world. There are no halting problems
here. The basic Java model is, mathematically speaking, completely
secure. In point of fact, if Java wasn't secure, *then* I could write a
Turing machine capable of solving the halting problem. There may be
flaws in the implementation, but I think that your challenges here are
based on a lack of knowledge.
If you have more questions about Java, I suggest you consult a FAQ or
Sun's Web site.
> Oops. You just rejected 'JavaDoom' -- three million people disabled their
> verifiers immediately.
"While you've been making better idiot-proof mechanisms, God is out
there making better idiots."
--
sentience@pobox.com Eliezer S. Yudkowsky
http://tezcat.com/~eliezer/singularity.html
http://tezcat.com/~eliezer/algernon.html
Disclaimer: Unless otherwise specified, I'm not telling you
everything I think I know.