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.
If you're into language/OS design, then go RTFA. It gives a good view of the why/how to do things, and some historic perspective.
Linus Torvalds (creator of Linux) interviews Bill Gates ("creator" of Microsoft) about God (creator of Universe) Come on, give us geeks some credit for knowing who some of the big-guys are.
I don't want to fit in, I just don't want to stand 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?
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 Army reading list
open4free ©
The snail-oil marketing around Java has always annoyed me. "Java has no pointers, so no more pointer errors!" What crap. Kindly explain NullPointerException then. Sure, you can't do some of the free-wheeling things you can do in C with pointers, but Java does have pointers (hidden by a coating syntactic sugar).
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.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
Expert Java EE Consulting
exim pros: syntax for configuration doesn't utterly suck
exim cons: doesn't scale to large mail volumes (may not matter if you're a small site)
Recommendation: avoid sendmail. avoid exim. use postfix.
This is a boneheaded remark. You could say the same thing about Sendmail. Perhaps he's just trolling?
Wow, is Gosling really that clueless?
"sweet dreams are made of this..."
(If the reason is old Perl code or uneducated programmers, I do think that your complaint is a bit overblown...)
Karma: Excellent (My Karma? I wish...:-( )