JDK-8077855 : When applet is relaunched, extra JUT records can be sent
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7u79,8u45,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-04-15
  • Updated: 2015-09-29
  • Resolved: 2015-06-09
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 7 JDK 8 JDK 9
7u91Fixed 8u60Fixed 9Fixed
Description
This is a request from JAMC. See JAMC-1748 and JAMC-1595 for details, and also JEM-244 at https://javafx-jira.kenai.com/browse/JEM-244.

A problem, in a few words. Suppose an applet requires Java version X. It is launched on a desktop with versions X and Y installed, and version Y is the current, used by Java Plugin / Web Start. The applet is first launched with version Y, then re-launched with version X in a new process. It results in two Java Usage Tracker records:

plugin2, appName java_version=X, version Y
plugin2, appName java_version=X __applet_relaunched, version X

The problem here is that the applet was not actually run with version Y, as the first JUT record implies. Java Plugin / Web Start should not report any JUT records, until:

1. It is clear what Java version is available and will be used to run the applet
2. It is clear that user has not cancelled application run (e.g. pressed "Cancel" button in a warning dialog)
Comments
SQE OK to defer the AMC related bug fix
06-05-2015
Added critical watch as it appears the aim is to fix for 15_03.
24-04-2015
Crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-959
23-04-2015
I can see why AppContext was not used, since in both javaws and plugin appName is stored from code running in different app context than the app. in webstart, even the first security dialogs are before switching to application thread group (and therefore app context), though subsequent dialogs may be shown in the apps threadgroup. So using AppContext for this is out, and since I wasn't able to find example of the potential problem (and it is not directly related to this fix) I will leave it for now. I am , however, changing to local variable, which since the instance of DeploymentHooks is a singleton, is the same as using system properties.
16-04-2015
There also seems to be a problem in DeploymentHooks wrt storing the appName in a SystemProperty. With html applets, multiple applets can share a VM, yet each applet has it's own AppContext. Storing data in a system property is no better than storing it in local variable . There is one set of System Properties for all applets running in a VM (just as Config.getHooks()) ensures there is one instance of DeploymentHooks()). As a result, it is possible to store the appName system property, then (before using it for that applet), store it for another applet, then use and clear the second name then the second applet to try and use it will have no value. Simple tests show no problem, as the sequence is { 1.) set, 2.) use and clear, 3.) set, 4.) use and clear. } but this is just timing - it could easily be { 1.) set, 2.) set, 3) use, 4.) use } (particularly if there are more than two applets sharing the vm with wildly different timings). Value should be stored in AppContext to ensure separate value for each applet.
16-04-2015
We currently show JUT from SandboxSecurity.isPermissionGranted (for sandbox apps) or TrustDecider.isAllPermissionGranted() (for all-permissions apps). We do this before rules are consulted and/or dialogs shown, so a record currently exists for a blocked app, and well before relaunch decision is reached. I think original design was that we should add JUT record for blocked app, but that could either be maintained or not as desired, with the following changes: 1.) move the calls to the end of these two methods, where they be added only if the app runs 2.) add JUT call in showBlockedDialog() (should we want to maintain JUT record for blocked apps, while not having one for canceled or user denied apps). Also content of this record for blocked app could be augmented in any way desired. 3.) change DeploymentHooks.TrackUsage(), so this method only prepares the JUT record, and does not add it, while adding separate call to actually add the record. 4.) Determine each place in code where we have final determination not to relaunch, and add call to DeploymentHooks to actually add the (previously saved) JUT record.
15-04-2015