The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 241

This JSR has been Dormant
Reason: The Specification Lead chose to list this JSR as dormant in April 2012.

Updates to the Original JSR

The following information has been updated from the original proposal.

Specification Lead: VMWare

E-Mail Address: glaforge@vmware.com

Telephone Number: -

Fax Number: -

2011年03月24日:

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java 2 Platform, Standard Edition 5, and subsequent versions of Java SE. (desktop and server)

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

This technology is not targeted for inclusion in any platform edition, although as Groovy compiles to regular bytecode for standard JVMs, Groovy can and is used on both Java SE and Java EE environments.

2.5 What need of the Java community will be addressed by the proposed specification?

Currently the Java community does not have a standard JCP-sanctioned agile programming language for writing scripts and applications that interoperate with the entire Java SE platform.

Groovy makes writing scripts and applications for the Java Virtual Machine fast and easy. Groovy includes language features found in Python, Ruby, and Smalltalk, but uses syntax natural to developers that use the Java programming language. Because Groovy is based on Java SE and its grammar derives from the Java 5 language grammar, applications written in Groovy can use the full complement of Java SE APIs, and work seamlessly with other packages and applications written in the Java programming language.

Groovy is a complement of the Java programming language, not a replacement of it. Where the Java programming language is exacting, Groovy is expedient. Where the Java programming language is extensive, Groovy is convenient. Using Groovy, developers can take advantage of rapid application development features like those in Python and Ruby for quick application prototyping and development of scripts for the Java Virtual Machine. In addition, Groovy is useful as a shell-level scripting language that can execute other Groovy scripts as well as native operating-system scripts.

Groovy is a very "learnable" programming language that makes adoption of the Java platform by developers go more quickly and smoothly. Groovy incorporates syntax similar to the Java programming language. That developers can use familiar Java-like syntax in Groovy source code makes learning of Groovy easier, and facilitates transition from either language to the other. Groovy can be a low-threshold language for developers new to the Java platform as well as a productivity-enhancing tool for experienced Java developers.

2.6 Why isn't this need met by existing specifications?

There is currently no standard dynamic scripting language specifically designed to take full advantage of the Java platform. We have considered JSR 223, and believe that while 223 is in the same problem domain, scripting, the scope and purpose is completely different than this JSR, and there is no overlap between the work of the two EGs. In addition, Groovy provides an implementation of the JSR 233 APIs, so that developers wishing to integrate the Groovy language inside their Java applications can easily do so, by using this implementation.

2.7 Please give a short description of the underlying technology or technologies:

Like the Java programming language, Groovy defines a programming language used to develop applications for the Java Virtual Machine. It is compiled into standard Java byte code that conforms to the Java Virtual Machine Specification. To the JVM, there is no difference between a class file compiled from the Groovy language and one compiled from the Java programming language.

To parse the Groovy programs, the Antlr parser generator is used, and for the generation of the bytecode, the ASM library is being used.

2.13 Please describe the anticipated schedule for the development of this specification.

This specification will target the version 2.0 of the Groovy programming language. The current plan of the Open Source Groovy project development team is to release Groovy 2.0 by the end of the year 2012, and thus, we intend to release the final version of the specification by that timeframe. Before that, we're looking forward submitting an Early Draft for review around mid 2012.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

Our plan is to run this JSR as an open source project, with open mail lists for the public and open access to the codebase. Further, public IRC chats, a public Wiki, and face-to-face meetings open to all interested parties will also be used to promote transparency and open communication.

That has been the practice for the Groovy open source project to this point, and the spec lead, contact and expert group members are all experienced participants and managers of successful open source projects.

---

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Geir Magnusson Jr.

Name of Contact Person: Richard Monson-Haefel

E-Mail Address: Richard@Monson-Haefel.com

Telephone Number: +1 612 822 1400

Fax Number:

Specification Lead: James Strachan, Richard Monson-Haefel

E-Mail Address: james_strachan@yahoo.co.uk, Richard@Monson-Haefel.com

Telephone Number: +1 612 822 1400

Fax Number:

Initial Expert Group Membership:

James Strachan
Richard Monson-Haefel
Geir Magnusson, Jr.

Supporting this JSR:

Apache Software Foundation
BEA
Richard Monson-Haefel
Thought Works Inc

Section 2: Request

2.1 Please describe the proposed Specification:

This specification will standardize the Groovy programming language so that vendors can provide compliant implementations and developers will have a sanctioned scripting language they can use on the Java^TM platform.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java 2 Platform, Standard Edition 1.4, and subsequent versions of J2SE. (desktop and server)

Note that this information has been updated from this original proposal.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

This technology is not targeted for inclusion in any platform edition, although as Groovy compiles to regular bytecode for standard JVMs, Groovy can and is used on both J2SE and J2EE environments.

Note that this information has been updated since this original proposal.

2.4 Should this JSR be voted on by both Executive Committees?

No

2.5 What need of the Java community will be addressed by the proposed specification?

Currently the Java community does not have a standard JCP-sanctioned agile programming language for writing scripts and applications that interoperate with the entire J2SE platform.

Groovy makes writing scripts and applications for the Java Virtual Machine fast and easy. Groovy includes language features found in Python, Ruby, and Smalltalk, but uses syntax natural to developers that use the Java programming language. Because Groovy is based on J2SE, applications written in Groovy can use the full complement of J2SE APIs, and work seamlessly with other packages and applications written in the Java programming language.

Groovy is a complement of the Java programming language, not a replacement of it. Where the Java programming language is exacting, Groovy is expedient. Where the Java programming language is extensive, Groovy is convenient. Using Groovy, developers can take advantage of rapid application development features like those in Python and Ruby for quick application prototyping and development of scripts for the Java Virtual Machine. In addition, Groovy is useful as a shell-level scripting language that can execute other Groovy scripts as well as native operating-system scripts.

Groovy is a very "learnable" programming language that makes adoption of the Java platform by developers go more quickly and smoothly. Groovy incorporates syntax similar to the Java programming language. That developers can use familiar Java-like syntax in Groovy source code makes learning of Groovy easier, and facilitates transition from either language to the other. Groovy can be a low-threshold language for developers new to the Java platform as well as a productivity-enhancing tool for experienced Java developers.

Note that this information has been updated since this original proposal.

2.6 Why isn't this need met by existing specifications?

There is currently no standard dynamic scripting language specifically designed to take full advantage of the Java platform. We have considered JSR 223, and believe that while 223 is in the same problem domain, scripting, the scope and purpose is completely different than this JSR, and there is no overlap between the work of the two EGs.

Note that this information has been updated since this original proposal.

2.7 Please give a short description of the underlying technology or technologies:

Like the Java programming language, Groovy defines a programming language used to develop applications for the Java Virtual Machine. It is compiled into standard Java byte code that conforms to the Java Virtual Machine Specification. To the JVM, there is no difference between a class file compiled from the Groovy language and one compiled from the Java programming language.

Note that this information has been updated since this original proposal.

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

groovy.*

2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No

2.10 Are there any security issues that cannot be addressed by the current security model?

No

2.11 Are there any internationalization or localization issues?

No

2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No

2.13 Please describe the anticipated schedule for the development of this specification.

Early Draft Review before the end of 2004.

Note that this information has been updated since this original proposal.

2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.

The working group will use a variety of communication methods to develop the specifications including, but not limited to: phone conferences, e-mail, occasional face-to-face meetings, IIRC Chat, and Wiki. This JSR will be run in the same way as a conventional Open Source project, with an open mailing list for the entire Java community.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

Our plan is to run this JSR as an open source project, with open mail lists for the public and open access to the codebase. Further, public IRC chats, a public Wiki, and face-to-face meetings open to all interested parties will also be used to promote transparency and open communication.

That has been the practice for the Groovy open source project to this point, and the spec lead, contact and expert group members are all experienced participants and managers of successful open source projects. Their experience includes well-known projects such as velocity, dom4j, drools, classworlds, maven, jelly, jexl, and many others.

Note that this information has been updated since this original proposal.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI and TCK will be delivered stand-alone.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

The RI and TCK will be available free of charge in both binary and source forms. The RI and TCK will be licensed under a business-friendly, Open Source license similar to the BSD or Apache Software License that include language supporting required limitations for RIs and TCKs. Please see

http://www.apache.org/licenses/proposed/JSR-LICENSE-2.0.txt

and

http://www.apache.org/licenses/proposed/TCK-LICENSE-2.0.txt

for examples on how the necessary compatibility-enforcing requirements would be addressed.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

The Groovy language specification will be based on work in progress on the Groovy open source project at http://groovy.codehaus.org/

3.2 Explanation of how these items might be used as a starting point for the work.

The Groovy open source project ( http://groovy.codehaus.org/) will produce the RI and TCK for the Groovy JSR.