JSR 347: Data Grids for the Java platform, a call for EG members

Exciting times; today the JCP voted in a new JSR that I have proposed, JSR 347: Data Grids for the Java platform.    I blogged about the original JSR proposal, and posted a follow-up to some criticisms around the proposal some weeks ago.  The proposal, however, went ahead, was assigned a number (347!) and has just been voted in by the JCP executive committee.

Before I go into the details of 347 and my plans around it, I'd like to highlight some concerns in the community, in the area of overlap with JSR 107.

Is JSR 107 dead?
No.  In very recent months, there has been a flurry of activity in JSR 107.  Activity which I am a part of, and hope will drive 107 to completion.

Does JSR 107 compete with JSR 347?
No.  JSR 347 aims to build upon JSR 107.  JSR 107's goals is to provide a temporary caching API for the Java SE platform.  JSR 347 plans to reuse JSR 107's APIs, adding additional features such as an asynchronous API, as well as defining mandatory characteristics such as behaviour with XA/JTA transactions and distributed workloads, thus targeting the Java EE platform.

Will JSR 347 retard the progress of JSR 107?
No.  If anything, JSR 347's need for JSR 107 to complete will add impetus to the JSR 107 effort.

I sincerely hope the existing expert group of JSR 107 (of which I am a member) can and will work well with (and join!) the nascent expert group of JSR 347, to drive both JSRs to successful completion.

Now onto next steps with JSR 347: forming an expert group to put together an early draft.  I would like to open invitations to join the expert group, please sign up on the JCP website.

With regards to process, with my background in open source and working with distributed teams, I intend this JSR to be developed in the public, making use of public mailing lists, public IRC channels and the like.
I've even set up a twitter account for JSR 347 so people interested in its progress may follow it!

Cheers
Manik