Developer Product Briefs
The JCP Wants You
JavaOne attendees heard many references to the JCP, including appeals from leading execs to sign on and participate. FTPOnline met with Onno Kluyt to get his take on all the attention.
The JCP Wants You
The Java Community Process figured prominently at JavaOne. Find out what Onno Kluyt had to say about its membership and milestones
by FTPOnline Editors
May 31, 2006
Despite all the excitement around the revelation that Sun Microsystems will now be intent on "how to make Java open source"—which was revealed at JavaOne's opening keynote in San Francisco from Sun Microsystems' President and CEO Jonathan Schwartz and Rich Green, executive vice president, Sun software—perhaps even more noteworthy were the repeated appeals to individual developers to enlist with the Java Community Process (JCP). Not only did the two Sun executives with brand new job titles and responsibilities urge the community to join up, but Marc Fleury, founder and CEO, JBoss; Ed Zander, chairman of the board and CEO, Motorola; and Mark Shuttleworth, founder and CEO, Canonical each had their turn on stage to chime in with the same petition for developers to get on board with the standards body.
These emphatic calls to action invited the Java developer community to get involved in the evolution of the Java language and platform to stay abreast of the standards' progress and provide feedback on the evolution of JSR technologies and APIs. With so much play given to the JCP during the extremely well-attended opening general session, FTPOnline editors took the opportunity to spend a few minutes at the conference with Onno Kluyt, chair of the JCP, to get his perspective on the big push for JCP membership registration from individual developers. Kluyt discussed the impact of these announcements, and what it means for the JCP and all of its membership, in addition to other significant news and milestones from the standards organization.
FTPOnline: The JCP received quite a bit of attention at the JavaOne opening keynote, particularly with the oft-repeated appeals by the various speakers urging attendees, and the developer community at large, to join the JCP as individual members. What did you think about all the attention?
Onno Kluyt: I'm very proud of my CEO. He's becoming a powerful marketing force for my community. I think if you look at the current membership, I think we're at 1,052 [members] this week. There are new membership applications every week, so the number keeps growing. Already around 60 percent of our members are individual members, which I think is quite good. I believe we're the only standards organization where individuals, corporations, and universities can collaborate on equal footing. For us that is working really well.
In the end the way you like to see a Java standard is [to be] a Java standard for developers by developers so that the technical quality and completeness and the delightfulness of the standard is very important. Individual developers play a role because they're very much the ones that work with this technology. They have to make it work; they have to make sense of it. The programs that they build get a lot of direct feedback from the working field, if you will, into the technology of the standard. At the same time of course there has to be a balance because the participation from companies like IBM, Nokia, and so on give you the market adoption and industry credibility of the technology.
The trick is to balance both and not have one point of view become overbearing upon the other. So far that's working well. Many of the spec leads, Sun spec leads, Nokia spec leads, Oracle spec leads value the individual developers, especially in the IDE space. Individuals on many of the expert groups [with] Bill Shannon's umbrella JSR for Java EE [JSR 244] are well regarded by their corporate peers.
Now having said that I don't necessarily expect all five million developers to sign up for the JCP, but I think they should be aware of what we're doing, and come visit the Web site, keep an eye on the draft specifications, and so on and give feedback on them. The reason I say that is that as a community the Java Community Process, the JCP, does something specific, and we're the ones that make the standards. And that is a different role or activity than, for example, a community like Java.net or Apache, which is sort of much more hands on, where people can start their own favorite project, try things out and if it doesn't work go try something else. Communities like Java.net and, for example, alphaWorks from IBM are very much the proving grounds for new ideas; whereas, oftentimes from those things certain common concepts emerge and then they become sort of the starting points for JSRs.
I think you could make the argument that there are two kinds of developers: those who are interested and excited by the plumbing, what the plumbing should look like, how thick the pipes should be, and where the taps should be; and then there are developers that just want to make sure the plumbing is there and that it works well and that they can get their glass of water. I think it's useful for all developers to be aware of what we do, but I wouldn't be insulted if not every single developer doesn't want to be proactively involved.
To a certain extent, every developer, whether they really know it or not, is probably one way or another influencing what happens at the JCP because you can make another metaphor—that the JCP is the parliament of the Java universe. For example, in the history of the ancient Greeks in the Athens city state each citizen was automatically a member of parliament. That of course doesn't work very well at the scale of humanity where we are at now; it would be really hard to manage. [Similarly], the one role the developers play, whether they know it or not, is they are influencing who makes the decisions and what decisions are being made [through] the technologies that they endorse, the opinions they express in their blogs, or the things that voting JCP members do in the elections of the executive committee, and so on.
FTPOnline: Now that JSR 244 [Java Platform, Enterprise Edition 5] Java EE 5 is done, which has been a big focus since the announcement and here at the conference, which other JSR [or JSRs] is the next one that is significant in terms of being near completion, or one that you consider particularly significant or most captures your interest or excitement?
Kluyt: The next two groups of technologies that are becoming final, in the ME space there is JSR 248, the Mobile Service Architecture (MSA), that is a coordinating JSR that specifically for the cell phone industry is the next generation of Java, how it should be when you should have this [any specifically relevant] JSR, that JSR, and in your phone when you combine the two JSRs, this is how they should behave.
Then later this year there is the Java SE 6, "Mustang," going final, so that's another group of 15, 16 JSRs altogether. I think it will have [a big] impact on developers; they can already play with early access implementations and tell us how well they are going. There's significant performance improvements, much more richness, new interface stuff, and so on.
FTPOnline: There's no doubt a lot of excitement in the mobility space, particularly with specific devices and the new Nokia platforms.
Kluyt: Well, as you saw in the opening keynote, the mention of James [Gosling]'s demo at his keynote [held on the last day of the JavaOne conference], JSR 209 will bring in much of Swing and Java to cell phones, and indeed if you look at what they can now do, there is really a nice looking user interface, a smooth interface, on these devices that is quite amazing. And I think there are a couple of things coming together. The devices themselves each year are becoming more powerful in their capability to run more complex technology. Then you see JSRs about bringing the technology out to the platform. Together they help lower the bar for the developer.
You also see in the tools area in Sun NetBeans, the mobility kits, and I think Nokia is doing similar things in the Eclipse community, where now you start to be able as a developer to design your applications for cell phones and other such devices in a very similar way as [they've done] for a couple of years becoming familiar with building their enterprise applications with very rich toolsets, where they can compose new interfaces, lay out their application, and the tool can take care of a lot of the plumbing and the coding and so on.
Some of what you can do now is quite stunning. With the NetBeans mobility kit, for example, you can debug your application so from there it runs from a server to the cell phone and in the application at a break point, whether that break point happens on the server or whether it happens on the cell phone, there's the ability then for the developer to write correct applications for the device.
FTPOnline: In a briefing here at JavaOne with the Nokia folks, including Jon Bostrom, Nokia's chief Java architect, there was considerable discussion of JSR 232 [Mobile Operational Management], which is very intriguing technology in that it essentially brings middleware to mobile devices.
Kluyt: The provisioning of service applications to devices like cell phones and PDAs by nature of the technology and the infrastructure need to be different than how people get software on their PCs. Regardless of how the cell phone technology progresses, we'll continue to find ourselves with devices that can do much more with the phone than what physically fits on it. That's where JSR 232 really helps with the provisioning where you have the rights to a whole bunch of applications, tools, and games, and other kinds of stuff you can use on the phone but you don't necessarily have to have them on the phone all the time, where as needed, and as you want it, things are deployed through your phone, and then if you need to do something else and need to have space for that it can manage what is physically present on your phone through cyberspace.
FTPOnline: Lastly, we understand the JCP is nearing the 300 [JSRs] milestone. What is the significance to you of reaching that milestone? What does it mean beyond, at least from an outsider's perspective, being just a number?
Kluyt: It shows that as an industry that we're still alive and well. Java is still as relevant as it was before, and it is still as cool as it was before, and there's still as much diverse interest in it and strategic need for it as before from Sun and all the other companies. Over the seven years or so that the JCP has existed, we keep getting between 35 and 40 JSRs each year; it's almost like clockwork. And that continues. What that shows is that the platform vendors like Sun and HP and others continue to see the need to build for the platform as well as the individual developers. They keep finding out new things that oftentimes become a project for standardization, and the cool thing about it is you can't really predict from what those cool things [are] for the next year just as they appear. Things appear at the same rate. I think that's pretty cool.
At the same time the supportive part of efforts like the JCP is that you continue to see the developers creating new frameworks, new programming models, the description languages, and so on, and you can see it happen right from the start more and more. The Java platform, as in the virtual machine, the cross libraries versus the programming language, and so on you will see much more apparent going on for years, but not that visible to the general population. But what you'll still see much more visibly over the coming years is that many developers or IT managers aren't necessarily going to care whether it was all written in the Java program language as long as it runs on that platform; as long it compiles to bytecode everybody's happy. In the mathematical world, a lot of the Fortran programming and the Ada programming all compiles to bytecode; all those compilers compile back to the bytecode that runs on the Java Virtual Machine.
And then you have a bunch of new things like Groovy JRuby, Jython, and so on. And I think that makes sense because Java really provides at an enterprise level, complex things, but at the same time, sometimes there is a very valid need for just quick, dynamic stuff that evolves the scripting languages. What I think we're working on more and more is giving those scripting languages the same richness that the Java programmer has with access to all the APIs, Java objects, and so on so it integrates well, and I think that's something that the community is looking at much more practically.