JDK-8088252 : Fix SandBoxAppTest unit test to work with XPatch
  • Type: Bug
  • Component: javafx
  • Sub-Component: application-lifecycle
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-05-09
  • Updated: 2016-03-15
  • Resolved: 2016-03-15
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
9Fixed
Related Reports
Relates :  
Relates :  
Description
In JDK 9 jar files in lib/ext are no longer granted all permissions by default. We deliver a policy file into the JDK 9 build such that JRE/lib/ext/jfxrt.jar is granted all permissions. This allows sandboxed apps that are run with a standard JDK 9 to continue to work.

When we run our JavaFX build, we run it with a JDK that has the jfxrt.jar removed so we can test the jfxrt.jar that we just built. In our  sandbox.SandboxAppTest unit test, we set a security manager and also set -Djava.ext.dirs to our local JavaFX build. Once we switch to using JDK 9 to build and test FX 9, this will start failing.

Comments
fixed as part of 8147399
15-03-2016

Any test that defines a -Djava.security.manager and uses the Jake -XPatch mechanism will need to append to the security policy so that the classes found in the patch are granted the needed permissions. Given an -XPatch: build/testing/modules, we will need something similar to: #from the JDK conf/security/java.policy) grant codeBase "jrt:/javafx.base" { permission java.security.AllPermission; }; # to the addition needed for each module in the XPatch: grant codeBase "file:build/testing/modules/javafx.base" { permission java.security.AllPermission; }; It is likely that we will need an absolute path, and not a relative path as is shown, and of course - more fun with Windows. As there is already a security policy that is being used for test, it is expected that we will need to generate in the build process a build specific file to be used (build/testing/java.policy maybe) that contains the required clauses, and then append them with the test perms to create a single file used for the test invocation.
02-02-2016

This may need to be modified slightly to work with Jigsaw, but I think that solution #1 still seems best until we are building FX and JDK at the same time.
17-12-2014

Note that this won't start failing right away because we will run the FX 9 build / test with JDK 8. When we do fix it, possible solutions are: 1) Add jfxrt.jar to the boot classpath 2) Provide a custom policy file that grants permissions to jfxrt.jar 3) Start running our tests with a JRE that includes the just-built JavaFX bits #3 would test it in the real environment, but seems impractical until FX is part of the JDK build. I plan to do #1 (#2 is more work and doesn't add any real benefit over #1).
09-05-2014