-
Enhancement
-
Resolution: Fixed
-
P4
-
9
-
None
-
b103
-
generic
-
generic
Currently, Nashorn Java adapters bind early (on construction) to the functions in their implementation-object. This can be a problem if the implemented class or interface has a lot of methods, as they'll all be looked up at once. It is also a problem as we use bound functions, which currently don't support type specialization.
Instead, we should just store the implementation object, and have the body of every delegator method contain the usual INVOKEDYNAMIC dyn:getMethod, INVOKEDYNAMIC dyn:call sequence.
Benefits:
- adapters will work with any JS callables, not just ScriptFunction
- constant-time initialization of adapter instances, as it just has to store the object and doesn't have to bind functions
- we won't force creation of bound functions, so invoked functions will still type-specialize
- no need to maintain separate code for return type conversions (either to SAM types or to char and String) as normal Nashorn bootstrap linking will take care of them.
Drawbacks:
- more complicated delegator body code, esp. needing to distinguish between being constructed with a function (SAM) vs. object, and detecting unimplemented methods (to delegate to superclass or throw UnsupportedOperationException)
Instead, we should just store the implementation object, and have the body of every delegator method contain the usual INVOKEDYNAMIC dyn:getMethod, INVOKEDYNAMIC dyn:call sequence.
Benefits:
- adapters will work with any JS callables, not just ScriptFunction
- constant-time initialization of adapter instances, as it just has to store the object and doesn't have to bind functions
- we won't force creation of bound functions, so invoked functions will still type-specialize
- no need to maintain separate code for return type conversions (either to SAM types or to char and String) as normal Nashorn bootstrap linking will take care of them.
Drawbacks:
- more complicated delegator body code, esp. needing to distinguish between being constructed with a function (SAM) vs. object, and detecting unimplemented methods (to delegate to superclass or throw UnsupportedOperationException)
- relates to
-
JDK-8179024 FX Samples broken
-
- Resolved
-
-
JDK-8067935 Don't create adapter classes in JavaAdapterFactory.isAutoConvertibleFromFunction
-
- Closed
-