What's Ahead for JavaBy Darryl K. Taft | Print
Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers
James Gosling language's 10th birthday features celebration, reflection.
The Java programming language turned 10 this year, and at the JavaOne conference in San Francisco last month, Sun Microsystems Inc. threw a big bash for its innovative technology, replete with a huge cake as well as a New Orleans-style ragtime band.
Meanwhile, James Gosling, the creator of Java as well as a Sun fellow and chief technology officer of the Santa Clara, Calif., company's Developer Products group, sat down with eWEEK Senior Editor Darryl K. Taft at the conference to discuss the ongoing adventure of Javawhere it's been and where it's going.
At some point a while back, you indicated that there might be a follow-up to Java from a language perspective. Is that still the case?
We've got a variety of projects working on a variety of things. We've been doing a bunch of work to make the Java VM [virtual machine] a lot friendlier to some of the stranger dynamic languages. A lot of that will show up in the next version. We've done a lot of work with different languages as targets. We have one rather strange language project going on in Sun Labs. It's centered around the combination of numerical computing and extreme multithreading.
That one's been going on a while, though, hasn't it?
Well, yeah. That one's a really hard science project. It's got a ways to go before it produces anything real. There are a lot of other hard problems in building something that scales to hundreds of thousands of threads and does the kind of concurrency that people need in numeric computing. It's been an area of research for, literally, decades.
Java's pretty far along on the scale in terms of its effectiveness at doing multithreading. And for the kinds of applications that most people write, it works extremely well. But when you get to numerical applications where there are a lot of cross-thread data dependencies, life gets very difficult. And it's generally an unsolved problem.
Is anybody close to solving it, other than what you guys are doing?
I don't know about close. There are a lot of people trying a lot of different things. We're sort of going down this road because it's very clear that serious multithreading with a large number of chords is the future. And the stuff that we do now works really well for the enterprise-class apps. And we know this will scale to a few thousand processors.
You can't buy machines that big yet, but you will be able to at some point. But that depends on the interesting properties of enterprise apps that are different from scientific apps. So it's a really interesting research topic.
I saw [Sun Vice President] Graham Hamilton's talk ... and he listed some tentative things that might go into "Dolphin" [the code name for Java SE 7]. Which of those do you think must go in?
Boy, I don't know that I have anything that "must" go in.
What would you like in?
Oh, there are all kinds of things I'd like in. Small-object support, that's been on my list for a long time.
Hamilton mentioned things such as direct XML support, something about cross-package references and method references.
Well, we do have ways to do cross-package references in different languages at different things. They all have their problems.
Method pointers? That one's been a long discussion for years. I'd actually be surprised if we ended up doing anything like that, if only because using classes properly does method pointers pretty well. And the things that people do with proxy objects now deal with method pointer situations pretty well.
I guess I wouldn't put those on my list. My list would contain things more along the lines of yet-more-interesting stuff in Swing. There's a lot of stuff we could do in rendering still, even though our 2-D rendering has gotten pretty good.
Direct language support for XML has been a debate for some time. All these things, at an abstract level, sound like the thing to do. When it comes down to the details, one of the problems ends up being that, using Java today, you actually get pretty good access to XML. And what it would end up being is sort of syntactic sugar that makes certain constructions simpler, but can you come up with something that actually makes people's life better by enough that it's worth adding that baggage?
I was at OOPSLA [the Object-Oriented Programming, Systems, Languages and Applications conference] in October, and when asked whether C# was an homage to, or owed its heritage to, Java, Anders Hejlsberg [the Microsoft Corp. architect who designed C#] said: "I've seen further when standing on the shoulders of giants." And I'm curious to know what shoulders were you standing on when you came up with Java?
Oh, hundreds of them. Niklaus Wirth with Pascal, [Ole-Johan] Dahl and [Kristen] Nygaard with Simula, Alan Kay and company with Smalltalk, Ken Thompson and Dennis Ritchie and the whole crowd in the C world, all the folks at DEC [Digital Equipment Corp.] that worked on Modula. There are a lot of ideas from LISP in there, too. It's from all over the place.
Why do you think Sun's development tools never commanded a greater share of the market?
Well, we're on our track to getting there. You look at the adoption curves, and we're doing pretty well.
Sun's earlier history with developer tools is filled with a lot of stupid stuff. One of the things that was kind of crippling for us early on is that we really wanted to depend as much as possible on things the community was doing. So there were a few companies like Symantec [Corp.] and Borland [Software Corp.] that were doing interesting tools, and if they were doing a good job, we were happy.
But the dynamics of the tool market are that, ever since Microsoft introduced Visual Studio and dropped the price to essentially zero, it's pretty much impossible for any company to sell tools for any price that comes close to covering their costs. And that turned the tools world into one where the only people who could produce tools had sort of an indirect business model. Microsoft's business model around tools is all about developer lock-in to their platform.
I know this has been bandied about, but do you think there will ever be any cooperation between Eclipse and NetBeans at some level?
At some level, maybe. It's really hard to tell. The architectures at the core of both of them are different enough that it's really, really hard to line things up. We're certainly achieving a fair amount of interoperability. We've got pretty good import filters; we both handle similar kinds of data objects, like Ant scripts and such. We've put a [lot] more effort into the specialized development areas, like J2EE [Java 2 Platform, Enterprise Edition] and J2ME [Java 2 Platform, Micro Edition], and a lot of interesting stuff in the cell phone world.
Will we see a fully conformant open-source implementation of Java SE from Sun?
Well, there are lots of different answers. One is "beats the hell out of me." You never know what the future will bring.
If you look at the way that we interact with the communitythe way that we have all of our sources out therewe have a lot of people from the community that contribute the way any open-source projects do.
Really, the major thing that's an obstacle to truly being open source is the nits in our license about testing. And having our license require testing disqualifies us from the religious blessing of the open-source community.
And when we talk to Java developers and big sites that use Java, interoperability and reliability of these systems is really, really important to them.
Right. But do you think that there's a possibility someone else could do it?
Oh, there's certainly a possibility.
Well, what kind of disadvantage would that put Sun in?
I don't think it would make a whole lot of difference. When you look at the J2ME world, there are dozens and dozens of compatible, interoperable JVMs [Java virtual machines] out there. But of course they all do the testing. We have a test suite, and they all run that.
And, like the Harmony folks at Apache [The Apache Software Foundation], they say they're going to run through the tests. If they do that, that's OK.
So the nice thing about AJAX is it encapsulates the nightmare and it makes that easy to use.
Do you think we've achieved the overall promise of software reuse that was expected when object-oriented programming was invented?
You look at the number of components that people are reusing, and you look at all the different JSRs [Java Specification Requests], and most of them are producing libraries of components. And if you look at many commercial shops out there, their jobs are producing components.
Whether they're user-interface components or enterprise bean components or components from private APIs, the Java world is just filled with components. And it's really been pretty spectacular to see that.
This article was originally published on eWEEK.com.