Improving the Java Specification Request Process

The JSR process is know to take a lot of time produce an actual specification. On top of that, it often produce overly complex specifications that are way too overkill to solve the problems they intend to solve. It is also a process that is driven by the main vendors desire with little thoughts for developers.

We could probably shorten the process and increase the usefulness of JSR by bringing a bit more agility in the process. Here is what I think we could do to make things a bit better :

1. Create the reference implementation first. Then produce the specification. A working implementation offer greater value than just having a specification. It allows the community to use it and comment on real life issue. This is way better than commenting on a theoretical document.
   Groovy is a good example of creating a reference implementation before a specification. Granted, it took a lot of time (lack of resource availability) to achieve, but in the end, we have a better Groovy than if we produced a specification first and then implemented it. Once a specification is voted, there is little coming back (beside repeating the complete JSR process). Voting on a working implementation mean voting on the real thing!
   
2. Make the sponsors of the JSR provide full time resources to work on the reference implementation. There is nothing worse than only having resources working part time on a JSR. Things go slower and communication suffer when the team members have other responsibilities.
3. Make the reference implementation Open Source from day 1. Make the code public as soon as basic functionality is built in. This allow the community to participate early and provide early comments.
4. Make all communication related to the JSR public from day 1. Public forum and/or mailing list increase the diffusion of the information. Issue/feature tracking should be readily available and every decision made on issues/features should be made public. Having public communication will again increase the community involvement and at the same time decrease the sentiment that the JSR driven by the vendors secret agenda.
   
5. Have the JSR team produce workable software at regular intervals (every months for example). These content of each iteration should be determined at the beginning of the iteration based on the issue/feature backlog. Each iteration should have a specific goal to make sure that the team focus on the right thing for the iteration.
6. If the JSR address something that is already available in an Open Source project, it should review the project and base it's work on it. If something exists there is no reason to start from scratch.

Doing all of this will ensure that at even if the JSR is voted off,the community will gain working software. It will then be its choice to use it or not. But I believe that with these kind of changes, most JSR, will either fail early (which is good as less time will be spent on it) or either succeed when they attain the voting stage (aka version 1.0).

2007 Predictions

Everybody doing it! Not wanting to be left in the cold, I will follow the herd and make predictions for 2007.

RoR will run flawlessly on a Java Application Server

The good people from JRuby are making incredible progress since they've been hired by Sun. We will soon be able to run RoR applications with no (or very little and trivial) modifications on Glassfish or other Web Container. Will that makes RoR application more scalable? I'm not sure. But it will increase RoR momentum in Java shops. When you talk about RoR to a java shop, the first question they have is "Will it run on Tomcat|WebLogic|WhebSphere|...?"

JRuby will take the top spot for scripting the Java platform

To the demise of Groovy, JRuby will take the spotlight. The main reason is the previous prediction. Once you can run RoR on a Java application server, nobody will need Grails. Grails is the only use of Groovy that create adoption.... Unless some other killer Groovy application, tool or framework is created.

RoR adoption continue

That's a fairly conservative prediction. RoR as a lot of momentum.

Java 6 adoption will start slowly in Q3

While Java 6 is out. It's adoption will grow slowly and will mainly be driven the scripting language support. Java 5 had many compelling reason to get adopted by many shops, but many many many application are still running on Java 1.4. Beside scripting support, there is nothing compelling enough in Java 6 to make it's adoption within the enterprise faster that Java 5.

Something will happen in Java build tool space

A lot of people are tired of Ant . Maven is cool, but lacks flexibility. Scripting language is getting more attention... We have Gant, Raven, JRake and many other existing or yet to be created build tool that use scripting language. By the end of the year, one of them will start getting a lot of traction. My best guess for now is Raven.

Java Specification Requests will become less and less relevant

The JCP is not working very well. It's too lengthy. Design by comity does not work well. Many JSR do not stand the sand of time. Today JSR mostly reflect some existing API with less feature (JPA vs Hibernate for example). They do not offer innovation, they just tend to seal mature innovative technology in the platform. New language features takes too long to traverse the JCP and with the open sourcing of Java, it will become easier for one group to add new feature to the language and to make a Java distribution of it's own. And with JSR like JSR-277 that create more turmoil than solve any problem, more and more people loose interest and faith in the process. Sun is not even interested in really supporting existing JSRs. We have a JSR for Groovy, but Sun hire the JRuby developers without giving any resource to Groovy. That's it! I made my prediction for 2007. This is probably my last post of the year, I will try to post a bit more often next year! In the mean time, have a Great Christmas and a really Happy New Year!