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.'"

Comments

Good idea.

[TheLink]

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).

Gosling, Java? Hmmm.....

[Cyberax]

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.

Re:Gosling, Java? Hmmm.....

[Laxitive]

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

Re:Gosling, Java? Hmmm.....

[bay43270]

Moderators seem to be confusing Informative with Offtopic. What does Gosling talking about security have to do with Sun implementing generics? While sun was adding generics to Java, Gosling was building IDE components. Why blame him for Sun's reluctance to alter the JVM?

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.

The problems of code injection

[Anonymous Brave Guy]

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.

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...

No Generics until 2006-2007 ??

[fforw]

Generics are non-existent to me. They won't be anywhere around until 2006-2007.

what are you talking about? the 1.5 release is already at "beta 2". So we will have a release version in autumn. Netbeans will reach it's beta for the 4.0 release soon, so there will be a matching, open-source IDE, too.

And all that before even 2005.

JVM and virtual servers

[gtrubetskoy]

I like Java as a language, what I don't like is the JVM.

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:Java snake oil

[Anonymous Coward]

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.