FULL PRODUCT VERSION :
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7600]

A DESCRIPTION OF THE PROBLEM :
Since the Java 7u51 update we've been having some issues with deploying our Webstart application, and Nadia suggested I contact you.

In order to demonstrate the issue, I created a very small test application. The goal is to start this without any unnecessary warnings.
The application contains a single jar, with a single class with an empty main method. In its manifest it requests all-permissions, and there is a APPLICATION_TEMPLATE.JNLP embedded as well.
The jnlp and jar are deployed via the JnlpDownloadServlet. The jar is signed by a valid certificate (not self-signed).

I tried two variations. One uses versioned resources ( <jar href="versioned.jar" main="true" version="1.0" /> ) while the other does not ( <jar href="unversioned.jar" main="true" /> ).

If I start the unversioned one with a simple link to the JNLP page, I get the warning: "This application will run with unrestricted access....".
The warning is what I expect, but I do not have an option to permanently accept. If I start the application again, I get the same warning.

If I start the versioned one, I can accept permanently which is good. But now there is another warning: "This application will be blocked in a futujre Java security update because the JAR file manifest does not contain the Permissions attribute. ...  " 
This is not blocking at this moment, but I do not want to run the risk that in 3 months time my application does not start anymore (as the warning indicates might happen).

If I add the webstart deployment toolkit into the mix, things change for the unversioned application: the Permissions warning is gone and I can permanently accept the application. But this does not work for the versioned application, and I don't really want to depend on the deployment toolkit (it should work by simply starting a download jnlp with javaws too).




REGRESSION.  Last worked in version 7u45

ADDITIONAL REGRESSION INFORMATION: 
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Manifest contains:
Manifest-Version: 1.0
Permissions: all-permissions
Codebase: *

JNLP-INF/APPLICATION_TEMPLATE.JNLP:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="*" spec="1.0+">
    <information>
        <vendor>...</vendor>
        <title>Test</title>
    </information>
    <security>
        <all-permissions/>
    </security>
    <resources>
        <jar href="versioned.jar" main="true" version="1.0" />
		<property name="jnlp.versionEnabled" value="true"/>
    </resources>
    <application-desc main-class="Main">
    </application-desc>
</jnlp>

JNLP file:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="$$codebase" spec="1.0+">
    <information>
        <vendor>...</vendor>
        <title>Test</title>
    </information>
    <security>
        <all-permissions/>
    </security>
    <resources>
        <jar href="versioned.jar" main="true" version="1.0" />
		<property name="jnlp.versionEnabled" value="true"/>
    </resources>
    <application-desc main-class="Main">
    </application-desc>
</jnlp>

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
- Use unversioned resources
- Disable the webstart cache