JDK-8170646 : JNLP fails to get loaded with old javaws when multiple jres (jre9 and jre8u111) installed
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u111
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-12-02
  • Updated: 2017-11-29
  • Resolved: 2017-01-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8u131 b03Fixed
Related Reports
Duplicate :  
JDK-8170452 - javaws application could not be launched on command line with "javaws jnlp_url" for JRE8
Relates :  
JDK-8003984 - Allow relaunch between 32 / 64 bit versions in Java Web Start when you have latest versions of both
Description
ENV: win7/x86/jre9-b146;ubuntu16.04/x86/jre9-b146

Steps to reproduce:
1. Install JRE9: jre9-b146
2. Install an older JRE: jre8u111b14
3. Add "http://sqeweb.us.oracle.com" to ESL
4. Load jnlp with old jre: for example, on windows, run: C:\Program Files\Java\jre1.8.0_111\bin\javaws http://sqeweb.us.oracle.com/net/scanas415/export/deployment/crystal/DO_NOT_REMOVE_ME/jrebug/disableJavaManual_NonMultipleJRE/jnlp/testJavawsLaunchOnCLI.jnlp
5. A security dialog will show up. Accept it
6. If  the application could not be launched and there's no response after accepting the security dialog, this bug is reproduced. 
I can see the following exception from trace:
ExitException[ 0]
	at com.sun.javaws.Launcher.relaunch(Unknown Source)
	at com.sun.javaws.Launcher.prepareResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
	at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
	at com.sun.javaws.Launcher.launch(Unknown Source)
	at com.sun.javaws.Main.launchApp(Unknown Source)
	at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
	at com.sun.javaws.Main.access$000(Unknown Source)
	at com.sun.javaws.Main$1.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
basic: Exiting

See attachment for full trace.

Note: 1. jnlp can get loaded with old jre when jre9-b46 and jre8u111-b14 installed
2. jnlp can get loaded if only jre8u111-b14 installed
3. jnlp can get loaded from jre9 home when jre9-b46 and jre8u111-b14 installed:
 C:\Program Files\Java\jre-9\bin\javaws http://sqeweb.us.oracle.com/net/scanas415/export/deployment/crystal/DO_NOT_REMOVE_ME/jrebug/disableJavaManual_NonMultipleJRE/jnlp/testJavawsLaunchOnCLI.jnlp
Comments
Verified with jre8u131-b07 on win7/x86
22-02-2017
ILW=HMM=P2
10-01-2017
17_02-critical-request justification: - Fix for Release : 8u131 - Justification : low-risk fix addresses failure in JNLP when specifying version to existing, secure 8u JWS with JDK9 - Risk Analysis : low - Webrev : https://java.se.oracle.com/code/cru/CR-JDK8UDEV-415 - Testing (done/to-be-done) : 8u-dev/PIT, 8u-cpu promotion - Back ports (done/to-be-done) : 8u131 only (9-na, 6/7-na) - FX Impact : NA
10-01-2017
There's the same issue happened on oel6.4-x86-jre8u121b13-32bit-ff45 RULE "disableJavaManual_MultipleJREScenarios/testDowngradeAwareNotUninstallEnable" any any
15-12-2016
Crucible review: https://java.se.oracle.com/code/cru/CR-JDK8UDEV-415
13-12-2016
It is not expected that you can run java web start from JDK8 when JDK9 is installed. a very simple app would try to relaunch into JRE9 (the latest available jre) in that case relaunch would completely fail, since deployment code in JDK8 would not know correct args to launch JRE9. now in this case, you have jnlp file specifically asking for jre 8u111, this shows the dialog saying 8u111 is not installed. as above, you cannot click on run with the latest, because that will then re-launch into JDK9, which this deployment code (8u111) does not know how to do (and shouldn't) That this worked using jdk9b46 is meaningless, since that was before modularization, and launching into jre 9 was no diferent than launching into older release. In any case this is not a bug in JDK9, since no code from JDK9 is ever run. There appears to be 2 bugs here in 8u111 1.) Why show the version-not-available dialog ? - the reason is this second testcase has: <java version="1.8.0_111"/> this is an invalid platform version specification. Turning on tracing you can see: basic: WARNING - specified JRE version, 1.8.0_111 is invalid platform version So this is a bug in the testcase. 2.) Why even consider 9+ as valid versions ? in JDK9 in JREInfo.isValid() we have: if ((isOsInfoMatch(_nativePlatform)) && (getProduct() != null) && (platform != null) && platform.compareTo("1.6") >=0 && platform.compareTo("9") <= 0 && ((new File(getPath())).exists())) { return true; } in other words, platform must be at least JDK6 and not greater than JDK9 - we cannot use JDK10 ! in 8u we have: if ((isOsInfoMatch(_nativePlatform)) && (getProduct() != null) && (getPlatform() != null) && (getPlatform().compareTo("1.6") >= 0) && ((new File(getPath())).exists())) { return true; in other words - nothing to prevent considering later versions. note also that the above code prohibits relaunching into 1.5.0! this was incorrectly included in the backport of JDK-8003984. In the backport the compare to 1.6 should have been 1.5 The launching of later versions was fixed in JDK9 as JDK-8138662 in summary - there is no bug in JDK9 and the bug in 8u is in the implementation of JREInfo.isValid() (allowing 1.6.0+ instead of 1.5.0 thru 1.8.0)
12-12-2016
in the test example, the jnlp requests version 1.2+ (latest installed version). when run with 1.8.0_XXX, it will crash on the relaunch trying to run JDK9. it worked back with JDK9 b46, because that was back before jdk 9 was modular, and could be launched using the same commands as were used to launch all previous releases. we need the checks mentioned above in JREInfo.isValid() to block JDK9+ from being valid to launch with JDK8 deployment code. same problem with simple app: ./javaws http://oklahoma.us.oracle.com/www/tests/sandbox/helloa.jnlp
12-12-2016
[~herrick] [~jijising] I just tried all above multi JRE scenarios provided by Jitender. My env is: win7/x86/IE11/jre9-b147;old secure jre 8u121-b12;old insecure jre 8u101-b13. Here are the results: 1. The following scenarios work fine for applet/jnlp-applet/jnlp: 1) a); 1) b); 2) b); 3) 2. The scenario 2) a) seems has some issues. 1) If app is on ESL, it works fine for applet/jnlp-applet/jnlp: it will show dialog asking if you want to run with older insecure version or run with latest. See attachment ON-ESL.png. 2) If app is not on ESL, applet and jnlp will behave differently. applet will show dialog saying use latest (JDK9) or block. See attachment NOT-ON-ESL-APPLET.png. jnlp or jnlp based applet will show dialog asking if you want to run with older insecure version or run with latest. See attachment NOT-ON-ESL-JNLP.png. Filed a bug JDK-8170956 for this issue.
09-12-2016
CPU17_01-defer-request justification: Not a release-blocking issue. Impact limited to 8 & 9 coexistence.
08-12-2016
Open a separate bug against 2) If app is not on ESL, applet and jnlp will behave differently.
08-12-2016
SQE needs clarification on multi JRE behavior with JDK9 1) Secure version of older JRE e.g. 8u121 installed on machine along with JRE9 a) App/Applet requesting older version of installed secure JRE using java_version param or version attribute - Are we going to launch with JRE9 without showing SSV dialog? b) App/Applet requesting older version of installed secure JRE using DRS (with our without force attribute) - Are we going to launch with older version of JRE? 2) Insecure version of older JRE e.g. 8u101 installed on machine along with JRE9 a) App/Applet requesting older version of installed insecure JRE using java_version param or version attribute - Are we going to launch with JRE9 without showing SSV dialog? b) App/Applet requesting older version of installed insecure JRE using DRS (with our without force attribute) - Are we going to launch with older version of JRE? 3) If requested old version is not installed - Are we going to launch with JRE9 without showing SSV dialog?
07-12-2016
with DEPLOY_DEBUG set I get: java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Unknown Source) at com.sun.deploy.config.Config.setInstance(Unknown Source) at com.sun.javaws.Main.main(Unknown Source) Need to get a debug build to see where that's happening.
07-12-2016
[~jijising] 1. JDK9 is not disabled when I do the testing. 2. If jre9 and 8u11 are installed and enabled whereas app is requesting 8u111, a ssv dialog saying "The application would like to use a version of Java(1.8.0_111) that is not installed...." and with "Run with the latest version" button will show up. If I click "Run with the latest version" button, app gets loaded successfully. test app: C:\Program Files\Java\jre1.8.0_111\bin\javaws http://sqeweb.us.oracle.com/net/scanas415/export/deployment/crystal/DO_NOT_REMOVE_ME/jrebug/disableJavaManual_NonMultipleJRE/jnlp/testJavawsLaunchOnCLIRequest8u111.jnlp
06-12-2016
Is JDK9 disabled using JCP? Also what is the behavior if JRE9 and 8u111 are installed and both are enabled whereas app is specifically requesting for 8u111?
06-12-2016
Affected Tests: RULE "disableJavaManual_MultipleJREScenarios/testDowngradeAwareNotUninstallEnable" any any
02-12-2016