|By Janice J. Heiss|
Bio: Patrick Curran, Chair of the Java Community Process (JCP) and director of the JCP's Program Management Office, has worked for Sun Microsystems and then Oracle since 1992. Before chairing the JCP he managed the team that was responsible for developing conformance test suites (Technology Compatibility Kits, or TCKs) for Java SE and Java ME. During this period, as an active member of the W3C's Quality Assurance Working group, he contributed to several documents on the theory and practice of conformance testing.
We caught up with him to get his perspective on recent developments at the JCP, ongoing concerns and controversies, its history -- and its future.
Q: Why don’t we begin with an overview of what’s happening at the JCP?
A: The short answer is that after a lengthy period of relative inactivity things are moving again. In December of 2010, Oracle filed JSRs for the next two releases of the Java SE platform (Java SE 7 and Java SE 8.) The Java EE team will soon follow with JSRs for Java EE 7 and we can also expect to see new JSRs for the Java ME platform before too long. In addition, I'll soon be filing two JSRs to modify the way the organization functions (we call these JCP.next.) So we're going to be very busy for the next year or two.
Q: What should Java developers know about what’s happening with JDK 7?
A: I'm guessing that you're asking about the next release of Java SE but I'm going to get pedantic on you. We need to distinguish between Java SE 7 -- the next formal version of the platform as specified through the JCP -- and JDK 7, which is Oracle's implementation of that platform. As I've said, the JSR for Java SE 7 (and subsidiary JSRs for components that will be implemented in the platform) were filed in December. However, because work on the implementation had been going on for a year or more in the OpenJDK project, it's expected that these JSRs will be completed -- and Oracle's implementation in the form of JDK 7 will be released -- relatively quickly. The Platform JSR states that the Final Release is planned for July 2011. In the meantime, work on Java SE 8 will begin soon.
"The Java SE 8 Platform JSR will be particularly interesting since it will define a module system for Java. If this is successful it could lead to significant changes in the way that all three Java platforms are packaged and distributed -- with a common 'kernel' for Java SE and Java ME, and profiles for various types of applications in all three platforms.”
Chair of the JCP
Q: What about Java EE? What's happening there?
A: It's alive and well. Java EE 6 was finished in December 2009. It introduced the first profile for Java EE -- the Web Profile -- which provides a lighter-weight but full-featured stack for Web application development. The platform was also modified to make it more extensible (it's now easier to plug in different development frameworks, for example) and, of course, the various APIs were updated and in many cases simplified. Adoption has been good, and the Java EE team is already focusing on the next release. They expect to file the JSR for Java EE 7 within the next few weeks.
Q: Tell us about the Java ME JSRs.
A: That's a little further out, but you can expect to see new JSRs to modernize the Java language and APIs in Java ME, and to better integrate with the Web, with the network, and with other Java platforms.
Q: In March 2008, when you were asked in an interview about changes you wanted to see in the JCP, you said you'd like to see more open-source and non-profit groups joining the organization. Has the JCP been moving in these directions?
A: The core of the organization is still the large commercial entities (IBM, HP, Motorola, Nokia, and many others) -- and we certainly need their support, since they do the majority of the hard work of leading JSRs and serving as members of Expert Groups. But it's worth pointing out that about three quarters of our membership consists of individuals. We do have a small number of research, open-source, and other non-profit organizations. The growth in this area hasn't been as great as I'd like it to be, but we have been successful in one area -- with Java User Groups. A couple of years ago we waived the membership fees for Java User Groups, and since then several have joined. We currently have more than 20 JUG members from all over the world, including Europe, Asia, Africa, Brazil, and Russia. I'm very pleased about that. The next step will be to get them actively involved -- reading and commenting on specs, participating in Expert Groups, and so on.
Q: How many JSRs are currently active and how are they distributed in the platform?
A: We have a definition for "active JSRs" (because we have a number of JSRs that are inactive, and that we want either to revive or close down.) We define a JSR as active if it has made formal progress through the process -- by issuing a draft of the spec, going to ballot, or making a final or maintenance release -- within the last 18 months. This is a somewhat "relaxed" definition of active, and we should probably expect faster progress, but that's another matter.
By this definition we had 46 active JSRs at the end of 2010. They were pretty evenly distributed between the three platforms.
""Now things are beginning to move again, and we can expect to see advances in all three platforms and further changes to the Process in the next couple of years.”
Chair of the JCP
Q: How has the JCP governance model and expert group processes changed over the years?
A: The JCP was formed 12 years ago, in December 1998. Initially, it was very clear that Sun was in complete control and that everybody else was only there to "advise." There were no Executive Committees, no voting, and no JSPA (Java Specification Participation Agreement). Effectively, Sun was the only developer and licensor of Java technologies.
Over the next couple of years Sun's partners and collaborators pressed for more influence. Sun responded with a revision of the Process (JCP 2.0) in mid-2000, which granted significantly more power to other companies. The Executive Committees were formed and the first version of the JSPA was released. This granted joint copyright to Sun and to the Spec Lead, since by then a small number of JSRs were being led by people outside of Sun. Most importantly, future revisions of the Process were to be carried out through the JSR process itself, with the Executive Committees acting as the Expert Group. This gave significant power to EC members since they would then control how the Process evolved.
The next phase involved concessions to the open-source movement. Apache had pointed out that the existing processes didn't permit "Independent Implementations" (those that weren't derived from the Spec Lead's code.) This was fixed in a revision to the Process in 2002 to permit Independent Implementations. The JSPA was also changed so that copyrights vested only in the Spec Lead. Since this revision of the Process, there have been many successful independent open-source implementations of Java EE technologies, but none in Java ME or Java SE. (Of course, Oracle's open-source implementation of Java SE has played an important role.)
From late 2007 onwards, the dispute with Apache over TCK licensing terms for Harmony (their implementation of Java SE) gradually led to stalemate within the organization. We did make a minor revision to the Process in 2009, focusing on increased transparency and on agility, but until the vote on the Java SE JSRs late last year, we weren't able to make much progress. Now things are beginning to move again, and we can expect to see advances in all three platforms and further changes to the Process as the JCP.next JSRs are completed during the next couple of years.
Q: Two years ago, in an interview you said that your focus at the JCP was on increasing transparency. How has it gone since then? Is the JCP more transparent than it was two years ago?
A: It's gone well and yes -- we're definitely more transparent than we used to be. In 2009, we did a Maintenance Release of JSR 215, which defines our Process Document (the procedures that govern how JSRs are developed.) We added a requirement that Spec Leads publish the transparency techniques that they use so everyone knows who's doing the right thing. Most of them now have public aliases, for example. I expect that in the next revision of the Process Document we'll make the use of certain transparency techniques mandatory rather than simply "strongly recommended." So, for example, Expert Groups will be required to carry out their work on public aliases, to use public issue-tracking mechanisms, to accept feedback from the community, to publicly respond to feedback, and so on.
Q: What are some interesting JSRs that Java developers should know about?
A: I could mention a few…
JSR 337 -- the Java SE 8 Platform JSR -- will be particularly interesting since it will define a module system for Java. If this is successful, it could lead to significant changes in the way that all three Java platforms are packaged and distributed -- with a common "kernel" for Java SE and Java ME and with profiles for various types of applications in all three platforms.
Before this, in Java SE 7, there will be a relatively small but very significant change; JSR 292 -- Supporting Dynamically Typed Languages on the Java Platform. This will introduce a new Java bytecode in the JVM -- invokedynamic -- and a new method linkage mechanism to make it easier to support dynamically typed languages, such as Ruby, Python, and PHP, on the Java platform. The JVM is not just for Java any more.
Finally, JSR 330 -- Dependency Injection for Java -- is interesting for a different reason: it was the fastest JSR ever completed. From start to finish it took 20 weeks.
Q: How does the JCP walk the fine line between respecting standards and encouraging innovation?
A: The reason we exist is to develop standards. By definition, this needs to be a deliberative process. When I next take a trip by air, I want to know that the interface between the wings and the fuselage has been thoughtfully designed and well tested! Similarly, if you're building enterprise-class software, you want well-designed interfaces. A standards-developing organization isn't necessarily the best place to innovate -- you don't really want to be on the cutting edge. It's probably better if someone has been trying things out in the real world and if there's a general consensus that interfaces are solid, well-designed and suitable for their purpose before you adopt them. The best way to do things is probably to start with open-source development processes. This allows you to do relatively rapid development, to generate and to test new ideas in the real world. Then when things settle down and things look solid, you bring things in to a standards organization and formalize the interfaces.
Q: It has now been nearly four years since Sun open-sourced the Java Platform. You have been JCP chair for about 3 years and before that, you ran the team responsible for developing the Technology Compatibility Kits (TCKs) for Java SE and Java ME. Do you have a sense of how the JCP changed as a result of open source?
A: It's had a very significant impact. About half of all JSRs are now developed through open-source projects or released with open-source licenses, and the proportion is increasing. Most Java EE JSRs are now pure open-source projects with Oracle's implementation being released in open-source form as the GlassFish Server, and in Java SE, of course, there's OpenJDK. The situation in Java ME is a bit different -- the business-models of the various players (particularly the carriers) are not so sympathetic towards open source.
Q: In October, 2010, IBM announced plans to collaborate with Oracle to support the OpenJDK project and in November Apple made a similar announcement. What is the significance of this?
A: It's extremely good news that IBM and Apple have signed on to the OpenJDK project -- we need corporate as well as individual developer participation, and these are two of the main players. Since the intent is that all future development work for the SE platform will be carried out through Open JDK in an open and collaborative manner, we obviously need the big corporate players to contribute. I hope that others will follow the lead of Apple and IBM. (Just to set the record straight, Red Hat has been contributing for several years now.)
Q: In 2005, when I asked JCP Chair Onno Kluyt about the biggest misconceptions about the JCP, he said that there were two: “First, that Sun controls everything, and second, that standardization is slow.” How would you answer the same question today?
"“Oracle can't go it alone. They can't advance Java without the support of the ECs and the broader community. It's a delicate balance that over the years has clearly shifted from Sun/Oracle to the community.”
Chair of the JCP
A: As for Sun and now Oracle's control -- yes, it's true: Oracle is "more equal than others." However, Oracle also makes significantly greater contributions than others. I've already noted that Oracle is the Spec Lead for more than half of the currently active JSRs. Over the years Oracle and the companies it has acquired have spent literally hundreds -- probably thousands -- of staff years developing the Java platforms. I did a quick estimate by looking at all completed JSRs (about 200 in all) to see who was the Spec Lead. Awarding one point for sole spec-leadership and half a point for joint spec-leadership, we find that Oracle and the companies it has acquired were responsible for just about two thirds (65%) of all the effort invested in developing Java. (Oracle scored 145 while all other companies together scored 78.5.) Obviously, Oracle feels entitled to a return on that investment. Having said that, it's clear from recent events that the other Executive Committee members and the broader membership of the community also have significant influence.
Onno pointed out, and I'll repeat, Oracle's control is limited to the evolution of the platforms themselves. As the Spec Lead for the existing platforms, Oracle obviously has significant influence over how the platforms evolve. The Process Document actually gives Oracle a veto power over the creation of additional platforms and over changes to the Java language and the Virtual Machine. However, it's the Executive Committees that have the real veto power. No JSR can progress, and the Process itself can't be modified, without their approval. Oracle can't go it alone. It can't advance Java without the support of the ECs and the broader community. It's a delicate balance that over the years has clearly shifted from Sun/Oracle to the community.
As for speed, it's true that standards take time to develop. As I suggested earlier, that's probably a good thing -- we need our interfaces to be solid and well-designed. However, I also pointed out that JSR 330 was completed in 20 weeks, which proves that the process itself isn't inherently slow. Developing high-quality software is a difficult and time-consuming task. Most of the effort involved in developing a JSR is simply the normal overhead of professional software-engineering processes. Standardizing doesn't necessarily increase the total effort significantly.
Having said that, we if we take too long, then our standards will be out of date or will not be adopted. So -- we're constantly looking at ways to improve our agility, and we've published some case-studies on jcp.org as a guide for Spec Leads.
Q: What are the leading criticisms of the JCP that you encounter? Can you give us a sense of the strengths and weaknesses of the criticisms you hear?
A: One criticism I often hear is that we're a secretive organization -- that we work behind closed doors. Some people seem to think that if they join the JCP or participate in an Expert Group, they'll somehow be gagged -- prohibited from discussing the work of the organization with others. That's simply not true. Yes -- there's some scary language in the JSPA that refers to confidentiality. However, it simply says that Expert Groups may, if they wish, label some materials as confidential. They almost never do and in the most recent change to the Process, we explicitly discourage this. (We'll probably prohibit it completely in the next revision.) In practice, most Expert Groups operate in the open, and we strongly encourage them to do so. (Remember that about half are operating as open-source projects.) Similarly, the Executive Committee publishes its meeting materials and minutes at jcp.org. Check it out.
Having said that, we recognize that we need to do even more to encourage openness and we're planning to do so in the next revision of the Process, which will be implemented in the next few months.
Q: What are the greatest current sources of fear, uncertainty, and doubt (FUD) about the JCP?
A: Whether we have a future -- whether Oracle cares about the community and the collaborative process. It does. I admit (and Oracle would probably admit) that it has made some mistakes in its handling of the organization and in its relations with the developer community. However, we're working hard to fix this.
Q: Are there any particular areas of expertise that the JCP needs help with?
A: Perhaps not particular areas of technical expertise (there's room for all kinds of expertise, given the diversity of the specs that we develop), but we certainly need the energy and enthusiasm of Java developers. People who have experience working in open-source organizations would definitely have a lot to offer.
There are lots of ways to participate. The simplest -- and least time-consuming -- is to read and comment on some of the specs that are under development. Choose something that interests you and jump in. If you can make a larger commitment, then you can join one of the open-source development communities (OpenJDK or GlassFish for example). You can play with the code that's under development or even contribute, if you want. Then, if you want to go even further, you can join an Expert Group and actively participate in the development of the JSR.
While it's also possible for individuals to play the Spec Lead role, I must point out that doing so is very difficult and requires a significant investment of time and energy. If you can get your employer to sponsor you, then that would help significantly. (This is how Stephen Colebourne is managing to lead JSR 310: Date and Time API, for example.)
The bottom line is that as we have become more open and transparent, there are many ways that people can contribute, putting in as much or as little time as they want. We strongly encourage this. It's good for us, and it's good for them.
Q: How has the JCP changed since Oracle acquired Sun?
A: Well...even though it's now been a year since the acquisition, I think it's obvious to everyone that for most of that time, we were in a holding pattern while the dispute over TCK licensing terms was being worked out. Late last year, things came to a head with the submission of the JSRs for Java SE 7 and Java SE 8. It's also no secret that not everyone believes that the problem has been solved. (We did have three resignations from the SE/EE EC.) Nevertheless, I think it's fair to point out that Oracle was determined to -- and did -- work through this problem that had originated during the Sun years, and that Sun had been unwilling or unable to resolve. As I said, not everybody is happy with the outcome, but at least we can now move forward again.
It's also clear to me that Oracle is supportive of the JCP and wants to see it succeed. We have a lot of work to do to regain the trust of the developer and user communities, but Oracle is working hard to reach out, and I'm hopeful that we'll succeed in rebuilding that trust. (The recent announcement that Oracle plans to nominate the Brazilian Java User Group, SouJava, to the Executive Committee is one example.)
You can expect to see more change during the next year or so, as we work on the JSRs to advance the three platforms and also to modify the Process itself through the JCP.next JSRs.
Q: Doug Lea and the Apache Foundation both resigned from the JCP's Executive Committee recently. How significant do you believe these resignations were?
A: Doug and the Apache Foundation have contributed enormously to Java and to the JCP over the years, and I was very sorry to see them go. Let's see how things work out over the next year or so. Perhaps we'll be successful in making enough changes so that they'll feel they can come back. If not, at least we know that Doug will continue to be involved through his role as a member of the OpenJDK Governance Board, and that Apache will continue to implement Java technologies even if it will no longer participate directly in creating them.
Q: Some bloggers have in the last couple of months claimed that the JCP is dead, or seriously weakened, or is no longer an open standards body. Do you want to respond to such claims?
A: To paraphrase Mark Twain, the reports of our death are an exaggeration. We're still here, and as I've tried to explain during this interview, things are moving again. Yes -- we've been weakened by the disputes that began several years ago, but we're working hard to rebuild. I know that Oracle takes the role of Java steward seriously. Now that we've broken the roadblock, I hope people will give Oracle a chance to show what it can do.