JDK-8067935 : Don't create adapter classes in JavaAdapterFactory.isAutoConvertibleFromFunction
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2014-12-19
  • Updated: 2015-11-16
  • Resolved: 2015-11-16
Related Reports
Relates :  
Relates :  
Description
Currently, every time Nashorn needs to know whether a class can be auto converted from a function, it will generate the adapter class for that function and ask it (because the adapter happens to know). This is a bit of a heavy-handed approach.

Even though from code complexity point of view it is convenient, performance wise it is not.
Comments
If JDK-8133299 is implemented, this is even less relevant.
16-11-2015

I have reviewed this, and the issue is that the ability to convert a function to a SAM type is dependent on Nashorn being able to create a SAM adapter. It'd be possible to write a kind of a "dry run" version of the adapter generator for determining the conversibility, but as a first step it is probably better to just make sure the isAutoConvertibleFromFunction query is more robust against failure to generate the adapter (JDK-8068580). To illustrate the problem: a type can be a target for a SAM conversion if ��� in addition to obvious requirement of being a public abstract class/interface with a single abstract method name and a public default constructor, it also has to have the said public constructor to not be @CallerSensitive, and it can't have an explicit and final finalize() method, and the adapter class can't exceed classfile size limitations. Right now, these constraints are automatically tested by trying to generate valid bytecode for the adapter class. It would be a valid disposition to decide to "Won't Fix" this as long as JDK-8068580 is fixed.
07-01-2015