What do you mean by unsafe?
They have a notion of managed code and unmanaged code. Managed code is the kind you can make security and reliability statements about. [But with unmanaged code], you can't depend on anything anymore. Memory corruption is indistinguishable from correct behaviour. It's pretty difficult to analyse what a program is doing. C programs tend to fail in mysterious ways. It ends up having deep implications about how security mechanisms work. In C, you have to be able to lie about the identity of things, and in Java, you're absolutely forbidden from lying about the identity of things.
What would it take to get Microsoft to join the Java Community Process (JCP)?
I don't have a clue. Ask (Sun chief technology officer) Greg Papadopoulos.
Would you like to see things back like they were in that six-month honeymoon period?
I would love to see them collaborate with the rest of the community of the JCP.
You just released Sun's Java application server as open source software through the GlassFish project. Are there lessons you hope to learn there that might apply to the possibility of releasing Java Standard Edition as open source software?
Maybe. Just about everything we do about the way Java SE is run is very much like an open source project. The major dividing line is our licence has this testing requirement. When we've done surveys of places that use Java really heavily, the whole testing thing turns out to be a really big issue. There's all the folks in the open source community who on the one hand say, yes, we're going to test, we just don't want to agree to test. It's conceivable we could [release Java SE as open source software] some day. A lot depends on how comfortable the community gets.
There are a lot of negative examples that make us really nervous. If you look at people's experience with JavaScript. There are interoperability issues there between all the different flavours of JavaScript that are nightmarish for people doing Web page authoring. If you want to make it run on this browser, make it this way. If you want to make it run on that browser, do it that way. People in the Java world look at the JavaScript manuals and go, "that's a horrible thing."
But with Java, companies like BEA Systems would add special features that would be available only if you ran the software on their Java application servers. So Java code wasn't so portable after all.
Yes, that's a problem. But at least the way it's always been done is that at least these special features are special features. There's a facility in Java about package naming. When you use an API, you have to explicitly use what's a public standard API — java.something-or-other — or are you using one of the corporate proprietary ones — com.bea.something-or-other. It forces you as a developer to be explicitly aware. The developers really cared about portability. Every time they have to write com.bea, they feel the claws biting into their skins. One thing difficult in the JavaScript world is that you can't really tell that you're using a feature specific to this browser or that browser.
Also, the way things have tended to evolve is you get one application server vendor who will come up with some idea, there will be general acknowledgement that it was a good idea, and often that would turn into a
