James Gosling, the creator of Java as well as Sun Microsystems vice president and fellow, spoke with eWEEK in an exclusive interview at the recent JavaOne conference in San Francisco. In this segment of a wide-ranging discussion I had with Gosling, he shared his view of Sun's new Java Store, which represents a distribution channel for millions of Java developers. Gosling said the Java Store could easily eclipse Apple's App Store marketplace for iPhone applications, making it look like a "rounding error." An excerpt of the full Q&A follows. eWEEK: At this JavaOne what would you say is the biggest piece or the biggest new thing?
Gosling: 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 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.
eWEEK: You say it's a large market; what kind of expectation do you have for what this market opportunity represents?
Gosling: Well, the current desktop market is somewhere around 800 million desktops. I don't know how many TVs there are on the planet, but there are a lot. How many cell phones? There are a lot. The nice thing about Java code is we can do managed deployments in a way that you just can't do with other things. And the way that the store is built right now, you can actually give it Windows install files and such. But those don't install anyplace besides Windows. And they have all kinds of security issues and the rest of it. So it's an open question as to whether or not we'll actually go there. Mechanically the store can support it.
But the size of the market when you glue together all of these domains where you can deploy Java applications, it's a couple of billion at least.
eWEEK: So it makes the iPhone look like...?
Gosling: A rounding error. Yeah, the iPhone is a rounding error compared to what this could be.
eWEEK: Initially, what types of apps are likely to be first to be adopted?
Gosling: The first up will definitely be little goofy games. And probably ... the greatest volume forever and probably the most money forever will be in games. The sad reality of the computer industry these days is it's pretty much dominated by the game industry. You look at Intel chip design these days and the high-volume, high-performance stuff is totally driven by game boxes. We only have high-performance floating point because people need to simulate fists going through walls.
eWEEK: But with the guts of the store, you guys have had this capability forever, what prompted turning it into the store at this point?
Gosling: We've always been doing stuff for other people. So I said I don't know how many store deployments we've been a part of over the years, and it was like why not. And with some of the JavaFX stuff and the way some of the consumer technology was growing up, it was just unavoidable. It was just too much the right thing to do.
eWEEK: I see. Sounds like it could have been a Sun turnaround story on its own. Gosling: It would have been lovely to have another year or so.
eWEEK: Back to the store, you mentioned partnerships with carriers and cell phone companies, what broader ecosystem do you think it would foster?
Gosling: The various carriers like having their own developer ecosystems. But the fact that they are independent ecosystems can often be difficult. And so we're hoping to be able to offer to carriers a picture where what they get is something that looks like their ecosystem. But from the developer's point of view the ecosystems actually sit together. So we don't want to go around the back of the carriers or on the side or over [the] top, we want to work with them. I would imagine that the kind of ways in which they want to work with us are variable. We'll probably wind up with a couple or three different broad styles of working with them. We've already had some preliminary discussions with carriers that have been pretty positive. Part of the beta that we announced was partly to have a place where we can have conversations with these folks.
eWEEK: It's a beta, but how far along is it? How much work is left to do?
Gosling: It's kind of up to the developer community in some sense. The physical infrastructure that's built, it'll scale to huge. We did a first prototype about a year ago that had all the PayPal integration and stuff. And we did a second prototype. Then we did the real engineered, "this is not a prototype" version. So the infrastructure we've got is absolutely production.
The question is not so much what is the structure of the engine, but what are the policies that surround it that work the best for the developer community. At various times we've done a half-dozen different cash register models. And one of the things at the top of my to-do list is to start some discussions on the store forums about what actually works for folks. Because we did some that were kind of different but that I think would work better.
eWEEK: Can you explain that? Why would they work better and what is different?
Gosling: So the ones that I personally like when I put on my "I'm a developer" hat are a little different than what you might see everywhere else. The one we built that I liked the most was one where the software is always free to download, but the software and the right to use are independent things. And what you buy at the store is not the software, you buy a right to use. So you get a little license token. And we built a license management server. So when you say buy that, what you get is a license token. So one of the disadvantages of this technique is that you have to modify your application. And we have an API where the app can say, "OK, has the person actually purchased this?" And then the app can respond in different ways. One of the things that the API gives you besides the purchase status of a right is how long it's been since you were installed. So you could do things like, say, if it's within 30 days of being installed I'll behave like I was paid for. After 30 days then maybe just shut down. Or when a person hasn't purchased the right to use you can respond in different ways. You can just not work and shut down, and say it can't run until you pay for this. Or you could start deleting features or graying out menu entries. Like you could gray out one menu entry a day for weeks. You could start watermarking all the images that they edit. You could do all kinds of things. Or you could just do the "nagware" thing like pop up an annoying dialog box that says, "Hi, wouldn't you sleep better at night if you actually paid for this thing?" So the license manager one is the one that's far and away the most flexible. But it does require that the developer do something.
One of the nice things about it is you can imagine having multiple rights for something. So you can do things like the way "RuneScape" works. You get "RuneScape" and the first two levels are free, but if you want to get into level four you've got to go to the store to buy this. But, oh, you want to get into level five, it'll cost you that. Or on another app like a photo manipulation thing you can say, oh, you want the red eye removal, then that will cost you more. I can imagine people doing all kind of things different ways, where the basic app is free. And we can support that with the license manager. But it does require work.
There are other models where you don't get the app at all unless you pay, which is basically the iTunes store. And then developers have to have two versions of every app, the demo version and then a regular one. And having to retain synchronized versions gets very messy. You can't do layered licensing.
eWEEK: But the work that would be required of the developer, would there be a way that you could simplify it with a template or something?
Gosling: Yeah, we have a standard API snippet. In fact, in the prototype there was a drop-down API list where you said, I want to use this purchase model. And if you picked the licensing one, then on the developer's page one of the things that showed up was a five-line piece of boilerplate and all you had to do was literally cut and paste into your code. And that would check for the license, etc. The coding part of it is pretty simple. It's thinking about what your policy is going to be that's more difficult.
eWEEK: So this is a lot more than I initially thought it would be.
Gosling: It's a really different store and the market's got extra digits.