Bug ID: JDK-8027933 Add --const-as-var option

Versions (Unresolved/Resolved/Fixed)

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
8u20Fixed	9 b13Fixed

Many existing scripts, especially node modules, use 'const' and so fail on Nashorn. As far as I can tell, a simple string replace with 'var' works just fine, but obviously Nashorn can do this much more effectively.

A new Options argument (even undocumented) would be perfect, e.g.

nashorn.option.const.as.var = { 
    name="--const-as-var",    
    is_undocumented=true,        
    desc="Replace 'const' with 'var'.",
    type=Boolean                 
}

FWIW, our use case would pass it via NashornScriptEngineFactory.getScriptEngine().

verified on jdk9 b25
01-08-2014
> However, if you add a command line option (--const-as-var) > to enable this "feature" (off by default) then > we will consider it. Thanks. Here is a patch that adds such option. > Note that you should also mod TokenType.java:114 > CONST (FUTURE, "const"), --> > CONST (KEYWORD, "const"), Well, this is a bit problematic with the --const-as-var option. The const can now have different meaning in different ScriptEngine instances. Rather than complicate the patch, I am inclined to keep the FUTURE type.
16-04-2014
The #1 goal I am aware of is to be able to use nashorn to execute existing node.js libraries. My patch https://bugs.openjdk.java.net/secure/attachment/19591/support-const.diff shows this is trivial to achieve. Can we focus on this real goal and help me polish my patch, so it is acceptable for production code, rather than spending our thoughts on (right now) esoteric support for ES6?
04-04-2014
I should have commented on this earlier. I agree it needs to be a full implementation according to the ES6 spec (not the v8 or rhino spec). It is still non-trivial to implement. It's not just locking properties. it also requires lower recognizing duplicates and var/let overrides.
20-03-2014
After thinking about this for a while I think we should go the whole way and implement const the right way. Adding a faux-const flag will add complexity to our and our users' code without adding much benefits. Besides, how complex could this feature be? We already have non-writable properties so we only have to support this in the parser and AST. I don't think there should be any new functionality required in codegen or runtime.
20-03-2014
This should be a temporary feature until we can get full featured const in place.
06-11-2013