Printed: Oct 1, 2016
|Mike Grogan||Sun Microsystems, Inc.|
|Bosanac, Dejan||Bothner, Per||Coleman, Don|
|Day Software, Inc.||Flatscher, Rony G.||Niemeyer, Patrick D.|
|Oracle||Pramati Technologies||SAS Institute Inc.|
|Sun Microsystems, Inc.||Williamson, Alan|
Updates to the Original JSR (JSR)
Sundararajan Athijegannathan took over as Maintenance Lead.
E-Mail Address: sundararajan.athijegannathan
- 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)
Section 1. Identification
Submitting Member: Sun Microsystems, Inc
Name of Contact Person: Eduardo Pelegri-Llopart
E-Mail Address: firstname.lastname@example.org
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
Initial Expert Group Membership:
Sun Microsystems, Inc.
* Macromedia, Inc.
* Zend Technologies
* Others TBD
Supporting this JSR:
Apple Computer, Inc.
* Borland Software Corporation
* Macromedia, Inc.
* MySQL AB
* Sun Microsystems, Inc.
* Zend Technologies, Ltd.
Section 2: Request
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.
The target platform is the same as that of Java Servlets, specifically JavaTM 2 Platform, Enterprise Edition (J2EE) 1.4.
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.
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.
The key technology is the Java Servlet specification. The EG will use the PHP scripting language as a concrete example of a scripting language.
If an API is defined to access the Java Servlet objects, we would expect to use a package related to javax.servlet.
No; we expect that this specification will take advantage of the existing JavaTM Servlet model.
We anticipate a fairly quick specification cycle on the order of 12 months, but details are still TBD.
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.
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.
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
* JSR-152, the JavaServer Pages 2.0 specifications
* The PHP5 language description
* TBD Pointers to additional documents
See section 2.1.
Section 4: Additional Information (Optional)
No additional information.