JSR refactoring

Maybe I've focused far too much on immediate problems as I've gone down my path as a Java developer and just trusted that out there, somewhere, someone was making good decisions for the Java community, leading us forward - tally ho and all that...

... and yet, looking towards the JCP for information on interface polymorphism support in JPA (JSR 220), I've come up a little sparse. The best thread I've found on the topic was offsite on the Hibernate forums (over here).

As the thread suggested, I emailed my "favourite" expert member of the JSR 220 to suggest support for interface polymorphism - and on the random wheel of potential support, I choose Linda DeMichiel (Michael Keith was a close second, but can't seem to find his email in my rolodex).

Something about this process seems a little light weight when compared with:

• how much it affects a developer's daily life
• just how many Java developers there are out there working with JPA in one form or another

So now truly seeing the JCP JSR process for the first time I can understand a bit more why JSR 306 is so important: we need to change this process in order to save it (or at least make it meaningful for developers). Transparency is key in most good development environments and the JCP JSR process has been left alone for too long. And yet, despite the momentum this JSR initially had, it appears it is falling behind schedule (snipped from here):

SR 306 passed JSR approval balloting unanimously. The current schedule indicates an early draft in December 2006 followed by a public draft in February 2007 . Final approval balloting is slated for May of 2007. InfoQ sat down with Heather VanCura, Manager of the JCP Program Office, and Onno Kluyt, Director of the JCP Program at Sun, and Chair of the JCP to discuss this new JSR and the changes it will be attempting to bring the JCP process.

So a public draft was due in February.... well it's almost June and still nothing. As the solution to many developers ills, it's running a little late.