Slashdot Mirror
Gosling on Computing
CowboyRobot writes "ACM Queue has Eric Allman (creator of Sendmail) interviewing James Gosling (creator of Java) and the conversation covers many aspects of computing today, including the state of security, comparisons of languages and OSs, and the future of virtual machines.
'At the lowest level, you have to know that the boundaries around the piece of software are completely known and contained. So, for example, in Java, you can't go outside the bounds of an array. Ever. Period. Turning off array subscripting is not an option.'"
Yep, that's a serious problem, and one that gets far less "press" than the sort of buffer over-run vulnerabilities you get in careless C or C++.
The one that always astounds me is that languages with an eval-type statement -- that is, ones which can parse and execute an arbitrary string at run-time -- don't get slated for their security problems way more often. We use Perl to write CGI scripts all the time, and its variable interpolation can be waaaaay more dangerous than any potential pointer nasties in C!
It's notable that Java does not have such a function. It does, however, have the usual problem with allowing arbitrary strings to be interpreted as statements through its SQL API, but given the nature of SQL I'm not sure how realistic it is to address that anyway...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
And what exactly should this implementation have been? Its easy to criticize, but I would like to know what you are proposing instead. Really.
Because from what I read, java generics look very usable. My only complaint is that they werent in JDK 1.4.
-- Home is where you eat your heart out.
> for example, in Java, you can't go outside the bounds of an array. Ever. Period.
As I recall, it used to be possible to turn off runtime bounds checking. I also think that most people would do this once the code is debugged. Did this feature get disabled recently?
I agree with your sentiment, to a limit.
I don't think the generics in Java are very ugly at all. The interface - i.e. the syntax itself - is reasonably clean. The implementation ends up being just a fallback to the safe-dynamic-casting functionality of the JVM, but you don't know that when you actually use the generics.
I think the major benefit of generics is that developers can structure their code easier. They can tell the compiler that something is a List of Strings, and not a List of Objects. The performance aspect of it is less important.
Also, you are not considering that there are low-level VM operations that can mollify, to a significant degree, the potential performance hits caused by dynamic casting.
If you read papers related to Self (a Sun research language, based on smalltalk, using prototype-based OO semantics), you'll notice that there was a lot of work done on doing fast dynamic type-inferencing. A lot of that work has been rolled back into Java.
So let's say you have a List of Strings in Java. And there's a location in the code which grabs the first element from a list, and that first element happens to be a String all the time, or most of the time (this occurrs very frequently even in OO code - even though the strict semantics might imply polymorphic behaviour, in practice, a lot of code ends up being monomorphic anyway). The Java VM will actually figure that out at runtime, and compile a special version of the code, which does one pointer check (to see if the object you're pulling out is a string), and if that pointer check succeeds, makes a call to a custom-compiled version of the method based on that type assumption. If that check fails, then it falls back to less efficient code. So that piece of code that ends up dealing with Strings in practice, ends up doing only a single pointer check, instead of the heavyweight operations needed for a blind dynamic cache.
Even when you have limited polymorphic behaviour (code that is polymorphic over a handful of tyes), the java VM optimizes it by using polymorphic inline caches (I think this was added in the 1.5.* VMs).
And the nice thing is, this happens on the dynamic properties of the code, not just the static properties. So if you have some code that, according to the syntax, deals with plain Objects, but in practice, deals with instances of Foo a vast majority of the time.. then most of the time, it WILL execute with the type-assumption, with the added cost of a pointer check.
So yes, it would be nice if the generics system had support at the bytecode level. But it's not as much of a hit on performance as one might think. The jitter and its low-level optimizations compensate for that quite a bit.
I'm pretty sure Sun developers were aware of this when they decided not to mess with the VM bytecode definition when adding generics support to the Java language.
-Laxitive