Simon, nope, I'm not on the JCP, for a few reasons:
a) the JSPA legalese required to participate: too long, too NDA-ish. I want to help improve specifications. Making all the individual who'd be able to help spend their time dissecting 10 pages of dense legalese before one can help is not such a great idea. The JCP should either drop the JSPA for participating on the JSRs, or cut it down to one page.
b) unclear legal restrictions on participants in JSRs. When the call went around to join the Mustang, I asked the spec lead what the legal implications would be on me as an independant implementor, but got no real reply. If Sun's spec lead on Mustang can't figure out what the legalese means, then there is someting seriously flawed with the system.
c) most core Java JSRs are not transparent, for members and non-members alike. If I want to know what's being cooked in JSR 277, to pick an example, I wouldn't be any wiser than I am now if I joined the JCP, as the spec lead is not encouraging public participation on that JSR, within or outside the JCP.
d) JCP is currently focused on quantity, rather than quality of the specs. In particular in the area I am familiar with, Java 1.5, there are several APIs that are very poorly specified, and should have never become part of Java. Stuff like http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4350444 is rather bad in an industry standard.
I think JCP is a good idea, that's not implemented very well. For Java to prosper in the future, the JCP needs to open up majorly, and grow further than the 700 individuals and organisations that are in it today. It needs to come with full, mandated transparency on every JSR, no-strings-attached access to specifications and test suites, like W3C does. It needs to have a patent policy that requires disclosure of submarine patents embedded in specified technology, and created a patent covenant around each JSR.
It needs to make the life of Java developers easier, not harder, as it does currently.