This content is part of the Essential Guide: JavaOne 2014: Takeaways from Java's biggest conference
Get started Bring yourself up to speed with our introductory content.

Understanding the new Nashorn

At JavaOne 2014, discussion turned to the creation and upgrades of the compiler engine called 'Nashorn.'

Technical architects and software developers have been looking at the JavaScript processing features built into Java to create a unified Java programming architecture for their organization. In Java EE 6, this was done with the Rhino JavaScript compiler. Java EE 8 included a new compiler engine called Nashorn that mostly provides faster performance and much better security, said Jim Laskey, multi-language lead at Oracle.

The first version of Nashorn, shipped in March 2013, added code cache and features for speeding up the execution of JavaScript code. An upcoming version, expected in February 2015, will increase compatibility with ECMAScript.

Better performance and security

Improving JavaScript performance was the key reason for driving the creation of Nashorn. Rhino had been around for several years and was starting to show its age. Laskey said that security was another key driver for Nashorn, since Rhino was vulnerable to many Java exploits. To address these security concerns, only public methods are accessible via Nashorn-compiled JavaScript code. These applications are not able to access internal methods, even for internal packages.

Laskey said that Rhino contained some cruft because it had been around since 1995. Hackers looking for vulnerable classes for security cases that had not been considered when Rhino was released could find them in Rhino. Secure frames in Nashorn's stack help limit the kind of classes that hackers have access to.

Getting the most from multiple threads

At the JavaOne conference, lead developers from companies like LinkedIn, Parse and Texas Instruments discussed some of the challenges and opportunities for leveraging Nashorn to improve the use of JavaScript for building back-end server applications. While in general, Nashorn performance is superior to Rhino's, there are a few challenges to consider. A lead developer at LinkedIn noted that while Nashorn performance is superior, there are some unexpected performance challenges around loading modules from a JavaScript file.

Laskey said some of these problems can be addressed with context to create separate bindings. Another solution is to load modules with new global context. This was primarily implemented because the Nashorn team wanted to create new threads and have processes isolated on the threads. There is no such thing as multi-threaded JavaScript engines yet, but Java enables isolation of processes across nodes. Typically, the structure of an application can be spread across multiple threads, but some threads, such as those used for generating graphics, need to be queued up to run later in order to receive input from the other threads running in parallel.

Slow warm-up

The LinkedIn developer also noted that performance is a little slow when an application is first warming up. Laskey said that the current version of Nashorn has some limits on code caching, which were not implemented for safety reasons. The team did not want developers to rely too heavily on this kind of capability until the bugs have been worked out. There are concerns about some of the possible side effects around clearing the cache over long periods of time.

One of the options in Rhino was for precompiling JavaScript. But this was based on the notion that the whole script would be compiled in one pass. The Nashorn team took the approach that they could get better performance on a per-function basis for functions that were used more frequently. The idea of trying to optimize the whole script makes less sense because the application will see less improvement from optimizing functions that are not called as often. Marcus Lagergren, runtime futurist at Oracle, said that while some functions might not be as optimized, the net result is that the peak performance of the application should outperform what was possible with Rhino.

Cryptic mirrors

Another problem that early Nashorn developers have run into is cryptic error messages around script object mirrors. Laskey said this was due to a decision to protect objects being instantiated globally. There were several approaches they could have taken, but the Nashorn team settled on creating script mirror wrappers for JavaScript objects. When these are passed in the same context, the wrapper gets stripped away.

These types of errors sometimes occur when a call is made out from the JavaScript application and then returned on a different thread. Laskey said that an array of objects can be implemented to overcome these types of errors.

Input, benchmarks and stories encouraged

In general, enterprises are starting to leverage JavaScript capabilities on top of Java more widely, said Laskey, but these tend to be hidden in various nooks and not widely publicized. He said they kind of skipped a step in releasing Nashorn around collating more user stories on the different ways it is being deployed across organizations. They welcome any user stories on the Nashorn blog so other companies and developers and architects in general can see how Nashorn can improve the software development lifecycle.

A lead developer for Parse noted that many development shops are starting to leverage NodeJS, and he believes that Nashorn may provide a viable option for organizations that want an architecture that is better integrated with Java.

The five-member Nashorn team is small and focused enough that they are able to respond to ideas and suggestions, said Oracle's Lagergren. He said they welcome any code submissions, and are also interested in new benchmarking tests in order to identify and characterize opportunity for specific improvement. Nashorn performance really shines when it comes to database processing, which is not well-characterized by some of the standard JavaScript benchmarking suites created for the V8 JavaScript engine. Nashorn also allows enterprises to leverage Java's superior WebSockets libraries, which have been tuned for good performance.

Developers interested in better understanding some of the technical issues around implementing Nashorn should check out the blog. Laskey said they are quite open to guest posts from developers who have been using the technology.

Dig Deeper on Java ALM

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.