Advertisement

Why Go Through the JCP?

Frank Sommers: Does a JCP JSR represent an "official" Java standard? What would prevent developers from favoring a non-JCP-developed solution to a problem over a relevant JSR?

Rob Gingell: The JCP reserves the namespaces java.* and javax.*. Other than namespace use, there's nothing about the JCP that requires anyone to use the APIs created through it. If there were, say, a javax.toaster.* family of classes, there's nothing that stops anyone from working outside the JCP to create an org.othertoasters.* family.

The JCP would tend to resist having a competing javax.othertoasters.* activity under its roof, but couldn't do anything about someone setting up a completely different thing in competition.

One reason we don't see instances of many competing APIs is that there's a general appreciation that Java's value lies mostly in the over 3 million developers who see that an investment in a single set of skills gives them a wide market in which to work. Fragmentation would be inconsistent with the value proposition perceived by those developers, and thus counter-productive to the motivations that would lead one to want to make toaster-based APIs in the first place.

Ultimately any community is defined by what makes up its members' common self-interest, and while that self-interest might be codified into agreements and practices and process rules, what really makes it work is the shared set of values behind it. If you're building something you want developers to target, you're not well-served by fragmenting that developer pool.