Nashorn Scripting Engine Replacement/Implementation?

[Dordrecht]

Hi all.

ColdFusion 2021 uses Java 11 and ColdFusion 2023 uses Java 17. Java 11 contained the Nashorn Scripting Engine, which is used in my CF 2021 code to run JavaScript on the back end, but Nashorn was removed from Java 17, so I'm looking for the best way to replace what it did in ColdFusion 2023. Has anyone else successfully done this?

Apparently Nashorn is now available as a standalone package but I'm not a Java guy, so I don't know how to get it into a form that ColdFusion can use (maybe a jar file). Would anyone else know how to go about this?

Another alternative is the GraalJS scripting engine, which I understand can duplicate what Nashorn did, but again, how can this be put into a ColdFusion-usable library or installation?

Any help would be greatly appreciated!

[Dave Watts]

That sounds interesting! I don't know anything about that. Can you post an example of using this from CFML?

[Dordrecht]

This is a very rudimentary example, @Dave Watts. I didn't code the original in our codebase but I got this to work yesterday when I was experimenting with it in CF2021.

<cfset local.scriptManager = createObject("java", "javax.script.ScriptEngineManager").init() />
<cfset local.engine = local.scriptManager.getEngineByName("javascript") />
<cfsavecontent variable="local.someJavaScript">
function addNums() {  return 2 + 3; }
</cfsavecontent>
<cfset local.engine.eval(local.someJavaScript) />
<cfset local.myResults = local.engine.invokeFunction('addNums',[]) />
<cfoutput>#local.myResults#</cfoutput>

[Dave Watts]

First, thank you for posting that example! It's interesting, and saves me the trouble of looking it up. But I think that's using built-in functionality in Java 17. If the rest of your code is using ScriptEngineManager you can skip the rest of my response.

Based on that example, I don't see any reason you can't just load an extra JAR file into CF to run this. It would have to be within the same JVM as CF though. All that said, I read that Nashorn has been deprecated in favor of GraalJS for reasons (based on your links). So, if you don't care about future compatibility, you could continue using Nashorn, or use GraalJS in compatibility mode. But I don't know how you can create a JAR file from these. I did find a sort of generic "how to create a JAR from a Maven project" page but it has a lot of options:

https://www.baeldung.com/executable-jar-with-maven

But it looks like you might have to run CF as a web application within the standard version of Tomcat to make this all work. That's probably more trouble than it's worth - and I could very well be wrong about all this - but here's a link about setting up Tomcat with GraalVM:

https://tomcat.apache.org/tomcat-9.0-doc/graal.html

Good luck, and keep us posted!

[sdsinc_pmascari]

If you can obtain a jar file, then it should be fairly simple to load it into CF for use.  I'm a bit hazy on creating a JAR out of Maven repository, though.

[BKBK · Accepted solution]

Hi @Dordrecht ,

I have found a way to solve the problem on Java 17.  It involves using the OpenJDK Nashorn version, as suggested in this Stackoverflow post: https://stackoverflow.com/questions/68108169/does-nashorn-org-openjdk-nashorn-have-any-support-for-j... .  The version I have successfully tested is Nashorn-core 15.6.

You can see from the Nashorn-core 15.6 documentation that its dependencies are

• asm
• asm-commons
• asm-tree
• asm-util

Each dependency corresponds to a Jar file. So, to implement Nashorn on ColdFusion 2023 and Java 17, you need to download the following Jar files, and place then in {CF2023_HOME}/lib:

• nashorn-core-15.6.jar (download location: https://repo1.maven.org/maven2/org/openjdk/nashorn/nashorn-core/15.6/ )
• asm-9.7.1.jar (download location: https://mvnrepository.com/artifact/org.ow2.asm/asm/9.7.1 , then click on "jar" link);
• asm-commons-9.7.1.jar (download location: https://mvnrepository.com/artifact/org.ow2.asm/asm-commons/9.7.1 , then click on "jar" link);
• asm-tree-9.7.1.jar (download location: https://mvnrepository.com/artifact/org.ow2.asm/asm-tree/9.7.1 , then click on "jar" link);
• asm-util-9.7.1.jar (download location: https://mvnrepository.com/artifact/org.ow2.asm/asm-util/9.7.1 , then click on "jar" link).

Remember to restart ColdFusion 2023.

The test code I used is:

<cfset scriptManager = createObject("java", "javax.script.ScriptEngineManager").init()>

<cfset engine = scriptManager.getEngineByName("Nashorn")>
<!--- Alternative lines to define engine --->
<!---<cfset engine = scriptManager.getEngineByName("javascript")>--->
<!---<cfset engine = scriptManager.getEngineByName("js")>--->

<cfset someJavascript = "function addNums() {  return 2 + 3; }">
<cfset engine.eval(someJavaScript) >
<cfset someResults = engine.invokeFunction('addNums',[])>

Test result: <cfoutput>#someResults#</cfoutput>

The output was: Test result: 5

[Dordrecht]

@BKBK Thank you for the response.  I'm just finishing the setup of my CF2023 environmet for implementing and testing this, and hope to strat trying to apply your suggestion shortly.

[BKBK]

@Dordrecht , No worries. I am curious to know how it pans out. 

My intention was to give an answer to your question about implementing standalone-Nashorn in Java. A quick solution, I thought, would remove any obstacles in your migration to ColdFusion 2023. Nevertheless, I would suggest we continue to look for a solution that uses GraallVM.

GraalVM has advantages over Nashorn, among which:

• performance;
• full ECMAScript support (Nashorn is somewhat limited here);
• versatility: With GraalVM, JavaScript won't be the only language being integrated into your Java application. The ability to use multiple languages together (polyglot programming) represents a more flexible, modern approach than Nashorn, which was solely focused on JavaScript.

[Dordrecht]

Understood, @BKBK. I did start to play with GraalVM, or specifically GraalJS, based on notes offered to me by a couple of very helpful people on Facebook's CF Group. I tried unsuccessfully to apply their CF2023 step-by-strp to CF2021, because 2021 was the only environment I had installed. Of course, I had to substitute earlier versions of the GraalJS jar files that I thought would be apropos to CF2021. I now have CF2023 installed and am planning on trying your Nashorn solution and the other person's GraalJS solution to 2023 soon. (We're having some internal dev environment issues that are delaying progress.)  

[Dordrecht]

This is the code (below) for implementation of GraalJS, as supplied (verbatim) by a helpful contributor in the Facebook CF group. I have tried to implement it as described but can't get it to work. I get the result, "Variable JSENGINE is undefined" when running her example. Possibly I have the wrong versions of the jars? I haven't been able to find a good cross-reference indicating which versions of GraalJS/GraalVM work with which versions of Java, which seems really odd. Any assistance would be greatly appreciated.

-----

Nashorn was removed from Java 15+, and ColdFusion 2023, which runs on Java 17, no longer includes it. GraalVM’s JavaScript engine is the best alternative, but it does require some setup.
Steps to Integrate GraalVM JavaScript into ColdFusion 2023
1. Download the GraalVM JavaScript JAR
Since you need JavaScript support within CF2023, you can use the standalone GraalJS JAR instead of the full GraalVM distribution.
Download the latest graal-js JAR from Maven:
GraalVM JavaScript JAR
The current version should be something like org.graalvm.js:js:23.1.1
You may also need org.graalvm.js:js-scriptengine for Java ScriptEngine compatibility.
2. Add the JAR(s) to ColdFusion's Classpath
After downloading the necessary JARs, you need to add them to ColdFusion's Java classpath:
Place the JAR(s) into ColdFusion’s lib directory:
Path: {ColdFusion2023_Home}/cfusion/lib
Alternatively, you can place them in a custom folder and reference them dynamically.
Edit ColdFusion’s JVM Arguments:
Open jvm.config (found in {ColdFusion2023_Home}/cfusion/bin).
Add the path to the JAR(s) in the java.class.path entry.
Example:
ini
Copy code
java.class.path={other existing entries};C:/path/to/graal-js.jar;C:/path/to/js-scriptengine.jar
Restart ColdFusion to load the new JARs.
3. Use GraalVM JavaScript in ColdFusion
Once GraalVM JavaScript is installed, you can use it in ColdFusion via the Java ScriptEngineManager, similar to how Nashorn was used.
Here’s how you can execute JavaScript in ColdFusion using GraalVM:
cfml
Copy code 

<cfscript> // Import required Java classes ScriptEngineManager = createObject("java", "javax.script.ScriptEngineManager"); engineManager = ScriptEngineManager.init(); // Get the GraalVM JavaScript engine jsEngine = engineManager.getEngineByName("graal.js"); // Execute JavaScript code jsCode = "var x = 10; var y = 20; x + y;"; result = jsEngine.eval(jsCode); // Output result writeOutput("JavaScript result: " & result); </cfscript>
Troubleshooting
If getEngineByName("graal.js") returns null, ensure:
The JARs are correctly added to the classpath.
The ColdFusion server has been restarted.
You're using the correct JAR versions.

[BKBK]

@Dordrecht , although Nashorn has been removed from Java 15+,  the OpenJDK Nashorn version may be ised in Java 17, as you yourself mentioned in your initial post. That is the basis for the Nashorn solution I gave.

Have you tested it? If it works, then you will at least have a bird in hand.

In any case, I am looking for a good GraalVM solution for Java versions from 17 onwards. 

[Dordrecht]

For GraalVM, I dropped the following files into my cf lib folder as the instructions indicated, but got "Variable JSENGINE is undefined":
js-23.0.7,jar

js-scriptengine-23.0.7.jar

Later, I added in:

js-language-23.1.1.jar

graal-sdk-23.0.7.jar 

truffle-api-23.0.7.jar

Following the addition of those, running the Graal script provided in my previous reply, the line:

jsEngine = engineManager.getEngineByName("graal.js");

worked. I was able to dump the contents of jsEngine and when I added and ran:

foo = engineManager.getEngineFactories();

writedump(foo);

It showed Graal as an available engine, which is great; however,  I immediately got the following error whern the actual JavaScript is processed:

java.lang.NoClassDefFoundError: com/ibm/icu/number/Notation

[BKBK]

I would like to have a two-way discussion with forum contributors. Have you seen the questions I have been asking about testing my own suggestions?

[Dordrecht2]

@BKBK I'm sorry. There have been about three replies that I have made to you that just seem to have gone missing. I'm not sure what is going on with that. I look forward to your replies and have been responding to them.

One of my replies confirmed that I tested your Nashorn solution and it seems to be working perfectly, and I offered a big "thank you" for your help on it, and added that although it may be a last ditch solution, the fact we have found that it is no longer supported will likely keep my company from adopting it. if there is anything else that you have mentioned that seems to be going ignored please let me know, and thank you again for your help! 

[BKBK]

@Dordrecht2 , I was still at a loss whether the OpenJDK Nashorn solution works in your setup. Thanks for confirming that it does.

We may use the same version of ColdFusion, but our setups and server environments might be different. Hence the necessity to tick off results we agree on before moving on. Especially in our search for a good GraalVM solution, which involves dealing with some complexity. 

Though I enjoy helping, I am grateful for your kind words. 

[BKBK]

Other obligations required my attention in the past week. Just to share that I am today resuming the search for a suitable GraalVM solution for ColdFusion 2023.

My findings so far:

• GraalJS's syntax is different from Nashorn's. So, if you're migrating from Nashorn to GraalJS, you will likely have to change some of the Javascript-related code. It means you will have to factor in some coding effort if you want to make a clean break from Nashorn.
  An alternative is to continue clinging to Nashorn by running GraalJS with "Nashorn Compatibility" switched on.  However, I would discourage this. For one thing, it is not a sustainable solution.
  I would look for a solution that makes a clean break from Nashorn, hence a future-proof solution that is 100% GraalJS.
• I have been unable to find any GraalJS/GraalVM Jar files targeting Java 17 (ColdFusion 2023's Java version).  
• The GraalVM Jar files that are readily available on the web (such as the newest versions 23..x.x and 24.x.x) are suitable for Java versions 21 and above. But they may not be compatible with Java 17.   
• So far, the best strategy I can think of is to: 
  (1) build a GraalVM project, separate from ColdFusion, using Maven and POM configuration, for example;
  (2) extract the Jar files from the project, and place them in ColdFusion's lib directory.

[Dordrecht]

Thank you, @BKBK! I really appreciate your assistance.

To make the coding needs clearer using some altered examples, the Nashorn interaction with the javascript engine in my code is not extensive. Once the engine is made available for CF to use, there is a block of hard-coded JavaScript brought in (mostly Javacript functions):

<cfset local.engine.eval(local.scriptBody)>

Next, some dynamically derived JSON data is made available to the engine. (JSON below is defined in scriptBody):

<cfsavecontent variable="local.jsData">
<cfoutput>
var myFirstData = JSON.parse('#JSStringFormat(SerializeJSON(local.firstData))#');
var mySecondData = JSON.parse('#JSStringFormat(SerializeJSON(local.secondData))#');
</cfoutput>
</cfsavecontent>
<cfset local.engine.eval(local.jsData) />

Next, more JavaScript is eval'd. (myFunction is defined in scriptBody): 

<cfsavecontent variable="local.jsRunStuff">
var myResults;
myResults = myFunction(myFirstData, mySecondData);
</cfsavecontent>
<cfset local.engine.eval(local.jsRunStuff) />

And last, an invocation is executed with a value returned to CF:

<cfset local.myResults = DeSerializeJSON(local.engine.invokeFunction('getmyResultsAsJSON', [])) />
 

So, I think the only thing I'd need Graal to do is equivalents of eval and invokeFunction methods. (I'm not quite sure at thie time what each of those methods do.) Hopefully everything else would just be handled by Graal. 

[BKBK · Accepted solution]

It has been a long search. But I can now provide an update. I have been able to create a proof-of-concept of GraalJS in ColdFusion.

The proof-of-concept consists of CFML code that uses GraalJS to evaluate Javascript source code, and produce a result.

Proof-of-Concept

The steps I followed in creating the proof-of-concept

1. Create a Maven project
   I created a project in Maven. However, I didn't need to install Maven, as ColdFusion 2023 comes with Maven already installed. It is located at C:\ColdFusion2023\cfusion\maven\apache-maven-3.8.6.
   To create a Maven project, simply create a new directory under the Maven root.
   For example, the directory C:\ColdFusion2023\cfusion\maven\apache-maven-3.8.6\myMvnProject
   
   
2. Attach POM file to project
   Copy the attached pom.xml file to the directory myMvnProject. Examine pom.xml in a text editor. You will see that it contains the 3 dependencies org.graalvm.sdk:graal-sdk, org.graalvm.polyglot:polyglot and org.graalvm.polyglot:js. These are the resources needed to download all the JAR files that GraalJS depends on.
   
   
3. Add Maven to the Operating System's Environment Variables
   I added the following:
   

   Variable Name: MAVEN_HOME
   Variable Value: C:\ColdFusion2023\cfusion\maven\apache-maven-3.8.6​

   I then added

   %MAVEN_HOME%\bin​

   to the PATH environment variable.
   
   
4. Obtain the JARs required for implementing GraalJS in ColdFusion 2023
   The steps I followed:
     - Open the Command Prompt (CMD) as Administrator.;
     - Use the cd command to navigate to the directory of the Maven project, C:\ColdFusion2023\cfusion\maven\apache-maven-3.8.6\myMvnProject;
     - Type the command mvn dependency:copy-dependencies and press <ENTER> to run it.
        If all goes well, the command will use the POM file to download the required JAR files.
        In addition, the command will automatically create the subfolder /target/dependency within the project directory, and store the JARs there.
        For example, my C:\ColdFusion2023\cfusion\maven\apache-maven-3.8.6\myMvnProject\target\dependency folder looks like this:
   
   
   
5.  Create GraalJS_library folder and copy the GraalJS JARs into it
   I created the folder C:\ColdFusion2023\cfusion\GraalJS_library.
   Then I copied all the contents from C:\ColdFusion2023\cfusion\maven\apache-maven-3.8.6\myMvnProject\target\dependency to the GraalJS_library folder.
   
   
6. Configure ColdFusion's JVM for Graal
   I did this by modifying the java.args setting in ColdFusion's jvm.config file as follows:
   
   Replace
   

   -Dcoldfusion.classPath={application.home}/lib/updates,{application.home}/lib,{application.home}/gateway/lib,{application.home}/wwwroot/WEB-INF/cfform/jars,{application.home}/bin/cf-osgicli.jar​

   
   with
   

   -Dcoldfusion.classPath={application.home}/lib/updates,{application.home}/lib,{application.home}/gateway/lib,{application.home}/wwwroot/WEB-INF/cfform/jars,{application.home}/bin/cf-osgicli.jar,{application.home}/graalJS_library -Dpolyglot.log.file={application.home}/logs/polyglot.log -Dpolyglotimpl.DisableClassPathIsolation=true -Dpolyglot.engine.WarnInterpreterOnly=false​

   
   
   You will find an explanation of the additional Graal flags in the Reference Notes below.
   Restart ColdFusion for the changes to take effect.
   
   
7.  Run the proof-of-concept code
   

   <!--- Create GraalJS context, giving it the necessary permissions --->
   <cfset context=createObject("java", "org.graalvm.polyglot.Context").newBuilder(["js"]).allowAllAccess(true).allowIO(true).build()>
   
   <!--- Javascript for calculating the square root of a given positive integer --->
   <cfset jsCode = 'calculateRoot(param); function calculateRoot(param) { return "The square root of ".concat(param).concat(" is ").concat(Math.sqrt(param)); }'>
   
   <!--- The input: a positive integer --->
   <cfset arg = 10>
   
   <!--- Pass the argument from CFML to GraalJS --->
   <cfset context.eval("js", "var param=#arg#;")>
   
   <!--- Run GraalJS using the argument --->
   <cfset value = context.eval("js", jsCode)>
   
   <cfoutput>#value#</cfoutput>​

   The result: The square root of 10 is 3.1622776601683795

[BKBK]

Information relevant to the above GraalJS proof-of-concept:

1. Some challenges I faced
   
   

• There is surprisingly little documentation on the use of GraalVM on the web. Practical examples are few and far between.
• GraalVM has only been around for 5 to 6 years. So it is relatively new Java technology. But it has a growing following. As such, it is developing and changing rapidly in the wild. It is being extended in different directions by different interest groups. One consequence is that, during my web searches, I could not find 2 GraalJS code examples that are implemented in the same way. 
• I faced complexity at every turn. GraalVM is available in two Editions, Community and Enterprise. The functionality and capability of the editions are quite different. However, when you search the web for GraalVM you see that the information about the two editions is all mixed up. 
  Add to this the fact that GraalVM can serve a variety of programming flavours. It can run applications written in programming languages such as Java, Python, Ruby, R, and Javascript. This is Graal's so-called polyglot capability. Not only that, Graal allows for tight integration between the different languages. For example, it enables you to call Java methods from JavaScript and vice versa. 
  Great versatility and power, for sure. But it is quite complex to get to grips with implementation, especially when there is inadequate documentation and guidance.

2. Reference notes
For reference purposes, here are some of the important obstacles and errors I encountered along the way (together with the solutions):

• Location of GraalJS JAR files
  GraalJS depends on 14 JARs and 2 POM files. I quickly discovered that it was impractical to copy them into ColdFusion's lib directory. For a start, that was poor design. It didn't promote separation-of-concerns. 
  In any case, it led to classpath errors. 
  The solution was to bundle the JARs and POM files into a separate directory dedicated to GraalJS, namely, C:\ColdFusion2023\cfusion\GraalJS_library.
  I then appended {application.home}/graalJS_library to the setting -Dcoldfusion.classPath in jvm.config. 
• javax.script.ScriptEngineManager inadequate
  Try as I could, I could not get the combination scriptEngineManager=createObject("java", "javax.script.ScriptEngineManager").init() and scriptEngineManager.getEngineByName("js") to work.
  I solved this by using Graal's polyglot engine instead.
• Frequent occurrence of the error messages "The eval method was not found" and "Access to language 'JS' is not permitted"
  Access problems persisted even after the move from javax.script.ScriptEngineManager to org.graalvm.polyglot.Context. This resulted from the fact that the class org.graalvm.polyglot.Context may be instantiated by means of a variety of methods. These range from the single create() to a chain such as newBuilder().allowHostAccess().allowIO().build().getBindings().putMember() 
  Researching and experimenting with the various combinations led to success eith 

  newBuilder(["js"]).allowAllAccess(true).allowIO(true).build()​

  You should yourself look into each of these methods if you're interested. You might come up with a more optimal solution than mine.

• Frequent occurrence of error message "java.nio.file.InvalidPathException: Illegal char <:> at index 2: /C:/ColdFusion2023/cfusion/lib/updates/chf20230012.jar"
  This is caused by the phenomenon of classpath isolation in GraalVM's polyglot engine.
  To fix this, apply the following JVM flag in ColdFusion's jvm.config:
  

  -Dpolyglotimpl.DisableClassPathIsolation=true​

• Frequent warning in the logs to configure runtime compilation for polyglot engine
  Apparently, without runtime compilation polyglot will use a fallback runtime. The fallback runtime does not support runtime compilation to native code, which will negatively impact performance of the guest application. To solve this, the GraalVM documentation recommends that you migrate to GraalVM or to a GraalVM-compatible JDK. That is impractical for our purposes, as ColdFusion 2023 is untested on GraalVM. Hence we resort to an alternative solution, namely, to suppress the warning and accept any temporary performance drop.
  To suppress the warning in ColdFusion's Java, use the JVM flag
  

  -Dpolyglot.engine.WarnInterpreterOnly=false​

  
  
  

[BKBK]

@Dordrecht , what are the values of 

local.firstData

and

local.secondData

in your code sample?

[BKBK]

@Dordrecht , Based on your code sample, I have created the following proof-of-concept. The JARs used and the setup are as described above

<cfset context=createObject("java", "org.graalvm.polyglot.Context").newBuilder(["js"]).allowAllAccess(true).allowIO(true).build()>

<!--- Data: two separate user structs --->
<cfset firstData={firstName:"Mary", firstEmail:"mary@domain.com", firstBlogUrl="https://www.mary.domain.blog"}>
<cfset secondData={secondName:"John", secondEmail:"john@domain.com", secondBlogUrl="https://www.john.domain.blog"}>

<!--- Convert each struct to a Javascript string --->
<cfset firstDataAsJSString=JSStringFormat(SerializeJSON(firstData))>
<cfset secondDataAsJSString=JSStringFormat(SerializeJSON(secondData))>

<!--- A JS script that merges two JSON objects into one --->
<cfsavecontent variable="jsRunStuff">
	<cfoutput>
		var myFirstData = JSON.parse('#firstDataAsJSString#');
		var mySecondData = JSON.parse('#secondDataAsJSString#');	
	</cfoutput>
	
	myFunction(myFirstData, mySecondData);
	
	// This funsion merges two struct objects into one 
	function myFunction (x, y) {return Object.assign(x, y);};
</cfsavecontent>

<!--- The result --->
<cfset value=context.eval("js",jsRunStuff) />

<cfoutput>#value#</cfoutput>

This example runs a JS script which takes two separate structs, each representing a distinct user, and combines them into one struct. 

[Dordrecht]

@BKBK, I'm sorry for the delay in responding. Work has been extremely busy.

I haven't been able to dive into what you have replied with above, but it looks amazing! I very much appreciate your significant efforts in providing assistance on this! I hope to be able to scan more through what you have written this week, and hopefully do a deeper dive next week. (The urgent for this scripting engine alternative has recently been somewhat lessened  - for now at least - but it is still very important, and my interest in digging in ASAP. Thank you!

[BKBK]

Hi @Dordrecht , Thank you for your kind words.

I wish you every success in your own research.

For now, I hope that I have answered both of your original questions:

1.   Is it possible to get the standalone Nashorn package into such a form that ColdFusion can use it, and how would you go about this?
2.  Can the GraalJS scripting engine duplicate what Nashorn did, and if so,  how can this be put into a ColdFusion-usable library or installation?

If your questions have been answered, then please mark the correct answer. That will help fellow developers who have a similar question. 

[Dordrecht]

@BKBK , I have started to go thorugh your solution. In step 4, immediately after running mvn dependency:copy-dependencies, I get the error "The JAVA_HOME environment variable is not defined correctly, this environment variable is needeed to run this program." I defined a new JAVA_HOME environment variable with value of C:\ColdFusion2023\jre and added %JAVA_HOME%\bin to the path. After doing this and then closing and reopening the command window, I was able to generate the necessary files. 

Subsequently I was able to follow the other instructions and get the square root example to work. I'm planning on working more on this in the coming days, and I'll report on how it is going. Thanks again!

[BKBK]

@Dordrecht , Thanks to you too for your update and for sharing what you found.