Of course nothing is 100% secure - it's all relative - how much hard you make it, how big of a deterrent you put up. You are missing the difference that Application bugs are very common compared to JVM bugs. Tell me how many browser bugs have been there and how many JVM bugs that allow arbitrary code execution. The JVM infrastructure provides the mechanism to prevent arbitrary code execution and does it right most of the times - Native code is way too unsafe for Application development. Another Safari bug and it will be exploited in most dangerous ways - another Java application bug and the JVM will restrict the consequences to at the most a DoS. You are continually denying that a VM based sandbox provides much stricter mechanism and much better detterrent against security flaws - that is commonly proven knowledge. You are arguing that JVM has bugs, native code has bugs so it's no different - which is naive. You do not seem to understand the difference between native code executing on CPU and bytecode executing inside a VM. You also seem to completely ignore the security mechanism Java provides - All Java code is subjected to a bytecode verification process and conformance to security model is enforced. Native machine code is unverifiable the application will happily try to execute garbage and crash. Through Java's SecurityManager interface, user agents can selectively impose fine-grained controls on downloaded code, specifying which files it can read or write, which hosts it can connect to, and so on. Such control is impossible when execuing native code. You can read and check the Java VM specification, the source of the SecurityManager, and so on, and satisfy yourself that they don't leave any holes. In short a quality JVM implementation will provide a much better resistance against security problems than standard UNIX or Windows security can ever do. There can hardly be any debate about it if you make an attempt to understand.