Welcome to the April edition of the JCP column! Each month you can read about the Java Community Process: newly submitted JSRs, new draft specs, Java APIs that were finalized, and other news from the JCP. In this month's column I'm focusing mostly on one new JSR.

Java Is a Platform
The above is an often-heard description when talking about this technology. While many Java developers may first think of the Java programming language, what makes this technology successful is not only the niceties of the programming language but the richness of the class libraries and the presence of a virtual machine that can run anything as long as "anything" consists of valid bytecodes: the platform aspect. The virtual machine doesn't worry much about how those bytecodes that it's asked to execute came about. From very early on in the life of the Java technology, there have been efforts to run programs written in other programming languages in the Java runtime environment.

Nowadays most Ada programs are compiled to Java bytecode. You can compile COBOL to run on a Java runtime environment if you so wish. More recently, there have been other efforts related to new languages such as Ruby and Python where developers have created Java versions, respectively, JRuby and Jython. The JCP recognized the use of scripting languages in the J2EE technology environment last summer and is currently working on a JSR to provide scripting languages, such as PHP access to Java objects. This is JSR 223. Now, there is a new JSR that explores an altogether new angle.

A JSR for the Groovy Programming Language
Submitted by Geir Magnusson and Richard Monson-Haefel, and to be led by James Strachan and Richard, JSR 241 is on the JSR Review Ballot. The goal for this JSR is to standardize the specification for the Groovy programming language so that platform implementers, tool vendors, and others can provide compliant implementations for their developers to use with the Java platform. Groovy is based on J2SE 1.4. In the words of the submitters: "Groovy is a complement to the Java programming language. Where the Java programming language is exacting, Groovy is expedient. Where the Java programming language is extensive, Groovy is convenient."

I asked James Strachan via e-mail how Groovy came to be. James explained that last summer he observed that several Java developers were intrigued by features found in new languages like Ruby and Python. These are great scripting languages to write the glue that holds enterprise applications together. While they are very useful, James felt that what was missing was a language that provides access to the J2SE and J2EE APIs for this purpose. That is the API set that the developers are familiar with, and Java developers will want to retain their investment in learning these APIs and the development tools that support them. And so Groovy was born. It began as an experiment to see whether a Ruby-like language could be compiled to bytecodes and use the Java runtime environment without wrapping Java objects but it quickly gained a lot of momentum, and now Groovy has many of the typical scripting language features in a very Java-like syntax.]

To check out the JSR, go to http://jcp.org/jsr/detail/241.jsp. To learn more about the Groovy programming language, visit http://groovy.codehaus.org.

And in Other News
For this month's edition of the JCP column I'd like to draw your attention to two JSRs that recently went final. JSR 127, the JavaServer Faces specification, is final. This specification simplifies the creation and maintenance of user interfaces for server-side applications. It provides a richer graphical composition than is possible with just servlets or JSPs. And to close, the J2ME Web services specification, or JSR 172, has also completed its JCP process. It delivers two optional packages so that nontraditional devices can process XML and make use of and interoperate with Web services.

That's it for this month. I'm very interested in your feedback. Please e-mail me with your comments, questions, and suggestions.