I am reading now an article in which James Gosling claims that .NET has a huge security hole. The problem seems to be that .NET allows execution of both safe and unsafe managed code in the same process:

[...], Gosling is concerned about "unsafe" code, which is produced by traditional languages like C and C++. Unsafe code is old code that does not strictly follow the rules of type safety that .NET defines, and this sort of code requires additional permissions to execute. According to Sterling, "you as a developer take it upon yourself" to utilise unsafe code in your .NET applications.

But what James Gosling fails to mention is that the Java runtime also allows the same type of unsafe code execution in every process running safe Java code. No, I'm not smoking crack. The technology is well established in the Java world and it is called JNI. Here is a quote:

The JNI allows Java code that runs within a Java Virtual Machine (VM) to operate with applications and libraries written in other languages, such as C, C++, and assembly. In addition, the Invocation API allows you to embed the Java Virtual Machine into your native applications.

Programmers use the JNI to write native methods to handle those situations when an application cannot be written entirely in the Java programming language. For example, you may need to use native methods and the JNI in the following situations:

  • The standard Java class library may not support the platform-dependent features needed by your application.
  • You may already have a library or application written in another programming language and you wish to make it accessible to Java applications.
  • You may want to implement a small portion of time-critical code in a lower-level programming language, such as assembly, and then have your Java application call these functions.

Think of it a second - in fact, how does a small Java program interoperate with the underlying operating system? How does a "Hello world" Java program succeed to write anything to the console? After all, the Win32 API is not directly callable from Java, correct?

Therefore, by its own measure, Gosling only suceeded to demonstrate that Java also contains a huge security hole... :-)


P.S. And, please, don't tell me that JNI is not a security hole because writing JNI code is eventually harder and not done as often than using "unsafe" in C#... Face it - in Java, whenever you are writing to a file, communicating through a network interface or just handling GUI controls, there is always some unmanaged C++ code being executed in your process...