Atom Feed SITE FEED   ADD TO GOOGLE READER

JSRs aren't appropriate for classlibraries

In addition to more platformey changes and language changes, the JCP develops standard classlibraries for the JDK. Let's contrast this process to open source development of classlibraries. In particular I'm thinking about libraries like binding, app frameworks, units/measures, date/time, module systems, and object-relational mapping.

Code Quality


JCP: consistently very good.
Open source: hit and miss. Some are excellent, some are trash. There's a current trend of porting or reinventing the excellent ones as JSRs.

API Stability


JCP: fixed in stone. These APIs never change. As a consequence, we're permanently stuck with every bad design decision released in a JDK.
Open source: flexible. If you're happy, you can keep your current version. If you want new features, migration to the latest and greatest may require effort.

API Choice


JCP: one-size-fits-all. Even if there are open source alternatives, the JDK API is 'standard', and not using it is an uphill battle that will require thorough justification to your team.
Open source: a marketplace. For example, there's a variety of PDF libraries for Java, each with their own relative merits.

Development Pace:


JCP: a few people work their asses off for six to twelve months and release something that meets the spec. If they missed feature you need, wait eighteen months for the next JDK.
Open source: agile. All interested parties can contribute fixes, bug reports and enhancements. If you need a missing feature, add it yourself. You can even patch your own version if necessary!

Coping with bad APIs


JCP: if the JDK includes an API I don't like, I'm pretty much stuck with it. Tough shit! We're already stuck with tons of crappy code in the JDK. Some JSRs will be flops, and we will be stuck with their code forever.
Open source: if it sucks, something better will be written. Free markets are awesome!

So...


So what's my problem? I just don't see the benefit of a giant process for writing 'blessed' libraries. Does every JRE really need a KinematicViscosity class? Why grant some libraries first-class status when we could let the market decide?

Instead, why not compliment the JCP (still great for language-type changes) with something like Perl's CPAN or Ruby's Gems? We could combine the benefits of easy access to classlibraries with the flexibility of open source libraries. We could even include ratings of APIs, so you could have confidence when choosing an API.
The really nice thing about the JDK is how simple it makes your dependency graph: "we require JDK 6". Resistance to using something outside the JDK is mostly resistance to complicating the dependency graph. The drawbacks of depending on a very fine-grained, constantly shifting dependency graph should be obvious by now.

Something like CPAN might be nice, but unless a distributor goes through the trouble of defining stable releases that contain versions that are known to work together, it's chaos compared to the JDK.

So I'd like to see something like a Linux distribution that bundles together sets of open source libraries into releases, except pure Java. The problem with libraries in the JDK is that the maintainers don't think like Linux distributors; rather than bundling existing, stable versions of libraries together with perhaps a few patches, and allowing upstream software projects to decide when an API has to change, they want to write standards and then lock down the API.
A-frickin'-men.