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.'"
Good idea. (Score:5, Insightful)
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).
Re:Good idea. (Score:2, Insightful)
Not that I'd dream of barely-on-topic evangelism or anything...
Re:Gosling, Java? Hmmm..... (Score:2, Insightful)
JVM and virtual servers (Score:5, Insightful)
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.
Re:Gosling, Java? Hmmm..... (Score:2, Insightful)
Basicly, Java generic classes are common classes with some compile-time information. Compiler automaticaly inserts type casts when it's neccessary. But resulting byte-code is just the same code with casts from Object. So the only advantage is more typesafeness.
In C# 2.0 generic class are not real classes, they are templates (as in C++) for classes with erased type information. CLR (Common Language Runtime) instantiates parametrized class when it's neccessary (in JIT-time), during instantiation erased types are substituted with specified types, it's the same mechanism as used in C++. Advantages of this implementation: faster code (no redundant casts), smaller size, ability to parametrize templates with promitive types.
Re:Java snake oil (Score:3, Insightful)
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
Re:Java snake oil (Score:3, Insightful)
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.
Re:What about turning off bounds checking? (Score:2, Insightful)
The language is defined so that this is impossible. See here. [sun.com] If you were to disable bounds checking, then you would be violating the language spec, and therefore it would not be Java. It would be the same if you wrote a JVM that ran bytecode but never checked array accesses. This sort of stuff may be useful for debugging or academic purposes, but it's not something one can do without redefining what it means to be Java.
Re:Gosling, Java? Hmmm..... (Score:4, Insightful)
As far as how Sun implemented generics, the decision was purely political. Even Sun knows their solution is technically inferior. That doesn't make it wrong. They weighed the pros and cons and arrived at a different solution than you did, not because you know something they don't, but because they weighted the results differently.
Re:No Generics until 2006-2007 ?? (Score:3, Insightful)
JBC is completely stack oriented and very close to UCSD pCode. CLR is register oriented
The VMs have completely different abstraction levels as well. Java has no assemblies, they use the more generic approach via class loaders.
angel'o'sphere
Re:Java snake oil (Score:3, Insightful)
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.
--