FULL PRODUCT VERSION :
build 1.8.0_161

ADDITIONAL OS VERSION INFORMATION :
Windows 10

A DESCRIPTION OF THE PROBLEM :
When using the  <property name="jnlp.versionEnabled" value="true"/> in a JNLP file with the following naming convention <JAR file name>__V<version number>.jar for binaries, application fails to launch for security reason if JAR files are autosigned.
@see https://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/avoidingUnnecessaryUpdateChecks.html
 
This is always true unless using a specific deployment rule. Indeed, a way for enterprises to continue using JavaWebStart legacy business applications in their environment is to use the Deployment Rule Set feature.
@see https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/deployment_rules.html

Unfortunately the version-based download protocol passes through the security check implemented with this Deployment Rule Set feature.
 


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
A  formal DeploymentRuleSet.jar file must be set and properly signed with a valid certificate from a trusted authority

JAR files referenced in the JNLP sample must be signed with a non valid certificate but defined in the ruleSet.xml 

Disable temporary files in general JAVA settings

The JAR files repository must not support the classical version-based download protocol like when using a JnlpDownloadServlet  
@see https://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/downloadservletguide.html

Instead add <property name="jnlp.versionEnabled" value="true"/> in JNLP file and use the following naming convention <JAR file name>__V<version number>.jar with files in the repository 



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Application should launch normally


ACTUAL -
Application is bloqued by a java security dialog

Note : 
When sniffing TCP request one can see a 6 times try request with URL  http://<site>/<main_jar_href>.jar&version-id=<version_value> for the main jar download
following by http://<site>/<main_jar_href>__V<version_value>.jar

The first 6 times failure looks normal when download protocol with query parameter &version-id is not handled by the repository server (tomcat jetty etc...)

But the last request with version naming convention in the URL should have been called instead when using <property name="jnlp.versionEnabled" value="true"/> 
Strangely, this is what happened for all other JAR download request but the main one. It starts trying download with URL like <JAR file name>__V<version number>.jar, then try with the casual &version-id query parameter one.

Unfortunately it passes through the security check implemented with this Deployment Rule Set feature.

It behaves normally when a valid certificate is used because a specific RuleSet is not required.



REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
If temporary file is enable in JAVA settings the failure occurs only once, then application can be launched normally. It sounds logical since there is no need to perform update check with up-to-date files stored in cache.

Another workaround is to use a JnlpDownloadServlet like to deal with the classical version-based dowload protocol.