JDK-6742245 : Support calling non-Java languages from JavaScript
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10,6u12
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic,x86
  • Submitted: 2008-08-27
  • Updated: 2011-05-13
  • Resolved: 2008-10-02
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.
6u10 b33Fixed 7Fixed
Related Reports
Duplicate :  
Relates :  
The new Java Plug-In has abstracted the Java/JavaScript bridge between different web browsers. It is now strongly desired to support calling from JavaScript on a web page into objects of non-Java languages hosted on the JVM. It will be necessary to expose hooks to allow the run-time systems of these JVM-based languages to detect invocations, field accesses, etc. that they should handle; perform data type conversions; delegate down to default data type conversions already provided by the Java Plug-In; etc. The first consumer of this functionality will be the run-time system for JavaFX.

SUGGESTED FIX webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6742245.1 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6742245/

EVALUATION Added hooks to the JavaScript/Java bridge and APIs in the com.sun.* namespace to allow third-party languages implemented on the JVM to interpose on method calls, field accesses, and other operations. With these hooks, the language implementor can define a mapping between JavaScript syntax in the browser and their own language. JavaScript on the web page can then call into applets written in these other languages, like JRuby, Jython and Groovy. The first consumer of this functionality and the principal use case is JavaFX Script. The test case contains a link to the javadoc, which describes how a language implementor would use the new APIs. Once this work is checked in, code will be checked in to the JavaFX compiler workspace which uses it to build the JavaScript/JavaFX Script bridge. The changes are largely a refactoring of existing code, not logic changes. Careful thought has been given to the security ramifications of this feature; see in particular BridgeFactory.getBridge().