Evolving the JCP Process - JSR 306 Passes JSR Approval Ballot

Posted by Scott Delap on Oct 03, 2006 10:28 AM

Community

Java

Topics

JCP Standards

Tags

JCP

The Java Community Process is scheduled to be revised as a result of JSR 306, Towards a new version of the JCP. The JSR proposes a number of changes for the JSPA and JCP process. In terms of streamlining the process:

• further improve the transparency of the process
  
• further optimize the average duration of JSRs
  
• how can individuals best participate in the process and in terms of fundamental changes
  
• allowing non-Java implementations of a JSR's specification
  
• ability to create liaison relationships with other standards organizations
  
• easing the migration of pre-existing technology towards an agreed upon standard
  
• the availability of TCK and associated licensing information upon completion of a JSR
  

JSR 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.

One of the main goals of the next JCP revision is to streamline the JCP process. Included with this goal is a discussion in regards to transparency. The JCP Program is seeking to refine the balance between confidentiality/IP rights and a more open process that allows visibility and access to JCP conversations. Speeding up overall JSR duration is also being targeted.

Another consideration in terms of streamlining is how individuals participate in the JCP process. Kluyt commented:

Originally the participation of corporations was considered much more than individuals. Many individuals currently find signing up as JCP members a daunting task. As the industry has changed in recent years however with the advent of movements such as open source, individuals are able to play a much more influential role in how standards are developed. Developers are starting to expect the same patterns in developing standards and API as they do when writing software itself.

Another major direction of JSR 306 is to consider a number of fundamental changes to the JCP. The need is arising with JSR's covering such things as web services to allow non Java JSR implementations. This is something the current process was not built to handle. The JSR also is seeking to introduce the ability to create liaison relationships with other standards organizations. Kluyt elaborated:

There are two aspects to liaison relationships. The first is ceremonial as a way to indicate good working relationships between standards bodies. The second is practical in terms of the expert groups needing to talk to one another to solve problems. A good example is Java's integration with Corba standardized by the Object Management Group.

The conversation then shifted to enhancing the JSR to more easily migrate existing technologies to an agreed upon standard. The main issue is what to do with the roadmap for an existing product while attempting to standardize it through the JCP. At times it is difficult to continue enhancement while respecting IP issues. Kluyt explained that today companies follow one of three methods:

The first route taken by some companies to to wall off their engineers responsible for enhancing the product from the engineers working with the JCP to standardize the technology. This has the downfall of being expensive however. Another option is to simply put the product roadmap on hold until the JSR is finished. A third option is to simply not start a JSR. What we want to do is see if we can make the process easier increasing the pool of IP while providing an environment that market leaders want to work in.

Finally it was asked if any of the changes up for discussion were a result of Java's move towards open source. Kluyt indicated no and that nothing with the current JCP prevents open sourcing Java citing Java EE as an example. However the changes slated will likely have beneficial side effects.

1. Back to top

   heyy

   May 6, 2008 5:17 PM by murat bektas

   At times it is difficult to continue enhancement while respecting IP issues. Kluyt explained that today companies follow one of three methods: ttnet search engine

   Reply

2. Back to top

   Heyy

   May 9, 2008 10:33 AM by mdsmd dmdmsds

   Finally it was asked if any of the changes up for discussion were a result of Java's move towards open source. Kluyt indicated no and that nothing with the current JCP prevents open sourcing Java citing Java EE as an example. However the changes slated will likely have beneficial side effects.game cheats

   Reply

• Older >