Details
-
Bug
-
Resolution: Fixed
-
P4
-
9
-
None
-
b141
-
generic
-
generic
Description
samples/dynalink/underscore.js fails to convert "java.lang.System.get_properties" call into "getProperties".
I tracked it down to the fact that we have a NashornStaticClassLinker as a prioritized linker (and it'll create a no-such-method linkage), so the autoexported UnderscoreNameLinker doesn't get a chance to step in.
This could be fixed by moving NashornStaticClassLinker to be a fallback linker (just as NashornBeanLinker is).
Now, underscore.js as an example would still never be able to convert underscore to camel case for any objects handled by any other prioritized linker (e.g. ordinary JS objects).
Even so, it feels like NashornStaticClassLinker might still be worth moving to fallback linkers; it only handles linking of “new” and application of our internal object filters to static method calls, but otherwise delegates to the ordinary Dynalink StaticClassLinker which lives within the BeansLinke, which is in the fallback. With the current setup (NashornStaticClassLinker being prioritized), we get the inconsistent behavior where autoexported linkers are bypassed for linking static methods while those same autoexported linkers get a chance to link instance methods on POJOs.
I tracked it down to the fact that we have a NashornStaticClassLinker as a prioritized linker (and it'll create a no-such-method linkage), so the autoexported UnderscoreNameLinker doesn't get a chance to step in.
This could be fixed by moving NashornStaticClassLinker to be a fallback linker (just as NashornBeanLinker is).
Now, underscore.js as an example would still never be able to convert underscore to camel case for any objects handled by any other prioritized linker (e.g. ordinary JS objects).
Even so, it feels like NashornStaticClassLinker might still be worth moving to fallback linkers; it only handles linking of “new” and application of our internal object filters to static method calls, but otherwise delegates to the ordinary Dynalink StaticClassLinker which lives within the BeansLinke, which is in the fallback. With the current setup (NashornStaticClassLinker being prioritized), we get the inconsistent behavior where autoexported linkers are bypassed for linking static methods while those same autoexported linkers get a chance to link instance methods on POJOs.