In my mind, an ecosystem conjures up a green, lush rain forest. The Java ecosystem, like a rain forest, is excitingly complex and able to sustain a diversity life and growth. At the JCP we have successfully balanced a variety of participants, who both compete and cooperate for success within our ecosystem.

The Java Community Process (JCP) program is a vital piece of the vibrant Java ecosystem, where the participants come together to standardize the platforms and APIs. Far from being the whole ecosystem, we're effectively doing our part to create broadly adopted standards with built-in compatibility, and we're working to stay in synch with the rest of the ecosystem. The JCP has been around for six years, and our success over that time has paralleled the success of the rest of the ecosystem - we're growing, getting smarter, and working together.

At the core of the JCP program's success is our ability to evolve with the ecosystem. Who can remember a time before we guaranteed the ability to create independent implementations, or before there were Executive Committees (EC) making the key decisions for the JCP program? Only the gray-hairs remember the days when Sun was the only company allowed to lead Java Specification Requests (JSRs)or when individuals weren't allowed to join in equal standing with the rest of the community members. We've come a long way and we're meeting the needs of the community better than ever.

The most recent evolution of the JCP program happened one year ago. In March 2004 we launched JCP version 2.6, which focused on increased transparency, participation, and efficiency (time-to-market) for JSRs. One year in the life of an ecosystem such as a rain forest is no time at all, but in the Java ecosystem, one year is a long time, and it allows us to evaluate the changes we have made and gauge their effectiveness.

The first area of focus for JCP 2.6 was the transparency of the JSRs. We heard from the community that a couple of changes would be beneficial in this area: giving more people access to early drafts of the JSR specifications, and ensuring all JSRs were optimally transparent for people not participating in the day-to-day activities of the JSR. These JCP 2.6 changes have had a positive impact: Spec Leads are getting significantly more feedback and more useful comments at the first review period, community members are getting access to more open issues and background on decisions made by JSRs, and the public has doubled their opportunities to review JSRs. JSRs under JCP 2.6 are more transparent, and that has proven to be a benefit to the community.

The second area of focus for JCP 2.6 was increased participation. The community wanted more tools to operate JSRs and more opportunities for the public and community to review drafts of the specifications. Since we implemented version 2.6 one year ago, we have seen the number of JSRs led by community members other than Sun continue to rise. By the end of 2004, the rest of the community was leading more than twice the number of active JSRs than Sun. This demonstrates a healthy increase in the investment of the community and the standards piece of the Java ecosystem.

The third area of focus for version 2.6 was increased efficiency, enabling JSRs to get to market faster, encouraging broader adoption with increased compatibility. JCP 2.6 changed the timing of the EC ballots that each JSR must pass. Under previous versions, all JSRs had to pass their second EC ballot relatively early in the life cycle of the JSR. This caused Spec Leads to get anxious about going to the first review with any open issues, and to spend roughly 200 days getting the JSR ready for that first review and ballot. Under version 2.6, that EC ballot is later in the process, resulting in an average of 125 days for JSRs to get to the first review period. This shows an encouraging trend of JSRs getting more efficient, enabling them to get to market faster and secure broader adoption within the ecosystem.

JCP 2.6 has certainly been more successful than we envisioned when we rolled it out a year ago. This evolution strengthened and grew the Java ecosystem. The participants continue to get more diverse, and there is a need to ensure that the standards for Java technology remain strongly committed to compatibility. The JCP program continues to look for ways to stay ahead of the evolutionary curve.

The Program Office and members of the EC are looking at ways to keep the community operating effectively and efficiently within the Java ecosystem. We are actively looking for input. If you have ideas for solutions to problems that you feel are preventing the JCP program from being as successful as it could be, or if there are things that are discouraging your participation, contact me directly at aaron@jcp.org. Our part of the Java rain forest, I mean ecosystem, is yours to help us evolve.

Sidebar

New Format
Starting with this issue I'm introducing a new format for the monthly JSR Watch column, inviting folks involved with the community to share their thoughts and opinions. It's timely that my first guest is Aaron Williams, since this spring the JCP program is celebrating the one-year anniversary of JCP 2.6. Aaron led the JSR that defined JCP 2.6 and worked closely with the community to develop and implement this process specification.