Deployment Rule Sets do not properly launch the latest available version from the JRE6 family when the jpi-version is specified by the RIA

Question

Issue Summary
In Java 1.7 Update 71, Java 1.7 Update 72 and Java 1.8 Update 25 Deployment Rule Sets do not properly launch the latest available version from the JRE6 family when the jpi-version is specified by the RIA.  We've noticed this with Oracle Forms and Reports 11g where we have forms that specify Java 1.6 Update 20.  We used to be able to specify Java 1.6 Update 26 in our Ruleset, but now the only version a that works in our ruleset is Java 1.6 Update 20 which is the same version requested by the JPI-Version attribute of the jar.  The long term solution would be to upgrade Oracle Forms and Reports, however this isn't currently in the cards.
RuleSet.xml Test
Ruleset.xml
1 
2
3
4
5
6
7
8
9
10
11
<ruleset version="1.0+">  
<rule>
   <id location="*.javatester.org" />
   <action permission="run" version="1.6*" />
</rule>
<ruleset version="1.0+">
<rule>
   <id location="*.internaldomain.name" />
   <action permission="run" version="1.6*" />
</rule>
</ruleset>
Test 1 (Control)
Installed Java Versions:
– 1.7 Update 51 b13 (both x86 and x64 however x86 is invoked)
– 1.6 Update 26 b03 (both x86 and x64 however x86 is invoked)
Deployment Ruleset works as expected for both URLs
Test 2
Installed Java Versions:
– 1.7 Update 72 (both x86 and x64 however x86 is invoked)
– 1.6 Update 26 b03 (both x86 and x64 however x86 is invoked)
The RuleSet works for JavaTester.org however on internaldomain.name we get the following error:
With the trace logging turned on, I suspected the version attribute supplied by the RIA. I was able to trick Java by adding the following to my system deployment.properties file:
deployment.javaws.jre.0.product=1.6.0_20
deployment.javaws.jre.0.path=C\:\\Program Files (x86)\\Java\\jre6\\bin\\javaw.exe
deployment.javaws.jre.0.enabled=true
Because the RIA requests 1.6.0_20 it matches 1.6* from the deployment ruleset sooner than 1.6.0_26. However, if 1.6.0_20 is not available 1.6.0_26 should match according to the Deployment Rule Set documentation:
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html
The version of the JRE that is used is determined by the following order of precedence:
1. The current version of the JRE is used if it is available and matches both the version attribute and the version requested by the RIA.
2. The latest available version of the JRE is used if it matches both the version attribute and the version requested by the RIA.
3. The current version of the JRE is used if it is available and matches the version attribute.
4. The latest available version of the JRE is used if it matches the version attribute.
If no version is available that meets the criteria, then the RIA is blocked, and a message is shown to the user. To provide a custom message, include the message element.
As a result:
If Java 1.6.0_20 is listed in the version requested by the RIA and 1.6.0_20 is listed in the deployment.properties file, #1 matches.
If Java 1.6.0_20 is listed in the version requested by the RIA, but 1.6.0_20 is NOT listed in the deployment.properties file the #1 SHOULD match, but doesn’t. It used to match up-to and including JRE 1.7 Update 51 however the ruleset appears to no longer match in subsequent versions.
#2 should never match with our current Deployment Ruleset. It would match if we specified 1.7* as a version in the Ruleset.xml.
#3 used to be broken as well after JRE 1.7 Update 51 however this bug has been marked as fixed. See: http://bugs.java.com/view_bug.do?bug_id=8032781
I have reproduced this issue with Java 1.7 Update 71, Java 1.7 Update 72, and Java 1.8 Update 25 when one of these versions are installed with Java 1.6 Update 26.

Answer 1

I can't seem to edit this post anymore, for some odd reason.
So here goes;
I found this post in NVIDIA's knowledge base;
When installing an after-market graphics card into a certified Windows 8 PC with UEFI enabled, the s...
The interesting parts in this post are as follows;
When an after-market graphics card is installed into a motherboard with UEFI enabled in the system BIOS, or if the system is a certified Windows 8 PC with Secure Boot enabled, the system may not boot.
UEFI is a new system BIOS feature that is provided on most new motherboards. A UEFI system BIOS is required in order for the Windows 8 Secure Boot feature to work. Secure boot is enabled by default on certified Windows 8 PCs.
In order to get the PC to boot with a graphics card that does not contain UEFI firmware, the end-user must first disable the secure boot feature in the system's SBIOS before installing the graphics card.
Note: Some system SBIOS's incorporate a feature called compatibility boot. These systems will detect a non-UEFI-enabled firmware VBIOS and allow the user to disable secure boot and then proceed with a compatibility boot. If the system contains a system SBIOS the supports compatibility boot, the user will need to disable secure boot when asked during boot process
This leads me to believe that the BIOS update that wrecked my setup was 9SKT58A/9SJT58A, which only contains one change;
"Adds support for updating BIOS from a WIN7 BIOS to a WIN8 BIOS".
I've just ordered a cheap UEFI-compatible GT640 from Gainward, so I hope I'll be able to try that out this weekend.