Yeah thats true. In theory it would be possible to write to some memory location, and maybe you'd overwrite a java object. But how? JNI does not expose direct pointers to its objects. All you get is a jobject reference, which is similar in concept to a Win32 HANDLE. Only the JVM knows how to obtain the actual memory address of the data. But with managed C++, you have a direct pointer to.NET objects. So it is very easy to misuse the pointer, and attempt to use it as one type when infact it might be something entirely different, because C++ has no runtime type checking.
Gosling is simply suggesting that Microsoft's decision to support C++ means that they had to design the platform to make it possible for the CLR to execute code without verifying it. Whereas the JVM will ALWAYS verify that any JAVA method invokation is valid for any particular object.
I think its a simple issue of runtime type safety. Thats all. I'd love to learn more about the internal design of the CLR... is that kind of information available?
I think alot of you dont understand what Gosling was trying to say. This whole argument of "you can do the same thing in JNI" is just not true.
In JNI, to access Java objects, you must do so via JNI function calls. That way, to invoke a Java method, the JVM can verify that the jobject handle you supply is of the correct class and that the method does exist and is valid for that object, therefore maintaining the integrity of all JAVA objects.
Gosling's point is that in C++, you are able to manipulate.NET objects using C++ classes, and therefore you can easily corrupt them. You can do arbitrary casting in C++. The example he used was an Image. In C++, you could theoretically cast an Image pointer to a String pointer, and start invoking String methods on it and the.NET runtime will attempt to run them, corrupting the data.
Basically it comes down to this: even the JNI maintains type safety. But in.NET, it is possible to get around it. So his arugment is that Java is therefore a much more secure platform. Ofcourse you could call malicious native code from Java, but any data in Java objects will be safe.
That being said, I still think.NET is a wonderful platform. It just has its flaws. As does Java. BUt Gosling is just pointing out that their decision to support legacy C++ may have affected the overall design of the platform to allow unsafe operations, just because it is allowed in C++.
Slashdot Mirror
Id also love to always remember to close my italic HTML tages properly... darn it =)
Gosling is simply suggesting that Microsoft's decision to support C++ means that they had to design the platform to make it possible for the CLR to execute code without verifying it. Whereas the JVM will ALWAYS verify that any JAVA method invokation is valid for any particular object.
I think its a simple issue of runtime type safety. Thats all. I'd love to learn more about the internal design of the CLR... is that kind of information available?
In JNI, to access Java objects, you must do so via JNI function calls. That way, to invoke a Java method, the JVM can verify that the jobject handle you supply is of the correct class and that the method does exist and is valid for that object, therefore maintaining the integrity of all JAVA objects.
Gosling's point is that in C++, you are able to manipulate .NET objects using C++ classes, and therefore you can easily corrupt them. You can do arbitrary casting in C++. The example he used was an Image. In C++, you could theoretically cast an Image pointer to a String pointer, and start invoking String methods on it and the .NET runtime will attempt to run them, corrupting the data.
Basically it comes down to this: even the JNI maintains type safety. But in .NET, it is possible to get around it. So his arugment is that Java is therefore a much more secure platform. Ofcourse you could call malicious native code from Java, but any data in Java objects will be safe.
That being said, I still think .NET is a wonderful platform. It just has its flaws. As does Java. BUt Gosling is just pointing out that their decision to support legacy C++ may have affected the overall design of the platform to allow unsafe operations, just because it is allowed in C++.