Use case for Javascript engine in Java?

[Jason Ross]

I didn't know where else to ask this. Sorry admins if it's in the wrong place.

I understand that Nashorn is the new Javascript engine in Java8, and Rhino was in Java7. But I don't see any use case for having a JS engine in the Java. I've seen the demos of people doing "hello world" in JS and then running it in a basic Java command line app, but that's not a practical example.

Can anyone give me a scenario where it's useful to have a JS engine in the VM?

[Jesper de Jong]

I once used it in a project where our software needed to read files in some proprietary format, with a complicated structure in the file. The data in the file had to be transformed into a collection of Java objects in our software. The problem was that we got the input files from different companies, and the different companies would put their data into the files in slightly different ways. So, for the files comping from each company we had to perform slightly different logic to convert them correctly.

The client for whom we were writing this software wanted to be able to modify the business logic for each company without recompiling the code. So we added the possibility to run scripts on the data that was being read using the Java scripting engine. Now somebody how knew about the details could write a small piece of JavaScript (or in fact, a script written in any scripting language supported by the scripting engine) with special business rules.

But that's just one example out of my own experience.

JavaScript is sometimes used for server side code, for example using NodeJS you can write JavaScript webapps quickly and easily. (NodeJS is not written in Java, but you can imagine something like that written in Java).

[Jason Ross]

Thank you, Jesper. Is it considered "safe" to allow the client to do that?

[Ulf Dittmer]

I would imagine that there is a pretty tight security manager in place for code that comes from external sources. Or maybe the JavaScript is parsed before execution to make sure it contains no potentially dangerous operations.

[Jesper de Jong]

Jason Ross wrote:Thank you, Jesper. Is it considered "safe" to allow the client to do that?

That ofcourse entirely depends on what exactly you mean by "safe", who the client is, who the users of the software are etc. In that project I did, this software was only going to be used by a few technically-minded people inside the company I was developing it for, so there was no big need to put all kinds of security measures into it.

If your software is going to allow random people who can access your system through the Internet to run scripts, then ofcourse you would have to make sure that those scripts cannot do malicious things. Never allow random scripts to be executed on your server.

[Justin Musgrove]

Hey Jason,

We have a front end development team that started to use dust.js which is a js templating engine for prototypes and demos. It fits right into the fe dev stack/tools, close to logic less, and meshes with json well. A new project was started using java and wanted to reuse the templates that already have been developed so we needed to find a way to render those templates on the server. Writing a light piece of code we converted our java objects to json and then render the dust template in rhino.

I wrote up how you could do it using nashorn which feels like a lot of work but not all that bad.
http://www.leveluplunch.com/blog/2014/06/09/compile-load-render-dustjs-template-java-nashorn/

Hope this helps.

[Rahul Mahindrakar]

Hi

If it helps and you have not seen this, here is a long list of cases

http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html

[Rahul Mahindrakar]

One simple case would be a bit primitive but lets say you have written a javascript validation on a web page and the user submits the page.

If you would need to do a server side check then you will need to implement a similar validation rule onthe server side in Java.

However with Nashhorn it seems that now we can reuse the same validation as written in Javascript.

Another would be for example stated as given earlier that there are many javascript frameworks doing much stuff on the front end. If you wish to reuse that in Java that would be problamatic. But with Nashhorn this is now possible.

[Ulf Dittmer]

However with Nashhorn it seems that now we can reuse the same validation as written in Javascript.

Hm... I don't think I'd want to resort to JavaScript for that, with all the language and context switching that entails. Most web frameworks have validation anyway built in.

Another would be for example stated as given earlier that there are many javascript frameworks doing much stuff on the front end. If you wish to reuse that in Java that would be problamatic. But with Nashhorn this is now possible.

I don't think too much of that code would be reusable, given how it's meant to run inside a browser, but I could be wrong about that. In that respect, Nashorn doesn't add anything new, though - the quite capable Rhino JavaScript implementation has been around for 15+ years, the last 10 even included in the JRE via the javax.script API.

I think major applications will be scriptability and customizability of applications (both client and server). Client is not very relevant these days, but having the ability to implement certain parts of server side code as JavaScript facilitates easy changeability at runtime. That could either be core parts of the business logic, or extension points for future changes.

[Rahul Mahindrakar]

Hi

yes that correct in many ways. But i was just stating some simple case.

if you look at listing 7 in the link it shows what i meant with using javascript frameworks within java.

[Nimit Shah]

One of the use case that I can see is, if you are developing a tool like soap ui.
SoapUI allows user to provide a script in groovy or javascript.