 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 223: Scripting for the JavaTM Platform
This JSR has been Withdrawn
2016.10.03:
2016.08.28:
E-Mail Address: sundararajan.athijegannathan 2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.- The Reference Implementation (RI) will be delivered in binary form free of charge.- This JSR will be included in the Java SE 6 platform release. The JSR TCK will thus be licensed as part of the Java SE 6 TCK under the terms described in the JSR-270 business terms. - The RI source will be available under the Java Distribution License (JDL) and Java Research License (JRL). Licensing of the RI is not required for the licensing of the TCK. - The JSR 223 TCK source will be made available at no extra charge to J2EE licensees. - The JSR 223 TCK will be licensed at no charge, without support or any trademark license rights. 2004.11.15: The Spec Lead and Expert Group changed the name of this request from "Scripting Pages in JavaTM Web Applications" to "Scripting for the JavaTM Platform".
Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Sun Microsystems, Inc Name of Contact Person: Eduardo Pelegri-Llopart E-Mail Address: pelegri@sun.com Telephone Number: +1 408 276 7234 Fax Number: +1 408 276 7191 Specification Lead: Mike Grogan E-Mail Address: Mike.Grogan@sun.com Telephone Number: +1 425 818 1166 Fax Number: Initial Expert Group Membership: *
Sun Microsystems, Inc. Supporting this JSR:
*
Apple Computer, Inc. Section 2: Request
2.1 Please describe the proposed Specification:This specification will introduce the basic technical background to bridge the scripting and the Java community. The specification is concerned with how to write and package Java classes that will be accessible from different scripting engines. The Java classes may be part of a Servlet application or may be in a standard Java VM. The JavaTM Servlet specification (Servlet 2.4, JSR-154, is the latest version) defines the set of core abstractions that are used by Java developer writing Web Applications. These abstractions include those of Web Application context, session, request, response, etc. When Java developers write Web Applications, they write classes that interact with these objects in well defined security, resource and class loader contexts. The proposed specification will describe which of these Java objects will be exposed to pages written in other scripting languages. The specification will be grounded on at least one concrete scripting language example, PHP, but the concepts will remain independent of the scripting language and, if at all possible, the EG will also explore the bindings to at least another scripting language. The EG will also explore the case where the Java objects may not be associated with a specific Web application but may just be instantiated in a Java Virtual Machine. The specification may include a Java API that can be used, possibly through JNI, by an scripting language engine to access the desired Java objects. This specification will describe how it is possible to bundle scripting pages into a WAR file, either stand-alone, or as part of an EAR. The specification will describe the different implications for security, resource, and class loader contexts both in the case of stand-alone WARs and as part of an EAR. The EG will also consider whether it is appropriate to deliver scripting and Java code outside of a WAR. The specification may describe how scripting pages can be denoted as such in a WAR in a manner that is easily identified using only the machinery in any standard Servlet container. For instance, it may be appropriate to define a standard Servlet per scripting language; this would allow a WAR to indicate in its web.xml descriptor which files are in a given scripting language. The EG may decide that a container that follows this JSR can use a different mechanism, like a default extension value, to determine that a page is an scripting language known to the container. The EG working on this specification will deliver the specific bindings of these ideas to the PHP scripting language, but the EG will ensure that the concepts can be applied to other scripting languages. It is unclear at this time whether the PHP bindings will be normative or not, but we believe the bindings need to be explored in detail to ensure that the concepts are well grounded. We expect the Reference Implementation to be built on top of the Servlet and JSP reference implementations and to include at least the PHP binding. We expect this EG to be grounded in the needs of both the scripting community and the Java community. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The target platform is the same as that of Java Servlets, specifically JavaTM 2 Platform, Enterprise Edition (J2EE) 1.4. 2.3 What need of the Java community will be addressed by the proposed specification?Companies and groups in the Java Community have web applications written in a variety of programming and scripting languages. These organizations would like to take advantage of the benefits of the Java technology in as many of these situations as possible. This specification will allow these organizations to bridge a number of scripting languages to the rest of the Java 2 Platform, Standard Edition and to the Java 2 Platform, Enterprise Edition. 2.4 Why isn't this need met by existing specifications?Java Servlets define the basic concepts for a Web Application. We expect this specification to build strongly on the Java Servlet specification by spelling out the assumptions that are shared among all scripting languages. The existing technologies can address some of applications today, when certain requirements are satisfied. For example, if the scripting engine is written in Java, then a WAR can be written including the implementation of the scripting engine, web.xml can explicitly require the use of that scripting engine and the whole application can be packaged into a WAR. This specification will enable a more flexible mechanism that does not impose as many implementation constraints and may provide more convenient packagings. 2.5 Please give a short description of the underlying technology or technologies:The key technology is the Java Servlet specification. The EG will use the PHP scripting language as a concrete example of a scripting language. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)If an API is defined to access the Java Servlet objects, we would expect to use a package related to javax.servlet. 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.8 Are there any security issues that cannot be addressed by the current security model?No; we expect that this specification will take advantage of the existing JavaTM Servlet model. 2.9 Are there any internationalization or localization issues?No 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.11 Please describe the anticipated schedule for the development of this specification.We anticipate a fairly quick specification cycle on the order of 12 months, but details are still TBD. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.The Expert Group will interact using the private e-mail alias and web site provided by the JCP's PMO in addition to conference calls and face-to-face meetings as appropriate. Expert Group members have strong ties into the Java and Web Services communities and will call on domain experts as needed. 2.13 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.Stand-alone. We expect the Reference Implementation to be built on top of the Servlet and JSP reference implementations and to include at least the PHP binding. 2.14 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.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.Planned Business Terms for this JSR: The specification will be released in accordance with standard terms as specified by the JCP process. The reference implementation (RI) will be delivered in binary form free of charge from http://java.sun.com. Licensing details are expected to be under the Binary Code License (BCL). The source for the reference implementation is expected to be delivered via the Sun Community Source License under standard SCSL terms & licensing and available free of charge to all Java 2 platform, Enterprise Edition and Java 2 platform, Standard Edition licensees. The TCK will be made available free of charge to all J2SE and J2EE licensees. The TCK will be offered for license at no charge, without support or any trademark license rights, to qualified not-for-profit entities (including not-for-profit) academic institutions) and qualified individuals engaged in efforts to create compatible implementations of the Specification. 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.
* JSR-152, the JavaServer Pages 2.0 specifications * The PHP5 language description * TBD Pointers to additional documents 3.2 Explanation of how these items might be used as a starting point for the work.See section 2.1. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.No additional information. |
