JDK-8150515 : sun/tools/jrunscript/* tests fail with "Expected an operand but found var"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-02-24
  • Updated: 2020-09-01
  • Resolved: 2016-02-24
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 9
9Resolved
Related Reports
Duplicate :  
JDK-8150186 - Folding mismatched accesses with @Stable is incorrect
Relates :  
JDK-8150180 - String.value contents should be trusted
Description
The tests fail with the following error:

< script error in file <system-init> : <system-init>:220:0 Expected an operand but found var
< var inp = java.lang.System["in"];
< ^ in <system-init> at line number 220 at column number 0

This seems to happen while parsing line 220 of
jdk/src/java.scripting/share/classes/com/sun/tools/script/shell/init.js
Comments
Oh, I missed that. Thanks for verifying, Aleksey!
24-02-2016
Aha. I think -Xint experiment is misleading, and scripts are actually starting without -Xint. This explains why removing @Stable works. I ran these tests with and without a candidate fix for JDK-8150186, and it starts to pass. So, we are looking at another instance of incorrect constant folding triggered by @Stable String.value. Closing this issue as duplicate.
24-02-2016
Weird. @Stable should not affect -Xint. I'll look into this.
24-02-2016
I'm able to reproduce this with the latest hs-comp build. I was able to determine the offending changeset: http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/c234831ff203 This was added with JDK-8150180. Removing the @Stable annotation solves the issue. Not yet sure why this happens.
24-02-2016
Not reproducible in 9-dev (Nashorn tip) and main; assigning back to hotspot/compiler.
24-02-2016
Verified that this is not a compiler issue (also fails with -Xint). Assigning to core-libs/jdk.nashorn.
24-02-2016