Saturday Apr 06, 2013

To Shell Or Not To Shell

I find myself facing a dilemma today. How should I use Java FX from Nashorn? So far, I have two approaches I could use, but each comes with some issues. Some background first.

Java FX, even though ships with the JDK, is on a different build cycle and has dependencies on elements of the JDK. This arraignment limits Nashorn, which is part of the JDK, from actually having dependencies into Java FX. But, there is a dependency requirement to implement a Java FX application. Java FX applications begin with a subclass instance of javafx.application.Application. Therefore, whatever choice is made, it has to be independent of the JDK (at some point should be part of Java FX.)

The first approach, in general terms, is the easiest to use. It involves using a predefined shell that is similar to jjs but handles the overrides of Application methods init, start and finish. The source of this shell is currently checked into the Nashorn repo under nashorn/tools/fxshell.

 * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved.
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.  Oracle designates this
 * particular file as subject to the "Classpath" exception as provided
 * by Oracle in the LICENSE file that accompanied this code.
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit if you need additional information or have any
 * questions.
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.logging.Level;
import java.util.logging.Logger;
import javafx.application.Application;
import javafx.stage.Stage;
import javax.script.Invocable;
import javax.script.ScriptContext;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineFactory;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;
import jdk.nashorn.api.scripting.NashornScriptEngineFactory;
 * This shell is designed to launch a JavaFX application written in Nashorn JavaScript.
public class FXShell extends Application {
     * Script engine manager to search.
    private ScriptEngineManager manager;
     * Nashorn script engine factory.
    private NashornScriptEngineFactory factory;
     * Main instance of Nashorn script engine.
    private ScriptEngine engine;
     * Needed so that the FX launcher can create an instance of this class.
    public FXShell() {
     * Main entry point. Never actually used.
     * @param args Command line arguments.
    public static void main(String[] args) {
     * Application overrides.
    public void init() throws Exception {
        // Script engine manager to search.
        this.manager = new ScriptEngineManager();
        // Locate the Nashorn script engine factory.  Needed for passing arguments.
        for (ScriptEngineFactory engineFactory : this.manager.getEngineFactories()) {
             if (engineFactory.getEngineName().equals("Oracle Nashorn") &&
                 engineFactory instanceof NashornScriptEngineFactory) {
                this.factory = (NashornScriptEngineFactory)engineFactory;
        // If none located.
        if (this.factory == null) {
            System.err.println("Nashorn script engine not available");
        // Get the command line and JNLP parameters.
        final Parameters parameters = getParameters();
        // To collect the script paths and command line arguments.
        final List<String> paths = new ArrayList<>();
        final List<String> args = new ArrayList<>();
        // Pull out relevant JNLP named parameters.
        final Map<String, String> named = parameters.getNamed();
        for (Map.Entry<String, String> entry : named.entrySet()) {
            final String key = entry.getKey();
            final String value = entry.getValue();
            if ((key.equals("cp") || key.equals("classpath")) && value != null) {
            } else if (key.equals("source") && value != null &&
                       value.toLowerCase().endsWith(".js")) {
        // Pull out relevant command line arguments.
        boolean addNextArg = false;
        boolean addAllArgs = false;
        for (String parameter : parameters.getUnnamed()) {
            if (addAllArgs || addNextArg) {
                addNextArg = false;
            } else if (parameter.equals("--")) {
                addAllArgs = true;
            } else if (parameter.startsWith("-")) {
                addNextArg = parameter.equals("-cp") || parameter.equals("-classpath");
            } else if (parameter.toLowerCase().endsWith(".js")) {
        // Create a Nashorn script engine with specified arguments.
        engine = factory.getScriptEngine(args.toArray(new String[args.size()]));
        // Load initial scripts.
        for (String path : paths) {
        // Invoke users JavaScript init function if present.
        try {
            ((Invocable) engine).invokeFunction("init");
        } catch (NoSuchMethodException ex) {
            // Presence of init is optional.
    public void start(Stage stage) throws Exception {
        // Invoke users JavaScript start function if present.
        try {
            ((Invocable) engine).invokeFunction("start", stage);
        } catch (NoSuchMethodException ex) {
            // Presence of start is optional.
    public void stop() throws Exception {
        // Invoke users JavaScript stop function if present.
        try {
            ((Invocable) engine).invokeFunction("stop");
        } catch (NoSuchMethodException ex) {
            // Presence of stop is optional.
     * Load and evaluate the specified JavaScript file.
     * @param path Path to UTF-8 encoded JavaScript file.
     * @return Last evaluation result (discarded.)
    private Object load(String path) {
        try {
            FileInputStream file = new FileInputStream(path);
            InputStreamReader input = new InputStreamReader(file, "UTF-8");
            return engine.eval(input);
        } catch (FileNotFoundException | UnsupportedEncodingException | ScriptException ex) {
        return null;

To built it you can (cd make ; ant build-fxshell) from within the nashorn repo. The result is in nashorn/dist/nashornfx.jar. To use just java -cp dist/nashornfx.jar <myscript.js> … . For the JDK savvy you can create a launcher by modelling an entry in jdk/makefiles/CompileLaunchers.gmk after the jjs entry.

The big plus for this approach is that it handles almost everything for you. You just have to define a start method with a few class declarations and that is it. The down side is that ideally you would want this implemented as a jjsfx launcher embedded in the JDK. But then we run into the chicken and egg dependency on Java FX.

The second approach only relies on jjs. With a recent modification to Java.extend (currently only in the nashorn forest), it is now possible to subclass javafx.application.Application. and thus launch from within a script. This sounds like all pluses except for the fact you have to wrap your brain around the fact that FX applications take control of execution and has static init dependencies that require careful use in your program.

I prototyped a simple fxinit.js include that shows how we could implement such a scheme. Ignore the implementation quirks. It's simpler than it seems.

GLOBAL = this;
javafx = Packages.javafx;
(Java.extend(javafx.application.Application, {
    init: function() {
        // FX packages and classes must be defined here because they may not be
        // viable until launch time.
        Stage          = javafx.stage.Stage;
        scene          = javafx.scene;
        Scene          = scene.Scene;
        Group          = scene.Group;
        chart          = scene.chart;
        control        = scene.control;
        Button         = control.Button;
        StackPane      = scene.layout.StackPane;
        FXCollections  = javafx.collections.FXCollections;
        ObservableList = javafx.collections.ObservableList;
        Chart          = chart.Chart;
        CategoryAxis   = chart.CategoryAxis;
        NumberAxis     = chart.NumberAxis;
        BarChart       = chart.BarChart;
        XYChart        = chart.XYChart;
        Series         = chart.XYChart$Series;
        Data           = chart.XYChart$Data;
        TreeView       = control.TreeView;
        TreeItem       = control.TreeItem;
        if (GLOBAL.init) {
    start: function(stage) {
        if (GLOBAL.start) {
    stop: function() {
        if (GLOBAL.stop) {
})).class, new (Java.type("java.lang.String[]"))(0));

How you would use it is straight forward. Here is the FX example written for Nashorn;

function start(stage) {
    stage.title = "Hello World!";
    var button = new Button();
    button.text = "Say 'Hello World'";
    button.onAction = function() print("Hello World!");
    var root = new StackPane();
    stage.scene = new Scene(root, 300, 250);;
Note the placement of the load("fxinit.js");. Since this is where the FX Application takes control, anything after the load will not complete until the application exits.

One other quirk. Since you can not static init some of Java FX classes until after the application launches. You can not globally (script level) declare any uses of these classes. Uses can be embedded in methods used after the launch, but no where else. This is a style cramp for me.

There is a third approach I have been considering. It involves some argument trickery, but may play out as a better way of doing things. Imagine jjs fxinit.js -- myscript.js -- my scripts args . The -- indicates the beginning of arguments passed to the script. The notion here is that fxinit.js launches the application and then evals myscript.js. This cleanses my script of any quirks, while putting the onus on getting the command line right.


Friday Feb 08, 2013

CSI: Nashorn - Shell Scripting in JavaScript, WAT?

I was reading the article in The Register with the heading GNOME project picks JavaScript as sole app dev language, when I remembered that we haven't said much about shell scripting using Nashorn.

This may seem sacrilegious to both JavaScripters and shell scripters, but think about it. The features that make JavaScript good for browser support are similar to what is needed for shell scripting. Plus you have access to all those Java libraries, and JavaFX, wink, wink, nudge, nudge (think visualization.)

There is an option (-scripting) in the Nashorn engine that extends the JavaScript language with features that make JavaScript very useful for writing shell scripts (even shebang scripts.) These features include;
  • function $EXEC("command args", "input"); that executes a command string as a separate process with handling of stdin, stdout $OUT, stderr $ERR and exit code $EXIT,
  • an exec string `command args` syntax for simple execution,
  • edit strings for embedding expressions in a double quote or exec strings, single quote strings are always unedited,
  • here strings, with editing for multi-line strings, <<TAG…TAG for include end of line and <<<TAG…TAG for exclude end of line,
  • environment variable $ENV for access to shell variables,
  • access to command line arguments with $ARG,
  • exit(code) and quit() for terminating the script,
  • and, # style comments
I will submit more scripting examples in the future, but let's start off with the following teaser.

Fingerprinting Source Code 

Often enough, when we are working on Nashorn, we run across some source that is unfamiliar and we would like to discuss the code with the original author. This is sometimes called blaming, but really, it's just about getting up to speed on the code without a lot of pain and suffering.  Nashorn is stored in a Mercurial repository on Mercurial already supports basic change set annotation of source, but sometimes you just want to cut to the chase and get the full details of a specific source line.

The following shell script, suspect, takes a root source file name and a line number, and then displays the change set information associated with the source line.

# This script hunts down the change set associated with a
# source file and a line number.

// Report proper command usage.
function usage() {
usage: suspect javaFileName lineNumber
    javaFileName - name of file in local mercurial repository
    lineNumber   - file line number

// Report on stderr.
function error(message) {

// Provide meaningful names for arguments.
var fileName   = $ARG[0];
var lineNumber = $ARG[1];

// If arguments are missing, report proper usage.
if (!fileName || !lineNumber) {

// Add .java if not present.
if (!fileName.endsWith(".java")) {
    fileName += ".java";

// Search for matching files and convert the result to an array of paths.
var where = `find . -name ${fileName}`.trim().split("\n");

// If not found
if (where == "") {
    error("File ${fileName} is not in the current repository.\n");
} else if (where.length != 1) {
    error("File ${fileName} found in multiple locations\n${where.join('\n')}\n");

// Get the source annotated with change set number.
var annotated = `hg annotate -c ${where}`.split("\n");

// Get the target source line.
var line = annotated[lineNumber];

// Make sure the line exists.
if (!line) {
    error("File ${fileName} does not contain line number ${lineNumber}\n");

// Extract the revision number.
var revision = line.substring(0, 12);

// Report the change set information from the revision number.
print(`hg log -r ${revision}`);

If I wanted to find out about the changed set for line 63 of,

>> suspect SpillProperty 63
changeset:   2:da1e581c933b
user:        jlaskey
date:        Fri Dec 21 16:36:24 2012 -0400
summary:     8005403: Open-source Nashorn

This is just the beginning.

Friday Dec 21, 2012

Open For Business

After a lot of blood, sweat and tears, we finally got Nashorn into OpenJDK.

hg fclone nashorn~jdk8

or for just Nashorn

hg clone nashorn

 More details about the tools you'll need and using OpenJDK are at

This is just the first drop and needs some larger integration work, but you can browse the source, build and play.  Be sure to read the README and RELEASE_README,  If you have any questions or issues please send them along to .  Responses may be a little slow over the holidays, but we will respond.

Friday Dec 07, 2012

The Vote Is In

Just got the following e-mail.  Gonna be busy next week.

Voting on the Nashorn Project with initial Lead Jim Laskey [1] is


Yes:  20
Veto:  0
Abstain:  0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the new Project and its initial Lead.

-John Coomes


Saturday Dec 01, 2012

Nashorn in the Twitterverse, Continued

After doing the Twitter example, it seemed reasonable to try graphing the result with JavaFX.  At this time the Nashorn project doesn't have a JavaFX shell, so we have to go through some hoops to create an JavaFX application.  I thought showing you some of those hoops might give you some idea about what you can do mixing Nashorn and Java (we'll add a JavaFX shell to the todo list.)

First, let's look at the meat of the application.  Here is the repackaged version of the original twitter example.

var twitter4j      = Packages.twitter4j;
var TwitterFactory = twitter4j.TwitterFactory;
var Query          = twitter4j.Query;

function getTrendingData() {
    var twitter = new TwitterFactory().instance;
    var query   = new Query("nashorn OR nashornjs");
    query.count = 100;
    var data = {};

    do {
        var result =;
        var tweets = result.tweets;
        for each (var tweet in tweets) {
            var date = tweet.createdAt;
            var key = (1900 + date.year) + "/" +
                      (1 + date.month) + "/" +
            data[key] = (data[key] || 0) + 1;
    } while (query = result.nextQuery());

    return data;

Instead of just printing out tweets, getTrendingData tallies "tweets per date" during the sample period (since "2012-11-21", the date "New Project: Nashorn" was posted.)   getTrendingData then returns the resulting tally object.

Next, use JavaFX BarChart to display that data.

var javafx         = Packages.javafx;
var Stage          = javafx.stage.Stage
var Scene          = javafx.scene.Scene;
var Group          = javafx.scene.Group;
var Chart          = javafx.scene.chart.Chart;
var FXCollections  = javafx.collections.FXCollections;
var ObservableList = javafx.collections.ObservableList;
var CategoryAxis   = javafx.scene.chart.CategoryAxis;
var NumberAxis     = javafx.scene.chart.NumberAxis;
var BarChart       = javafx.scene.chart.BarChart;
var XYChart        = javafx.scene.chart.XYChart;
var Series         = javafx.scene.chart.XYChart.Series;
var Data           = javafx.scene.chart.XYChart.Data;

function graph(stage, data) {
    var root = new Group();
    stage.scene = new Scene(root);
    var dates = Object.keys(data);
    var xAxis = new CategoryAxis();
    xAxis.categories = FXCollections.observableArrayList(dates);
    var yAxis = new NumberAxis("Tweets", 0.0, 200.0, 50.0);
    var series = FXCollections.observableArrayList();
    for (var date in data) {
        series.add(new Data(date, data[date]));
    var tweets = new Series("Tweets", series);
    var barChartData = FXCollections.observableArrayList(tweets);
    var chart = new BarChart(xAxis, yAxis, barChartData, 25.0);

I should point out that there is a lot of subtlety in this sample.  For example;
stage.scene = new Scene(root) is equivalent to stage.setScene(new Scene(root)). If Nashorn can't find a property (scene), then it searches (via Dynalink) for the Java Beans equivalent (setScene.)  Also note, that Nashorn is magically handling the generic class FXCollections.  Finally,  with the call to observableArrayList(dates), Nashorn is automatically converting the JavaScript array dates to a Java collection.  It really is hard to identify which objects are JavaScript and which are Java.  Does it really matter?

Okay, with the meat out of the way, let's talk about the hoops.

When working with JavaFX, you start with a main subclass of javafx.application.Application.  This class handles the initialization of the JavaFX libraries and the event processing.  This is what I used for this example;

import javafx.application.Application;
import javafx.stage.Stage;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;

public class TrendingMain extends Application {

    private static final ScriptEngineManager
                                        MANAGER = new ScriptEngineManager();
    private final ScriptEngine engine = MANAGER.getEngineByName("nashorn");
    private Trending trending;

    public static void main(String[] args) {

    public void start(Stage stage) throws Exception {
        trending = (Trending) load("Trending.js");

    public void stop() throws Exception {

    private Object load(String script) throws IOException, ScriptException {
         try (final InputStream is = TrendingMain.class.getResourceAsStream(script)) {
            return engine.eval(new InputStreamReader(is, "utf-8"));
To initialize Nashorn, we use JSR-223's javax.script. 

private static final ScriptEngineManager MANAGER = new ScriptEngineManager();
private final ScriptEngine engine = MANAGER.getEngineByName("nashorn");

This code sets up an instance of the Nashorn engine for evaluating scripts.

The  load method reads a script into memory and then gets engine to eval that script.  Note, that load also returns the result of the eval.

Now for the fun part.  There are several different approaches we could use to communicate between the Java main and the script.  In this example we'll use a Java interface.  The JavaFX main needs to do at least start and stop, so the following will suffice as an interface;

public interface Trending {
    public void start(Stage stage) throws Exception;
    public void stop() throws Exception;

At the end of the example's script we add;

function newTrending() {
    return new Packages.Trending() {
        start: function(stage) {
            var data = getTrendingData();
            graph(stage, data);

        stop: function() {



which instantiates a new subclass instance of Trending and overrides the start and stop methods.  The result of this function call is what is returned to main via the eval.

trending = (Trending) load("Trending.js");

To recap, the script Trending.js contains functions getTrendingData, graph and newTrending, plus the call at the end to newTrending.  Back in the Java code, we cast the result of the eval (call to newTrending) to Trending, thus, we end up with an object that we can then use to call back into the script. 



Thursday Nov 29, 2012

Nashorn in the Twitterverse

I have been following how often Nashorn has been showing up on the net.  Nashorn got a burst of tweets when we announced Project Nashorn and I was curious how Nashorn was trending per day, maybe graph the result.  Counting tweets manually seemed mindless, so why not write a program to do the same.

This is where Nashorn + Java came shining through.  There is a very nice Java library out there called Twitter4J that handles all things Twitter.  After running bin/ to get a file with personal authorization, all I had to do to run my simple exploratory app was;

nashorn -cp $TWITTER4J/twitter4j-core-3.0.1.jar GetHomeTimeline.js

The content of GetHomeTimeline.js is as follows;

var twitter4j      = Packages.twitter4j;
var TwitterFactory = twitter4j.TwitterFactory;
var Query          = twitter4j.Query;

var twitter = new TwitterFactory().instance;
var query   = new Query("nashorn OR nashornjs");
query.count = 100;

do {
    var result =;
    var tweets = result.tweets;

    for each (tweet in tweets) {
        print("@" + tweet.user.screenName + "\t" + tweet.text);
} while (query = result.nextQuery());

How easy was that?  Now to hook it up to the JavaFX graphing library... 

Monday Nov 26, 2012

Request for Project Nashorn (Open Source)

The request went out to the OpenJDK community last Thursday (November 22, 2012) for Project Nashorn. The deadline for voting is midnight December 6, 2012 UTC. If all goes well, we hope to have all the bits in the OpenJDK in time for all to play with during the holiday period. Fingers crossed.

Wednesday Oct 10, 2012

Welcome To The Nashorn Blog

Welcome to all.  Time to break the ice and instantiate The Nashorn Blog.  I hope to contribute routinely, but we are very busy, at this point, preparing for the next development milestone and, of course, getting ready for open source. So, if there are long gaps between postings please forgive.

We're just coming back from JavaOne and are stoked by the positive response to all the Nashorn sessions. It was great for the team to have the front and centre slide from Georges Saab early in the keynote. It seems we have support coming from all directions.

Most of the session videos are posted. Check out the links.

Nashorn: Optimizing JavaScript and Dynamic Language Execution on the JVMUnfortunately, Marcus - the code generation juggernaut,  got saddled with the first session of the first day. Still, he had a decent turnout. The talk focused on issues relating to optimizations we did to get good performance from the JVM. Much yet to be done but looking good.

Nashorn: JavaScript on the JVM. This was the main talk about Nashorn. I delivered the little bit of this and a little bit of that session with an overview, a follow up on the open source announcement, a run through a few of the Nashorn features and some demos. The room was SRO, about 250±. High points: Sam Pullara, from Twitter, came forward to describe how painless it was to get Mustache.js up and running (20x over Rhino), and,  John Ceccarelli, from NetBeans came forward to describe how Nashorn has become an integral part of Netbeans. A healthy Q & A at the end was very encouraging.

Meet the Nashorn JavaScript Team. Michel, Attila, Marcus and myself hosted a Q & A. There was only a handful of people in the room (we assume it was because of a conflicting session ;-) .) Most of the questions centred around Node.jar, which leads me to believe, Nashorn + Node.jar is what has the most interest. Akhil, Mr. Node.jar, sitting in the audience, fielded the Node.jar questions.

Nashorn, Node, and Java Persistence. Doug Clarke, Akhil and myself, discussed the title topics, followed by a lengthy Q & A (security had to hustle us out.) 80 or so in the room. Lots of questions about Node.jar. It was great to see Doug's use of Nashorn + JPA. Nashorn in action, with such elegance and grace.

Putting the Metaobject Protocol to Work: Nashorn’s Java Bindings. Attila discussed how he applied Dynalink to Nashorn. Good turn out for this session as well. I have a feeling that once people discover and embrace this hidden gem, great things will happen for all languages running on the JVM.

Finally, there were quite a few JavaOne sessions that focused on non-Java languages and their impact on the JVM. I've always believed that one's tool belt should carry a variety of programming languages, not just for domain/task applicability, but also to enhance your thinking and approaches to problem solving.

For the most part, future blog entries will focus on 'how to' in Nashorn, but if you have any suggestions for topics you want discussed, please drop a line. 


Raging Red Rhino


Technical discussions and status of the Nashorn JavaScript Project.


« April 2015