In this editorial, we argue that greater individual involvement in the JCP would lead to better specifications, and that more individual developer members could provide a
healthy balance between vendor perspectives and those of users.

http://www.artima.com/lejava/articles/jcp_individuals.html

What do you think about the role of individuals in the JCP?

> In his JavaOne keynote, Sun's new CEO Jonathan Schwartz
> credited the Java Community Process (JCP) for Java's
> widespread use and industry acceptance...

I think that the above statement is massively overselling the JCP. Java's success came from it being the right language (i.e. it was platform independent and had applets) in the right place as the Internet became widespread in the late 1990s. The existence and composition of the JCP was neither here nor there. I don't believe anyone anywhere ever decided to adopt Java because it had a JCP.

> Java's success came from it being the right
> language (i.e. it was platform independent and had
> applets) in the right place as the Internet became
> widespread in the late 1990s. The existence and
> composition of the JCP was neither here nor there. I
> don't believe anyone anywhere ever decided to adopt Java
> because it had a JCP.

Yes, Java was the right thing at the right place, but its long-term success (it's been going on for 10 or so years now) has a lot to do with compatibility between various Java standards, the JVM being the most important perhaps.

I spoke with lots of folks lately about the state of AJAX and JavaScript, and nothing could contrast more with the state of JVMs - whereas Java apps run the same on every JVM, JavaScript apps certainly do not run the same in all script engines. So that really speaks a lot to Java's compatibility, and the JCP had a lot to do with that.

The JCP ensures compatibility by insisting that specifications not only produce a spec document, but also a working reference implementation as well as a TCK (technology compatibility kit). It's really simple, actually - software that claims to implement a JCP standard must pass the TCK's automated test suite. Users then can be assured that the implementation is compatible with all other implementations.

This process, I think, has a lot to do with the high level of comfort organizations have in investing in Java-based technologies and development. Not to mention that it enables a set of players above the technology vendors to add value, since their apps are guaranteed to run in the various products of those vendors (you don't write for JBoss or BEA, but to Java EE5, for instance).

Correct. Without the requirements for TCKs and RIs for each JSR the JCP would become a free for all for all kinds of weird ideas and would quickly becomes useless or worse, a detrimental force to the platform.

As it is only well thought out and workable ideas get implemented (or at least fewer ill thought out ideas do get implemented than otherwise would be the case) and only by people who probably know what they are doing and have the guts and resources to invest in making it happen.

If everyone can start launching JSRs based purely on theoretical ideas without any practical base and those'd get incorporated into the language standard it would be a disaster almost as big as handing over the governance over the platform to the slashdot crowd.

> Correct. Without the requirements for TCKs and RIs for
> each JSR the JCP would become a free for all for all kinds
> of weird ideas and would quickly becomes useless or worse,
> a detrimental force to the platform.

When people talk about open-source Java, they often think of Java either as primarily a programming language or as a set of APIs (e.g., the servlet API), or maybe both.

Few developers think of Java as a platform, which actually sets it aside from other languages (C++, Ruby, Perl, etc), and other APIs (Apache API, Libc, etc).

One reason might be that most developers deal with Java as a language or a set of APIs. Few developers are involved in the deployment and maintenance of applications, or in crafting the IT strategy of their organizations. And fewer still are financially impacted by the operational costs of the overall IT department.

If you try to use Linux, for instance, as it is today on a desktop, you easily get a taste of what a "platform" means. For no user in their right mind would first download the kernel and build tools, build the kernel, then download a whole bunch of other source packages, etc., until you have the complete system up and running. Instead, you'd download a distro, pop a CD in the drive, and install Fedora or Mandrake or whatever. Those distros, in fact, are little "platforms," offering a full stack of useful stuff all the way from the kernel to the UI.

I'm a really long-time Linux user (well over 10 years), and I found out the hard way many times that it doesn't pay to deviate from such distros any more. For instance, I downloaded a vanilla kernel into my Fedora Core 4 system, and compiled it, etc., a few months ago. Things worked fine, until I wanted to use Fedora's upgrade capabilities - which now complained that it knew nothing about my kernel, and wanted me to download a standard Fedora kernel instead. I could have spent a couple of hours figuring out how to customize the Fedora updater—or just forget the whole customization thing and use the Fedora defaults.

This is also an issue now with larger Linux "stacks." For instance, Kim Polese's new company, Spike Source, sells entire tested and configured Linux stacks (Apache, PHP, and the whole kitchen sink). I think it makes sense, actually: If I'm the IT manager of a large company, would I rather have my employees fiddle with these things, hoping that all will work out, or would I just buy, say, the SpikeSource platform, and make the compatibility of that platform with other tools someone else's problem? Open-source does not have such compatibility requirements (yet?), but Spike does in their QA department, I imagine.

Of course, developers often are shielded from those decisions, and thus don't appreciate the value of being able to focus on just the code and design of an application, and to not have to worry whether those apps will run in certain environments.

There are many reasons why open-source by itself is not a guarantee of compatibility, nor should it be. More on that an another post.

The companies wanting to use and develop Java decided some time ago that they needed a mechanism to ensure compatibility, and the JCP is the vehicle for that. It's not perfect - but no one, to my knowledge, suggested a better alternative yet.

JCP, as it is today, does not fulfill the primary function it exists for: creation of high quality specifications, accompanied by high quality reference implementations through a transparent process involving the community of users and developers.

It's very far away from that ideal in the J2SE space. Rather than being transparent, for example, Sun-led J2SE specifications are kept behind closed doors, except for the token gestures of publishing drafts mandated by the JCP statutes. Rather then involving the community in some sort of a process, as the JCP abbreviation suggests, specifications are largely being handed down and rubberstamped by Sun and their business partners on the EC. The quality of the resulting Sun-led J2SE specifications is in part simply appalling, meaning an independent implementor without being part of the private, NDA-infested communication of a JSR in question needs to waste a lot of time figuring out why Sun in their infinite wisdom broke something again from publicly accessible blogs, mailing list, and other third party communication channels. Finally, most JCP reference implementations are not available under open source licenses, so that their study is pointless and outright dangerous for independent implementors, due to potential for copyright infringement.

Why should an individual join and legitimize the JCP, given that the things are so badly broken per explicit wish of Sun and their corporate partners? What sort of power can individual reasonably expect to wield in the corporate oligarchy that is JCP today? None, afaict.

So why waste time on the JCP, if one can't change anything for the better?