JDK-8066380 : VM Option wasn't used when first jre is disable and second jre is enable
  • Type: Bug
  • Component: deploy
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2014-12-02
  • Updated: 2014-12-30
  • Resolved: 2014-12-25
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 9
9Resolved
Related Reports
Relates :  
JDK-4774077 - Use covariant return types in the NIO buffer hierarchy
Description
Testsuite:unifyJRESetting in common
Test name(s):testPassingRuntimeArgstoNonDefaultJRE
Product(s) tested:Jre9b40 64bit  
OS/architecture:Ubuntu12.04 x64

Reproducible: Always
Reproducible on machine:egtc

Is it a Regression:Not sure

Test result on the last GAed release for this train:Pass (8u45b01/64bit on ubuntu12.04-x64, but There is no step 18:we didnt' import the cert into signer CA in the instruction) 

[if Fail] Test result on FCS:

Is it a platform specific issue:Not sure.
(on win7-x64 with the same build 9b40/64bit,the result failed as another issue:unable to load the applet in IE9.)

Exception/Error from Log:http://scaaa008.us.oracle.com:9502/runs%2F647449.ManualSubmit-1/unifyJRESettingScenarios/testPassingRuntimeArgstoNonDefaultJRE.jtr

Copy JDF workspace,install test jre,and run this case
Steps to reproduce:

1.Install the public latest JRE 8u25b17 from java.com
2.Copy the installed jre directory to the local location. (e.g. simply copy binary jre /core to /root/Desktop/jre1.8.0_25)
3.Uninstall the JRE
4.Install the test JRE
5.Launch the Java Control Panel
6.Click "Java" tab
7.Click "View..." Java Runtime Environment Settings
8.Click "User" tab
9.The copy of public jre 8u25b17 should not be in the list(Only the test jre is avaible)
10.Click "Find" button
11.Follow the JRE Finder instruction to specify the path to the copy of jre 8u25b17.(with the exmaple, it should be /root/Desktop/jre1.8.0_25)
12.The JRE Finder should be able to locate the copy of jre /root/Desktop/jre1.8.0_25.
13.Click "Finish". The jre should be added to the Java Runtime Environment Setting's 's User tab
14.Change the Product name of lcoal jre under "Product" column, make it different with the installed jre
15.For the entry associated with the local jre(not test jre), enter '-Xmx256m' under 'Runtime Parameters' column
16.Under 'Enabled' column, uncheck all the boxes and only check the box associated with private jre
17.Enable Java console
18.Import cert into signer CA from http://sqeweb.us.oracle.com/deployment2/sheldon/webCases/unifyJRESetting/tmpcert/myKeystoreValid.
19.Use the browser to invoke a jnlp applet from http://sqeweb.us.oracle.com/deployment2/sheldon/webCases/unifyJRESetting/html/testHelloWorld_JNLP.html
20.If you see a dialog 'Warning - Unavailable Version of Java Requested', wait ~30 seconds until information about Java security baseline is downloaded, close browser and load the same page again - this is not an error
21.Accept the security warning dialog
22.Press 's' from within Java console
23.Expected behavior: 'javaplugin.vm.options = -Xmx256m' should be listed in the java console

The actual result: 
Step 22:there is no 'javaplugin.vm.options = -Xmx256m' shown in java console.
Comments
I tested this for 9 and 8u40 (latest). The only problem I was able to find is when jre9 is installed(and disabled) and jre8 is copied(and enabled), so we need to perform jre9 -> jre8 relaunch (as initial jvm is always latest available version on the machine, regardless the fact it can be disabled). Deployment tries to start jvm8 (this can be discovered in the logs: "basic: AppletRelaunch due to SSV") from jvm9, but it fails. The problem was introduced in 9b38, looks like by JDK-4774077, so it's not a deployment issue. Yesterday JDK-8067322 added new changes that should avoid this problem. So the bug should go away after the new jre9 that includes the changes for 8067322. Resolving this as duplicate.
25-12-2014
It is about multiply jres management(See attachment). This kind of unselecting enble jre is not really disable, I think it just provides a way to decide a preferred jre to launch. So the "unselected enable" jre can also be used in some cases. Such as there is no other jre as option or other jres are under security baseline. Possibly, the issue is that the not-installed jre cannot be registered completely successfully. It needs to investigate.
23-12-2014
So, the bug is just about we launch applets using disabled jre, right?
22-12-2014
I think this is a scenario that test three points: 1) Not-installed jre can be registered with JCP. 2) The Not-installed jre registered with JCP can be launched by applet also in some special case. That is the installed jre is disable and the not-installed but registered jre is enbled. (Now it cannot be used) 3) The Not-installed jre registered with JCP is able to use jvm argument defined in JCP. (Now argument cannot be used since the second condition cannot be achieved) The steps 1 to 3 is just to create a not-install jre.
15-12-2014
Per discussion with Jitender
09-12-2014
Issue can be reproduced on win7 x86 also. Try it with 9b40 as installed version, 8u25 and 9b40 as "copy" version. Look like the enable option doesn't work. The jnlp applet always gets launched with 9b40 although it is disable. 8u25 and 9b40 are above security baseline so expecting they are used when installed 9b40 is disabled. In the cases of 8u25, jnlp applet hangs up. In the cases of 9b40 as copied jre, the multiply jres setting in jcp is removed although they have different product name. Bug might have the relation with JDK-8015842.
03-12-2014
RULE unifyJRESettingScenarios/testPassingRuntimeArgstoNonDefaultJRE any any
02-12-2014