Gosling on Computing 74
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.'"
The problems of code injection (Score:5, Interesting)
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...
Re:Gosling, Java? Hmmm..... (Score:2, Interesting)
Because from what I read, java generics look very usable. My only complaint is that they werent in JDK 1.4.
What about turning off bounds checking? (Score:3, Interesting)
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?
Re:Gosling, Java? Hmmm..... (Score:5, Interesting)
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
Re:The problems of code injection (Score:3, Interesting)
The first is a "not thinking straight" problem and requires stupidity/ignorance which is common. The second is a "typo class" problem and only requires imperfection which is nearly ubiquitous -even smart and knowlegeable people make such mistakes (some even do it regularly).
As for other languages: I crashed a forth webserver the first time I tried
As the author of the webserver said when I emailed him: "the line between CODE and DATA is blurred by Lisp and obliterated by Forth.
That's dangerous if you don't know what you're doing...
At least with perl if you turn on tainting and "use strict" a lot of exploits become very difficult. Whereas with C you need to keep remembering to do the right thing. Global "make things safer" switches are good for most people.
If you ALWAYS use SQL prepared statements in Java, in one sweep you make SQL injection attacks a lot harder. After that you need to make sure that LIKE queries don't have unwanted wildcards, and that stuff like a=b-parameter is either a=b - parameter or a=b-(parameter) so that if parameter is a negative number it doesn't create an SQL comment.
Then either you turn off multibyte/multilingual support or hope that the database implements it correctly. There was a bug in a database where a particular invalid multibyte word caused the following character to be "eaten" up. Imagine if the following character was a ' or \. The DB developer who mentioned the prob didn't even realize the severity of that prob and I had to give examples. Eye-opener...