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.'"
It's dangerous to use a programming language where common programmer mistakes allow "remote attackers to execute arbitrary code of their choice with the process's privileges".
Once they do that we'll only have to worry about stuff like SQL injection (which can result in execution of arbitrary code), which can be reduced/near eliminated by making people use prepared statements.
In some cases it'll still be necessary to use the unsafe languages, but nearly 100% of the programmers in the world obviously can't code safely in C or similarly vulnerable languages.
Even Eric Allman couldn't (see Sendmail for evidence).
I lost all my respect to Gosling after a clumsy attempt to add generics to Java.
The right way to add generics to Java is a radical modification of JVM (Java Virtual Machine), but Sun didn't want to it. So they made an attempt to add generics to Java language without touching JVM. The result of this attempt is a complex scheme of name mangling (just like C++), and some unnecessary overhead. And such implementation _still_ requires some JVM changes and is incompatible with old JVMs. So now we have an ugly generics in Java and Java 5.0 (rebranded J2SE 1.5) incompatible with previous versions.
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.
> 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?
And all that before even 2005.
while (!asleep()) sheep++
In this article he mentions that the idea for the JVM came from the days when he wrote an emulator and found that his emulator actually performed better than the compiled C code. With the most modern JVM's, tests show that their performance is very close to, and often exceeds that of compiled code.
But the problem is that this is done at the expense of the performance of the overall server. UN*X (and other OS's) go to great lengths to make different programs perform and share resources in the most efficient manner. Scheduling, memory management, IO optimization, all that wonderful stuff, that makes a bear like emacs start almost instantaneously even on an old P90.
As is evident from my sig, I've been spending quite a bit of time in the past year tinkering with virtualization (The Linux Vserver in particular). The amazing thing is that all the optimizations of Linux still apply even if you're running two dozen virtual servers on the same machine (the code for emacs is still shared across processes, even in different virtual servers). Except for, sadly, the JVM. This is why you see many VPS hosting providers forbid running Java and sell a separate "Java server" at a much higher price. And we're considering doing the same. In our experience, a typical VPS customer running Apache, sendmail and a few other things uses 200-400MB of virtual memory, much of which is shared, whereas a customer running Tomcat or, even worse, JBoss use 1-3GB of virtual memory, next to none of which is shared. (Note that virtual memory != physical memory, but that's a separate discussion.
Given that virtualization is becoming more and more popular these days (and even Solaris now has "zones", which are same thing as Linux Vserver or FreeBSD jails), I think the folks at Sun need to think about where the JVM fits into a virtual server.
The Java snail-oil salesmen try to convince you that your code will be bug free because certain classes of errors just can't happen. Again, what crap. They can happen. The only thing the JVM does is tell you precisely when they happen. Is this better than insideous bugs in C that change memory they shouldn't but don't crash as a result until later? Certainly. But the bugs still happen in Java. And they can be insideous in different ways.
;)
Ah, snail oil, it does wonders for the skin
Anyway, yes, it IS better to know WHAT is happening and WHEN it happens, than for it to blindly happen and cause problems later. This is because it bounds the code and its runtime behaviour. A NullPointerException or array out of bounds exception is not nearly as insidious as random memory getting clobbered. For one, it eliminates an entire class of possible bugs: buffer overflows. They simply wont happen. Knowing that there will be certain strict bounds on the runtime behaviour of the program is extremely important.
-Laxitive
The Java snail-oil salesmen try to convince you that your code will be bug free because certain classes of errors just can't happen. Again, what crap. They can happen. The only thing the JVM does is tell you precisely when they happen. Is this better than insideous bugs in C that change memory they shouldn't but don't crash as a result until later? Certainly. But the bugs still happen in Java. And they can be insideous in different ways.
Calm down, buddy. I never saw anything that said that Java will eliminate every bug known to man. I think everyone understands that "you can't go outside the bounds of an array" means "you can't go off the end of an array, corrupt memory, and do god-knows what to your application's state". You openly admit that this is better, yet you attack the "snake oil salesman" for bringing it up. It sounds like you have an axe to grind.
Hear, hear!
My coworker is currently recovering from 3 days' bugfixing session.
In C++, he called a virtual method off uninitialised pointer. The random piece of code that got run somehow managed not to crash the program immediately. Instead, it overran stack in random places. The program would crash in a corrupted STL list, in a completely unrelated spot. And it wasn't compatible with Valgrind.
Frankly, I'd take bugs in Java code instead of this anytime.
--
I refuse to use