Gosling: What's Good for Google May Not Be Good for Java
Gosling: What's Good for Google May Not Be Good for Java
Q: What do you think of Google's use of Java or the subset of Java they use?
A: They are odd. It's not like the petulant kid who doesn't want to play with others. It's like they've got their head in the clouds and they're now saying, "Oh, you mean there are other people out there that we might want to play with?"
It's really hard to tell what their intentions are with Android. They put this thing out there, and you've got lots of people picking it up. The big attraction seems to be the zero on the price tag. But everybody I've talked to who is building an Android phone or whatever, they're all going in and they're just hacking on it. And so all these Android phones are going to be incompatible.
One of the reasons that we charge license fees is because we've got organizations of people that do compatibility testing and actual negotiating amongst the different handset makers so that things like GPS APIs look the same. And what's going on in the Android world is there's kind of no adult in charge. And all these handset manufacturers are doing whatever they damn well please. Which means that it's just going to be randomness. It could be let a thousand flowers bloom, but it also could be a dog's breakfast. And I guess having been around the track a few times, it feels like it's going to be more of a dog's breakfast.
Q: At this JavaOne what would you say is the biggest piece or the biggest new thing?
A: We're getting to this point where everything is tied together. So with my myopic blinders on ... what I've spent most of my time on in the last few months has been the store [Sun's Java Store]. For me that's a pretty big deal. It's going to be a very different kind of store than people have seen before. The JavaFX stuff is doing way better than I ever hoped. I think when we first started the JavaFX thing we were wringing our hands about all kinds of weird devices and people thought we were kidding.
So things like the [Java-powered] LG television, the fact that that's actually a product that is shipping and in stores. ... Admittedly, it's only shipping in Korea because it's a cable TV set-top box for the Korean market. But it's got the cable TV set-top box standards ... and fairly beefy Java engines. And that device runs JavaFX wonderfully. That's a TV that I believe the guts of it will be showing up all over the place. ...
I think that a year or two ago people thought we were kidding about this stuff. And we were not. There's definitely going to be more of this stuff. The fact that we're able to do this at price points that work for the CE manufacturers is pretty amazing. And you add all of that together and it turns into this unbelievably huge marketplace. And with the store. The hard bits of the store are its processes for managing deployment. The store that you see today manages deployment to desktops. But in not too long you'll see it managing deployment to cell phones and cable TV set-top boxes, and all kinds of strange things. The cell phone stuff, we're probably not going to directly do it. That's the kind of thing we'd probably do in conjunction with the cell phone carriers.
The Java Innovation Leaders
Q: Where's the innovation going on in Java today?
A: It's all over the place inside Sun. People are doing cool things in any direction you want to look. The enterprise guys-the GlassFish group-they're totally on a tear these days. The OpenDS guys are being really successful. The OpenJDK guys are getting some real traction. Stuff like the Jigsaw modularity stuff is getting a lot of excitement.
Q: Is that [Jigsaw] complementary to OSGi or different?
A: I think it's kind of both. OSGi is this thing that kind of came from a different universe that's being used for modularity. And it's kind of huge and a bit of overkill. So we needed something that was a lot lighter weight.
Q: So it would have the same functionality as OSGi?
A: Yeah. But with none of the other stuff that was irrelevant.
Q: Well, I know Eclipse is big on OSGi, and a bunch of the enterprise Java players are pushing it.
A: And we even use it. But it doesn't play well in the smaller spaces. I guess it's just too overwhelming. If you start worrying about modularity in some of these other interesting places and you're like, OSGi's just too much fat.
Q: Where are we with the issue of what language comes next? People say the JVM [Java Virtual Machine] supports all of these languages and one of them is going to supersede Java at some point.
A: Maybe. I actually would like to think so. It would be weird that, for what life span human civilization has, Java stays in place and nobody comes up with something that takes over. That would be just wrong. But the important thing isn't really Java the language, it's the JVM-the integration hub. And the fact that we can have all kinds of languages that get along together. You can be writing JRuby code interacting with Scala code with great performance, and it works really, really smoothly. The JVM is the piece that actually matters.
Q: So are you more accepting of dynamic languages these days?
A: Well, I don't know whether "accepting" is the right word. At the right times and in the right places, I think they're great. If it's not too much of a performance penalty. Because most of them have made design decisions that cause them to be way too slow for the things that I normally do.
The Importance of Parallelism
Q: What are you guys doing in software to attack the issue of parallelism?
A: In Java itself there have been concurrency libraries, and they are being pretty successful. In the enterprise stuff, the frameworks have been really good at doing parallelism for people. With the enterprise stuff, the frameworks have actually been pretty good at doing a little magic parallelism for people. They write a sequential model and by magic it ends up parallel. But for things like doing scientific calculation on massively multithreaded machines, that's a really hard problem. So like the Fortress guys, Guy Steele [a Sun fellow working on programming language research] and friends, they've got this functional language that they tear apart and map to a multiprocessing. And that's really interesting. They're the only folks that I know of that are really tackling large-scale multithreaded systems for the nonenterprise issues.
Q: So it's not a tools problem? Or could tools help?
A: Well, tools could help if only we knew. Dealing with multithreaded programming has been a huge source of Ph.D. theses for like 30 years. And there just hasn't been a killer solution. So there are all kinds of stuff that we could do with tools. If you look inside NetBeans, there are all kinds of stuff for monitoring threads, monitoring the data behind them, monitoring blocks. And for hundreds of threads most of those things act really great. Once you get into the tens of thousands of threads, life gets hard.
Q: Another question that comes up is, When are we going to see continuations in Java?
A: I had hopes for last year. And all the stuff that Neil Gafter [a Microsoft engineer focusing on the future of Java as a hobby] was doing just blew up for ridiculous reasons. Josh Bloch's [chief Java architect at Google] opposition was pretty bizarre. And it's hard to know when we can take another stab at that without getting the same type of high-temperature community reaction.
Q: You said you're impressed with the adoption of JavaFX. Do you feel like you guys have the RIA thing licked?
A: I don't think it's licked. We've got a lot more to do. But I'm really comfortable with the vector that we're on. We took this tack of integrating with the Adobe tools and sort of feeding that into the chain. That's been remarkably successful. The artist crowd really likes that. We've got this new tool that we've been showing. And JavaFX itself, one of our hopes for that since the early days was that we would be able to figure out how to map it to fairly widely different devices. We kind of had this back of the envelope proof that it was doable. And we pretty much got it figured out and nailed.
Q: Will Java be a platform for cloud computing?
A: People have been doing cloud computing kind of stuff in Java from day zero. Cloudlike stuff has become a part of everything we do. Kenai is our developer cloud. And the integration with NetBeans actually has REST APIs, and that's some pretty snazzy stuff. We really only started to do that stuff in the last six months. We've got this long "wouldn't it be cool?" list for NetBeans and Kenai and the combination of them.