• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Specification Leads
	Andrew Herrick	Oracle
	Dmitrii Markov	Oracle
Expert Group
	Hewlett-Packard : Bob Naugle	Oracle : Andrew Herrick	Oracle : Dmitrii Markov
	Oracle : Steve Tom	Rix, Thomas : Thomas Rix	Silverstream Software : Alex Rosen
	Sitraka : Edward Lycklama
Contributors

Updates to the Original JSR
The following information has been updated from the original proposal.

2021.11.05:
Dmitrii Markov has assumed the role of Maintenance Lead for JSR 56.

Maintenance Lead Member: Oracle

Name of Maintenance Lead: Dmitrii Markov

E-Mail Address: dmitry.markov@oracle.com

Telephone Number: -

Fax Number: -

Original Java Specification Request (JSR)

Identification | Request | Contributions

Original Summary: A specification of protocols and APIs that will enable Java^TM applications to be deployed on the Web. An implementation of this specification will support Web deployed applications by enabling distributing an application on a Web server and launching the application from any Web browser.

Section 1. Identification

Submitting Participant: Sun Microsystems, Inc.

Name of Contact Person: Rene Schmidt

E-Mail Address: rene.schmidt@eng.sun.com

Telephone Number: (408) 863-3395

Fax Number: (650) 856-2114

Section 2: Request

2.1 Please describe the proposed Specification:

A specification of protocols and APIs that will enable Java applications to be deployed on the web. An implementation of this specification will support web deployed applications by enabling distributing an application on a web server and launching the application from a web browser. The components of this infrastructure are likely to include:

• A standard encoding of the information needed to launch a Java application whose components are hosted by one or more web servers. Some examples of application launch information are: the version of the Java Runtime Environment (JRE) required by the application, the URLs and version of the application's jar files, and the name of the application's main class.

• A launcher application, such as a browser helper application, that interprets the above encoding and launches Java based applications. The launcher application will be responsible for starting the correct JRE, loading/caching the application jar files, and starting the application itself. Browser helper applications are associated with a mime type and default file extension. This specification will define a mime type and default extension for the above encoding.

• A standard application execution environment for web deployed applications. The environment could consist of a security model such as the sandbox model, pre-configured proxy settings, support for showing a URL in the default browser. This is similar to (but not limited to) what is provided for Java Applets, e.g., the AppletContext.showDocument.

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

Java 2 Standard Edition.

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

One important element of a successful application deployment is distribution: getting the initial version of the application to the user, and then delivering newer versions as they become available. Presently the Java platform does not provide any explicit support for application deployment.

Applets already have these features; the goal of this specification is to extend support for web deployment to applications. An application runs independently of the browser in its own window and process, e.g., its life time is not constrained by the lifetime of the web page it is launched from, it could have a look and feel like a traditional (native) application, could be launched independently from a browser through the native platforms preferred mechanism, and be required to run on a specific version of the JRE.

The proposed specification will simplify the deployment of Java-based applications by making it possible for developers to deliver them with a web server and for users to launch them by clicking on a link in an HTML document.

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

No existing specification addresses the issue of launching an application from a web-browser or delivering an application on a web-server.

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

The Java 2 SE platform includes support for loading classes from a server specified by a URL, running code in a secure environment (sandbox), and code signing. Support for incremental updates could be based on existing work submitted to the W3C, such as the HTTP Distribution and Replication Protocol (HTTP DRP), and the Generic Diff Format Specification (GDIFF).

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

javax.jnlp

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

The browser helper application will include OS dependent (C language) code for spawning a Java VM process and for very limited communication with the spawned process.

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

No. The existing applet "sandbox" security model will be reused for web deployed applications.

2.9 Are there any internationalization or localization issues?

The protocols and APIs are likly to be language neutral. However, the reference implementation, a browser helper application, will include a modest GUI for informing the user of progress in loading and starting the Java application. The messages presented in the GUI will have to be localized.

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.

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.

An prototype implementation is under development along with a draft specification at the Java Software division at Sun Microsystems, Inc. More information is available by contacting Ren?W. Schmidt at rene.schmidt@eng.sun.com.

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

The working specification of the prototype could be used as the basis of a draft specification. Similarly the prototype implementation could evolve into the reference implementation.