JDK-8068573 : POJO setter using [] syntax throws an exception
  • Type: Bug
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-01-07
  • Updated: 2015-09-29
  • Resolved: 2015-01-14
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.
JDK 8 JDK 9
8u40Fixed 9 b47Fixed
Related Reports
Relates :  
JDK-8068994 - Forgot to add a test model to JDK-8068573
Description
This program (requires jdk.nashorn.test.* classes):

var x = new (Java.type("jdk.nashorn.test.models.PropertyBind"))
var n = "writeOnly";
x[n] = 2
print(x.peekWriteOnly());

throws:

Exception in thread "main" java.lang.invoke.WrongMethodTypeException: expected (Object,int)void but found (Object,int)Object
	at java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:294)
	at java.lang.invoke.Invokers.checkExactType(Invokers.java:305)
	at jdk.nashorn.internal.scripts.Script$Recompilation$2$x$cu1$restOf.:program(x.js:3)
	...
Comments
SQE OK to take the regression bug fix to 8u40
19-01-2015
Critical Request Template - Justification : The inability to invoke a POJO setter through indexed property syntax is a regression from 8u25. - Risk Analysis : Low but potentially existing risk. Changes in type handling can always have subtle, hard to predict side effects. In this case, care has been taken to limit the changes to handling of void return type from POJO methods only. It is actually possible to further reduce this patch: by just adopting the changes to AbstractJavaLinker alone the immediate regression is avoided. The rest of the changes have to do with ensuring consistency of the return values from overloaded method when some of them are void (making sure void is always represented as undefined, not as null). Strictly speaking, the changes to AbstractJavaLinker are sufficient to eliminate the regression if we don't care for the last assertions in the test to return "null" instead of "undefined" (void 0) when invoked on a void-returning method. What I'm trying to say is that if the overall changeset is deemed too risky (my personal opinion is that it shouldn't be), we can separately apply only the changes to AbstractJavaLinker with no risk to fix the regression in its narrowest sense. - Webrev : http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-January/004095.html - Testing (done/to-be-done) : A new test has been added to Nashorn's test suite (test/script/basic/JDK-8068573.js). The test262 test suite has been run as well and it indicated 0 failures. - Back ports (done/to-be-done) : Backported to 8u-dev; 8u-dev backport needs to be pushed into 8u40 if approved here. No further backports necessary. Note that JDK-8068994 also needs to be backported, as it is a part of the test that was unfortunately omitted from the original changeset. - FX Impact : N/A - Fix For Release : 8u40
16-01-2015