JDK-6782031 : Scripting API should provide public API to control access to Java classes
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: javax.script
  • Affected Version: 6u10,6u16
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp,windows_vista
  • CPU: x86
  • Submitted: 2008-12-08
  • Updated: 2024-04-12
  • Resolved: 2017-07-05
Description
A DESCRIPTION OF THE REQUEST :
The Scripting API should provide a public API to control access to Java classes, e.g. Mozilla Rhino's ClassShutter.

JUSTIFICATION :
Considering that the JDK automatically and irreversibly initiates the JavaScript context with the JavaAdapter and the "Packages", "java", "com", "edu", "javax", "net", and "org" properties, this makes it impossible to provide a sandbox-type environment in which scripts can run that are not completely trusted.

One example use-case is for processing Proxy Auto-Configuration (PAC) files (JavaScript) from within Java.  As visible in the Mozilla Firefox 3.0.4 source, nsProxyAutoConfig.js processes a PAC file within a restricted sandbox - something not currently possible with the Rhino implementation provided and configured by the JDK.  (In this case, there is no need for the JavaAdapter or any Java-class access.)


CUSTOMER SUBMITTED WORKAROUND :
None, other than providing and calling Mozilla Rhino or another scripting engine directly, without utilizing the Java Scripting API.
Comments
This requires change in javax.script which is covered under JSR-223 (maintenance JSR needed)
07-12-2015
Updating javax.script API would need maintenance JSR. There are nashorn specific solutions like --no-java option and ClassFilter API (https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/ClassFilter.html). For scripting language independent solution, we have to maintenance update of JSR-223 (javax.script) and that is not possible in jdk9 timeframe. Deferring this to jdk 10.
03-12-2015