Here's an update from the Chair of the JCP and director of the JCP Program office: Patrick Curran

http://java.ulitzer.com/node/965152


JSR Watch: Here’s to Progress

And here’s to the next 10 years!
By Patrick Curran

May 15, 2009 03:00 PM EDT
Reads: 560

The end of the year is an opportunity to review the past year's activity, and to present this to our Executive Committee (EC) members, to our broader membership, and to the general public. So this month I will summarize our progress during the past year.

PMO Initiatives
First, in addition to the ongoing work of moving JSRs through the process (more on this later), the JCP engaged in a couple of new initiatives around transparency and agility.

I've addressed the transparency issue relatively recently in this column, so I won't say much more here except to remind you that we are now strongly encouraging all Expert Groups (EGs) to work in an open and transparent manner by adopting practices such as the use of public mailing lists and issue-tracking mechanisms. Of course, it would be hypocritical for us to encourage this behavior in EGs while continuing to hold Executive Committee (EC) meetings in private, so there too we are becoming more open. Starting in September 2008 the ECs agreed to make full minutes and meeting materials accessible to the general public rather than simply posting summaries that only JCP members could read. (We reserve the right to go into Private Session from time to time when sensitive matters are discussed, but we don't expect to do this very often.) If you want to see what we're up to, the meeting materials are accessible.

As for agility, when I reviewed 2007 activity this time last year it became apparent that the amount of time it takes Expert Groups to complete their work varies significantly. Some manage to finish in a little more than a year, while others take several years. Also, we know that there are some JSRs that are effectively stalled and really ought to be withdrawn. As a first step to encourage agility we decided to introduce a new category for JSRs that have made no progress for 18 months - these will be labeled as "Inactive" on jcp.org. The PMO will work with the Spec Leads of these JSRs to encourage them to pick up the pace. If it becomes clear that the JSR is unlikely to complete, we will encourage them to withdraw it. In addition, we plan to review all JSRs that reach completion, and others as appropriate, to identify and publicize the good (and bad) practices that affect the speed with which JSRs move through the process.

Both of these subjects were discussed at the December EC meeting. Thanks to our new "open and transparent" policy, you can review the presentation that formed the basis for that discussion here.

Membership
Our membership grew slightly (by 3%) in 2008 to a total of 1,465. About three quarters of these are individual members, while most of the others are corporations, with a small number of non-profit organizations (open source foundations, universities, etc.). Half our members are based in the U.S., one-third in Europe and the Russian Federation, and most of the rest are based in Asia and the Middle East, with 4% in South America. Since individual membership is free and never needs to be renewed, it's likely that some of these members are "inactive" (not having told us that they've moved on), but the turnout in our annual elections (around 30%) shows a reasonably healthy participation rate. Speaking of free membership, we are currently waiving membership fees for Java User Groups who wish to join the organization (several are in the process of doing so). Visit our site for further information.

JSR Activity
In line with the new definition of "Inactive JSRs" (those that made no formal progress through the system during the past 18 months), we collected data on JSRs that made progress during the past 18 months rather than during the calendar year 2008. By this definition we currently have 70 Active JSRs. During this period six new JSRs were started (two others were proposed but failed to win approval), 16 JSRs completed, and 13 issued Maintenance Releases. An additional 38 made other progress through the system, mostly publishing Early Drafts, Public Review Drafts, or Proposed Final Drafts.

Of the 70 Active JSRs, 27 targeted Java ME, 20 were aimed at Java SE, 15 were for Java EE, and 8 intended to support both Java SE and Java EE.

The new JSRs were JSR 320: Services Framework (AT&T); JSR 321: Trusted Computing API for Java ( IAIK Graz University of Technology); JSR 322: Java EE Connector Architecture 1.6 (Sun); JSR 325: IMS Communication Enablers (ICE) (Ericsson AB); JSR 326, Post mortem JVM Diagnostics API (IBM); and JSR 327: Dynamic Contents Delivery Service API for Java ME (SK Telecom).

The JSRs completed in calendar year 2008 were JSR 272: Mobile Broadcast Service API for Handheld Terminals (Nokia/Motorola); JSR 293: Location API 2.0 (Nokia); JSR 298: Telematics API for Java ME (SK Telecom); JSR 311: JAX-RS: The Java API for RESTful Web Services (Sun); JSR 289: SIP Servlet v1.1 (Oracle), JSR 240: JAIN SLEE v1.1 (OpenCloud); JSR 281: IMS Services API (Ericsson AB); JSR 258: Mobile User Interface Customization API (Nokia); JSR 286: Portlet Specification 2.0 (IBM); and JSR 254: OSS Discovery API (Nakina Systems).

A further six JSRs completed in the second half of 2007: JSR 190: Event Tracking API for J2ME (Amdocs Management); JSR 196: Java Authentication Service Provider Interface for Containers (Sun); JSR 263: Fault Management API (HP); JSR 264: Order Management API (Codecentric); JSR 280: XML API for Java ME (Sun, Nokia); and JSR 291: Dynamic Component Support for Java SE (IBM).

The time it took these JSRs to work their way through the process varied from a little over one year for JSR 291 to five years for JSR 190. There are obviously lessons to be learned about how to - and how not to - complete JSRs quickly, and we will investigate further over the coming months.

Spec Leadership and Expert Group Participation
Twenty-two organizations and three individuals played a Spec Lead role on the 70 active JSRs. Sun was the most active, occupying 27 Spec Lead positions, followed by Nokia (11), Oracle (8), Motorola (5), and IBM (4).

Another measure of involvement is participation in Expert Groups. More than 1,200 members served on the EGs of active JSRs (an average of about 17 per group). Two-hundred twenty-one different organizations contributed EG members, together with 245 individuals. Once again, Sun was in the lead with 92 Expert Group members. Oracle (after absorbing BEA) contributed about 75, followed by IBM (54), Motorola (42), Nokia (39), Red Hat (27), Ericsson (24), SAP (24), and Samsung (23) - to list only those companies that contributed 20 or more.

These numbers make it clear that no matter how important we believe individual members are (and I do strongly believe they are important, and appreciate their involvement), the JCP's work could not be accomplished without the active participation of our large corporate members.

Happy Birthday, JCP
Finally, 2008 was a special year for the JCP, since the organization turned 10 years old in December. We celebrated the event in January with a party at the Computer History Museum in Mountain View, to which we invited JCP program participants - Executive Committee members, Spec Leads, and Expert Group members - as well as Sun executives, members of several local Java User Groups, and others who have been influential in the development of Java over the past 10 years. You can see a slide show of photographs from this event.

I'll finish this column as I finished my brief welcome speech at the birthday party, by noting that Java would not be where it is today - with millions of developers, and running on billions of devices - without the JCP. By working collaboratively to develop Java technologies, we grow the market for everybody. Happy birthday to the JCP and here's to the next ten years!

Views: 46

Happy 10th year, JCertif!

Notes

Welcome to Codetown!

Codetown is a social network. It's got blogs, forums, groups, personal pages and more! You might think of Codetown as a funky camper van with lots of compartments for your stuff and a great multimedia system, too! Best of all, Codetown has room for all of your friends.

When you create a profile for yourself you get a personal page automatically. That's where you can be creative and do your own thing. People who want to get to know you will click on your name or picture and…
Continue

Created by Michael Levin Dec 18, 2008 at 6:56pm. Last updated by Michael Levin May 4, 2018.

Looking for Jobs or Staff?

Check out the Codetown Jobs group.

 

Enjoy the site? Support Codetown with your donation.



InfoQ Reading List

Presentation: How to Get Tech-Debt on the Roadmap

Ben Hartshorne discusses how to pitch a product, covering why one needs to make a business case, what is tech debt, what data is most compelling, getting tech debt on other teams’ roadmaps

By Ben Hartshorne

Podcast: InfoQ Culture & Methods Trends in 2024

In this podcast the Culture and Methods editorial team along with special guest Jutta Eckstein talk about the current state and trends we see in the technology industry in 2024.

By Susan McIntosh, Jutta Eckstein, Craig Smith, Ben Linders, Rafiq Gemmail

HashiCorp Released Version 2.3 of Terraform Cloud Operator for Kubernetes

Hashicorp recently released the version 2.3 of Terraform Cloud Operator for Kubernetes with a new feature: the ability to initiate workspace runs declaratively. The Terraform Cloud Operator for Kubernetes was introduced in November 2023 with the goal to provide a Kubernetes-native experience while leveraging Terraform workflows

By Claudio Masolo

KubeCon EU: Backstage, Crossplane and Others Preparing for CNCF Graduation

More projects from the CNCF incubated level are preparing to graduate for an ever-widening cloud native ecosystem. The Backstage community has worked on a more robust architecture, and Crossplane aimed to improve its developer DX. KubeFlow and Volcano, both tools promising to improve AI adoption within the Kubernetes ecosystem, are working on easier installation and more features, respectively.

By Olimpiu Pop

How to Tame Technical Debt in Software Development

According to Marijn Huizenveld, discipline is key to preventing accumulating technical debt. In order to be disciplined you should make it difficult to ignore the debt. Heuristics like fixing small issues immediately, agreeing on a timebox for improvement, and making messy things look messy, can help tame technical debt.

By Ben Linders

© 2024   Created by Michael Levin.   Powered by

Badges  |  Report an Issue  |  Terms of Service