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

This is the proposed change log for a Maintenance Review of JSR-056 version 7.0

The proposed new version number will be 7.0

Change 1 - bump the specification version number to 7.0

In the title page (index.html) replace (in 2 places):

Version 6.0.18

with:

Version 7.0

Change 2 - add this revision history to section 0.7:

Add section 0.7.6 as follows:

0.7.6 Changes since release 6.0.18

This is a minor update of the version 6.0.18 specification. The change are described below:

Modify section 5.4.1 to allow signed jnlp files using APPLICATION_TEMPLATE.jnlp
Modify section 7.7 to allow trusted applications to access any PersistenceService entries.
Modify section 3.5, and the DTD in section Appendix C to add attribute “install” to the shortcut element.

This revision introduces the version number (7.0) for the JNLP file and the JNLP API. Version 7.0 is a proper superset of version 1.0, and of version 6.0.18. A JNLP Client implementing this specification must be able to run a JNLP file which requires 1.0, 1.5, 6.0, 6.0.10, 6.0.18, or 7.0; i.e., the spec attribute in the jnlp element is set to any of 1.0, 1.5, 6.0, 6.0.10, 6.0.18 or 7.0.

A complete list of changes for v7.0 can be found at:

{include URL to where this change log is posted on jcp.org}

Change 3 – allow signed jnlp files using APPLICATION_TEMPLATE.JNLP

Replace section 5.4.1 with the following:


A JNLP file can optionally be signed.
A JNLP Client must check if a signed version of the JNLP file or JNLP template exist, and if so, verify that at least one of them match the JNLP file that is used to launch the application. If a match is not found (see below), then the launch must be aborted.
If no signed JNLP file or JNLP template exist, 
then the JNLP file is not signed, and no check needs to be performed.

A JNLP file is signed either by including a copy of it in the signed main JAR file, or by including a matching (see below) template file in the signed main JAR file. 

For the first method, the signed copy must be named: JNLP-INF/APPLICATION.JNLP. 
The APPLICATION.JNLP filename should be generated in upper case, but should be recognized in either upper or lower case.
To match, the signed JNLP file must contain exactly the same XML elements and attributes, with identical values, as the JNLP file used to launch the application. 

For the second method the signed copy must be named JNLP-INF/APPLICATION_TEMPLATE.JNLP.  
The APPLICATION_TEMPLATE.JNLP filename should be generated in upper case, but should be recognized in either upper or lower case.
The template (APPLICATION_TEMPLATE.JNLP) may have fields for CDATA arguments or values denoted as "*".  The signed template must have exactly the 
same elements and arguments as the JNLP file used to launch the app, and the value of each element and attribute must "match" as described below.

An element value or attribute value matches if either the value in the template is identical to the value in the JNLP file used to launch the app, or all of the following are true:
1.) The element or attribute is defined (in the DTD in appendix C) to be of type CDATA (for attributes) or #PCDATA (for elements).
2.) The element or attribute value in the signed template is "*"
3.) The element or attribute value is not blacklisted or restricted by the JNLP Client.

It is expected that a JNLP Client will blacklist (or restrict) certain jnlp elements and argument values such as "java-vm-args" or property "name" and "value" 
to maintain security. The exact list is up to the individual JNLP Client implementations.

As an example, the following APPLICATION_TEMPLATE.JNLP could be used to host an application on various hosts with different icons:

<?xml version="1.0" encoding="UTF-8"?>
  <jnlp codebase="*">
    <information>
      <title>Draw!</title>
      <vendor>My Web Company</vendor>
      <icon href="*"/>
      <offline-allowed/>
    </information>
    <resources>
      <java version="1.3+"/>
      <jar href="draw.jar"/>
    </resources>
    <application-desc main-class="com.mysite.Draw"/>
  </jnlp>

An Application with the above contents in JNLP-INF/APPLICATION_TEMPLATE.JNLP in it's main jar could be moved from one server to another, or could change it's icon without resigning the main jar.

Change 4 - allow trusted applications to access any PersistenceService entries.

Modify the third paragraph of section 7.7 from:

Each entry in the persistent data store is stored on the local system, indexed by a URL, i.e, using a URL as a key. 
This provides a similar hierarchical structure as a traditional file system. 
An application is only allowed to access data stored with a URL (i.e., key) that is based on its codebase. 
The URL must follow the directory structure of the codebase for a particular application. 
For example, given the codebase, http://www.mysite.com/apps/App1/, the application would be allowed to access data at the associated URLs:
To: 
Each entry in the persistent data store is stored on the local system, indexed by a URL, i.e, using a URL as a key. 
This provides a similar hierarchical structure as a traditional file system. 
An untrusted application is only allowed to access data stored with a URL (i.e., key) that is based on its codebase. 
The URL must follow the directory structure of the codebase for a particular untrusted application. 
For example, given the codebase, http://www.mysite.com/apps/App1/, the untrusted application would be allowed to access data at the associated URLs:

Change 5 – Add “install” arg to shortcut element in jnlp.

1.) Change the example (in top of section 3.5) from:

      <shortcut online="false">
To: 
      <shortcut online="false" install="false">

2.) Add after definition of online attribute (in section 3.5):

install attribute: The optional install attribute can be used in a shortcut element to describe the application's preference for being considered "installed". 
If the value is "true" the application prefers to be considered installed. 
The default value of the install attribute is "false".

It is up to the JNLP Client to determine how and if applications are treated differently when install="true", and this may vary from platform to platform.  
For example, a JNLP client on a Windows platforms may add the application to the Windows Add/Remove menu only when install="true" is specified, while making no distinction on unix platforms.

3.) Add (after "offline" attribute in the DTD in Appendix C) the following:

    <!--
    The install attribute of the shortcut element describes an application's preferences for being considered installed
    --> 

    <!ATTLIST shortcut install (true | false) "false">