Thursday Dec 18, 2014

Node.js and io.js on Java

The Nashorn JavaScript engine is one of many improvements in JDK 8. Nashorn (German for Rhino) is a faster replacement for the previous JavaScript engine known as Rhino. There is also another noteworthy feature: the ability to run many Node.js and io.js applications in the JVM. These applications can then call back and forth between optimized Java libraries and automatically receive monitoring capabilities through JMX.

In the upcoming JDK 8 update 40, it is planned to improve Nashorn / JavaScript performance even further through optimistic typing.

Java Virtual Machine - More than just Java

The Java Platform offers a way to run different types of applications, even if those applications are not written in the Java programming language. As a result, developers can take advantage of optimizations and stability of the JVM, while system administrators can better control and monitor deployments.

Examples of other languages on the JVM include: JavaScript (Nashorn), Ruby (JRuby), Python (Jython), Scala, Groovy, and many others.

Project Avatar – A JavaScript services layer on the JVM

Avatar.js is a project to bring the node programming model, APIs and module ecosystem to the Java platform. Although written in JavaScript, these applications can take advantage of the Java platform's scalability, manageability, tools, and extensive collection of Java libraries and middleware. After downloading the Avatar.js binaries, developers can then execute their applications. For example, Tim Caswell’s article "Hello Node!" contains basic examples for hello-console.js and hello-http.js that can be used as a basic way for testing Avatar.

Nashorn, The Hidden Weapon of JDK 8 was presented at the Silicon Valley Java User Group meeting in December 2014. The available slides describe the use of Nashorn and Avatar at Netflix and provide additional Nashorn demos.

Avoid rewrites and re-use libraries

One major benefit of running serverside JavaScript applications within the JVM is access to Java libraries. Developers do not have to rewrite major libraries or functionality like SQL or NoSQL drivers, Hadoop clients, encoding libraries, etc. Additional examples are available in a previous post, Nashorn: the rhino in the room, but they are not specific to Node.js.

Niko Köbler has a two-part article about Avatar 2.0 and its Model Store API. By using this model store API, developers can more easily interact with SQL and No-SQL and benefit from many existing optimizations.

  1. Part 1 explains the architecture and threading model.
  2. Part 2 covers the technology behind the Model Store API.

Monitoring Applications on the JVM

All Java processes can be monitored through a mechanism called JMX. System Administrators can enable remote authenticated JMX connections and see inside these running applications, rather than monitoring from the outside coming in.

Additional details about JMX monitoring (both local and remote) can be found in a previous post, Deep Monitoring with JMX.

Monitoring applications with Mission Control / Flight Recorder

Java Flight Recorder is an effective way of monitoring JVM applications in production. Unlike standard development profilers (like the NetBeans profiler), Flight Recorder has negligible performance impact.

The dashboard view in Mission Control provides basic information about CPU and memory resources. Developers may use the Threads tab to better understand system throughput, or if the application is blocking around any particular resources.

To open Mission Control, run the jmc command and connect to your Avatar application. The screenshot below shows Mission Control monitoring a Node.js application identified as com.oracle.avatar.Server.

Monitoring Node.js on Java

Although the Node.js applications are written in JavaScript, Flight Recorder can also perform trigger-based recordings on events, such as a CPU spike. System Administrators and Developers can look back at the recording to see what lead up to the event.

Additional details are available on the Mission Control home page and user guide.

Additional ways of running Node.js on the JVM

Avatar is one of several ways to run Node.js applications on the JVM.

When run on Oracle Java, both projects can be monitored by Flight Recorder / Mission Control as described above. Because this monitoring is provided directly by the Oracle JVM itself, there is no need to make any code changes or apply additional monitoring packages.

Wednesday Jul 02, 2014

Diagnosing TLS, SSL, and HTTPS

When building inter-connected applications, developers frequently interact with TLS-enabled protocols like HTTPS. With recent emphasis on encrypted communications, I will cover the way in which the JDK evolves regarding protocols, algorithms, and changes, as well as some advanced diagnostics to better understand TLS connections like HTTPS.

Most developers will not have to do this level of diagnosis in the process of writing or running applications. In the event that you do, the following information should provide enough information to understand what's happening within secure connections.

Stability: The evolution of protocols and algorithms

For the last 15 years (since 1998), the Java platform has evolved through the Java Community Process where companies, organizations, and dedicated individuals develop and vote on specifications to determine what makes up the Java Platform. Much of the efforts are centered on compatibility, like the TCK, ensuring that different implementations are compatible with each-other and that developers can predict how their applications will run. We are not changing critical default options (like TLS protocol) within minor versions.

The following chart depicts the protocols and algorithms supported in each JDK version:


JDK 8
(March 2014 to present)
JDK 7
(July 2011 to present)
JDK 6
(2006 to end of public updates 2013)
TLS Protocols
TLSv1.2 (default)
TLSv1.1
TLSv1
SSLv3
TLSv1.2
TLSv1.1
TLSv1 (default)
SSLv3


TLSv1 (default)
SSLv3
JSSE Ciphers:
Ciphers in JDK 8
Ciphers in JDK 7
Ciphers in JDK 6
Reference:
JDK 8 JSSE JDK 7 JSSE JDK 6 JSSE
Java Cryptography Extension, Unlimited Strength (explained later)
JCE for JDK 8 JCE for JDK 7 JCE for JDK 6

Sample Java code for making an HTTPS connection

Making an HTTPS connection in Java is relatively straight-forward. I will post the code here with the intent focused on tuning and understanding the underlying capabilities.

Sample back-end code for making an SSL connection:

final URL url = new URL("https://example.com");
try(final InputStream in = url.openStream()){
  //…
}

Or the connection can be tuned through a cast:

final HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
//operate on conn
conn.connect();
try(final InputStream in = conn.getInputStream()){
  //…
}

Example: Qualys SSL Labs' "View My Client" Page

Qualys SSL Labs maintains a collection of tools that are helpful in understanding SSL/TLS connections. One in particular is a View My Client page, which will display information about the client connection. By integrating with that page, I was able to control the implementation as I used different Java tuning parameters.

To test parameter tuning, I implemented a small JavaFX application in JavaScript. It displays that page in a WebView, showing information about the underlying Java SSL/TLS client connection. You can find the code in the appendix.

JSSE Tuning Parameters

When diagnosing TLS-related issues, there are a number of helpful system properties. They are generally covered in their relevant sections of JSSE but this single collection may help anyone looking to understand the flexibility of Java’s implementation or diagnose connection details.

javax.net.debug
 Prints debugging details for connections made.
Example: -Djavax.net.debug=all or -Djavax.net.debug=ssl:handshake:verbose
https.protocols

Controls the protocol version used by Java clients which obtain https connections through use of the HttpsURLConnection class or via URL.openStream() operations. For older versions, this can update the default in case your Java 7 client wants to use TLS 1.2 as its default.
Example: -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2

For non-HTTP protocols, this can be controlled through the SocketFactory's SSLContext.

jdk.tls.client.protocols Introduced in JDK 8, this controls the underlying platform TLS implementation. Additional information is available in the JSSE Reference Guide.
Example: -Djdk.tls.client.protocols=TLSv1.1,TLSv1.2
http.agent
When initiating connections, Java will apply this as its user-agent string. Modifying this will handle cases where the receiving party responds differently based on the user-agent.
Example: -Dhttp.agent="known agent"
java.net.useSystemProxies
java.net.useSystemProxiesUse proxy details from the operating system itself.
Example: -Djava.net.useSystemProxies=true
http.proxyHost
http.proxyPort
The proxy connection to use for HTTP connections.
Example: -Dhttp.proxyHost=proxy.example.com -Dhttp.proxyPort=8080
https.proxyHost
https.proxyPort
The same as above, except that configuration is separate between HTTP and HTTPS.
http.proxyUser
http.proxyPassword
https.proxyUser
https.proxyPassword
Password-based credentials for the above proxies.

Many other protocols and properties can be found within the following areas:

Example of diagnosing a problem

When making an HTTPS connection, let’s assume that the client threw the following exception due to a failed handshake with the server:

 javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure 

SSLHandshakeException is a subclass of the IOException, so you do not need to catch is explicitly. Most developers will not need an explicit catch, but it may help you more easily diagnose the cause of any IOException.

When applying the -Djavax.net.debug=all property from above, the failure associated with this SSLHandshakeException would appear immediately after algorithm negotiation in the logs.

 JDK 7 (fails on unsupported algorithm) JDK 8 (works fine)
Cipher Suites: […Long list of ciphers…]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {…}
Extension ec_point_formats, formats: [uncompressed]
Extension server_name, server_name: [host_name: HOST]
***
main, WRITE: TLSv1 Handshake, length = 168
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT:  fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Cipher Suites: […Long list of ciphers…]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {…}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: …
Extension server_name, server_name: [type=host_name (0), value=HOST]
***
main, WRITE: TLSv1.2 Handshake, length = 226
main, READ: TLSv1.2 Handshake, length = 89
*** ServerHello, TLSv1.2
RandomCookie:  GMT: -1809079139 bytes = { …}
Session ID:  {…}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
***
%% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
** TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
main, READ: TLSv1.2 Handshake, length = 2308

In the case above, the failure occurred during the handshake. The most likely cause for that is algorithm support. The JDK provides a separate package called JCE Unlimited Strength, designed to add stronger algorithm support than what’s available by default. Qualys SSL Labs provides a different server SSL test that will enumerate which algorithms a server supports.

Many TLS error messages are covered in a few pieces of documentation:

Adding stronger algorithms: JCE Unlimited Strength

In a high security environment, one way of strengthening algorithms in the JDK is through the JCE Unlimited Strength policy files. In this particular case, replacing those policy files within JDK 7 allows it to use the stronger variants of existing algorithms and connect successfully.

JCE Unlimited Strength downloads: JDK 8, JDK 7, or JDK 6.

Appendix

The following code will open Qualys SSL Labs’ View My Client page within a Java client. To test configurations, run this like:

jjs -fx viewmyclient.js
jjs -fx -Dhttps.protocols=TLSv1 viewmyclient.js

var Scene = javafx.scene.Scene;
var WebView = javafx.scene.web.WebView;
var browser = new WebView();
browser.getEngine().load("https://ssllabs.com/ssltest/viewMyClient.html");
$STAGE.scene = new Scene(browser);
$STAGE.show();

Wednesday Jun 11, 2014

Nashorn, the rhino in the room

Nashorn is a new runtime within JDK 8 that allows developers to run code written in JavaScript and call back and forth with Java. One advantage to the Nashorn scripting engine is that is allows for quick prototyping of functionality or basic shell scripts that use Java libraries. The previous JavaScript runtime, named Rhino, was introduced in JDK 6 (released 2006, end of public updates Feb 2013). Keeping tradition amongst the global developer community, "Nashorn" is the German word for rhino.

The Java platform and runtime is an intentional home to many languages beyond the Java language itself. OpenJDK’s Da Vinci Machine helps coordinate work amongst language developers and tool designers and has helped different languages by introducing the Invoke Dynamic instruction in Java 7 (2011), which resulted in two major benefits: speeding up execution of dynamic code, and providing the groundwork for Java 8’s lambda executions. Many of these improvements are discussed at the JVM Language Summit, where language and tool designers get together to discuss experiences and issues related to building these complex components.

There are a number of benefits to running JavaScript applications on JDK 8’s Nashorn technology beyond writing scripts quickly:

  1. Interoperability with Java and JavaScript libraries.
  2. Scripts do not need to be compiled.
  3. Fast execution and multi-threading of JavaScript running in Java’s JRE.
  4. The ability to remotely debug applications using an IDE like NetBeans, Eclipse, or IntelliJ (instructions on the Nashorn blog).
  5. Automatic integration with Java monitoring tools, such as performance, health, and SIEM.

In the remainder of this blog post, I will explain how to use Nashorn and the benefit from those features.

Nashorn execution environment

The Nashorn scripting engine is included in all versions of Java SE 8, both the JDK and the JRE. Unlike Java code, scripts written in nashorn are interpreted and do not need to be compiled before execution.

Developers and users can access it in two ways:

  • Users running JavaScript applications can call the binary directly:
    jre8/bin/jjs
    • This mechanism can also be used in shell scripts by specifying a shebang like #!/usr/bin/jjs
  • Developers can use the API and obtain a ScriptEngine through:
    ScriptEngine engine = new ScriptEngineManager().getEngineByName("nashorn");
    • When using a ScriptEngine, please understand that they execute code. Avoid running untrusted scripts or passing in untrusted/unvalidated inputs. During compilation, consider isolating access to the ScriptEngine and using Type Annotations to only allow @Untainted String arguments.

One noteworthy difference between JavaScript executed in or outside of a web browser is that certain objects will not be available. For example when run outside a browser, there is no access to a document object or DOM tree. Other than that, all syntax, semantics, and capabilities are present.

Examples of Java and JavaScript

The Nashorn script engine allows developers of all experience levels the ability to write and run code that takes advantage of both languages. The specific dialect is ECMAScript 5.1 as identified by the User Guide and its standards definition through ECMA international.

In addition to the example below, Benjamin Winterberg has a very well written Java 8 Nashorn Tutorial that provides a large number of code samples in both languages.

Basic Operations

A basic Hello World application written to run on Nashorn would look like this:

#!/usr/bin/jjs
print("Hello World");

The first line is a standard script indication, so that Linux or Unix systems can run the script through Nashorn. On Windows where scripts are not as common, you would run the script like: jjs helloWorld.js.

Receiving Arguments

In order to receive program arguments your jjs invocation needs to use the -scripting flag and a double-dash to separate which arguments are for jjs and which are for the script itself:
jjs -scripting print.js -- "This will print"

#!/usr/bin/jjs
var whatYouSaid = $ARG.length==0 ? "You did not say anything" : $ARG[0]
print(whatYouSaid); 

Interoperability with Java libraries (including 3rd party dependencies)

Another goal of Nashorn was to allow for quick scriptable prototypes, allowing access into Java types and any libraries. Resources operate in the context of the script (either in-line with the script or as separate threads) so if you open network sockets and your script terminates, those sockets will be released and available for your next run.

Your code can access Java types the same as regular Java classes. The “import statements” are written somewhat differently to accommodate for language. There is a choice of two styles:

  1. For standard classes, just name the class: var ServerSocket = java.net.ServerSocket
  2. For arrays or other items, use Java.type: var ByteArray = Java.type("byte[]")
    You could technically do this for all.

The same technique will allow your script to use Java types from any library or 3rd party component and quickly prototype items.

Building a user interface

One major difference between JavaScript inside and outside of a web browser is the availability of a DOM object for rendering views. When run outside of the browser, JavaScript has full control to construct the entire user interface with pre-fabricated UI controls, charts, or components. The example below is a variation from the Nashorn and JavaFX guide to show how items work together.

Nashorn has a -fx flag to make the user interface components available. With the example script below, just specify: jjs -fx -scripting fx.js -- "My title"

#!/usr/bin/jjs -fx
var Button = javafx.scene.control.Button;
var StackPane = javafx.scene.layout.StackPane;
var Scene = javafx.scene.Scene;
var clickCounter=0;
$STAGE.title = $ARG.length>0 ? $ARG[0] : "You didn't provide a title";
var button = new Button();
button.text = "Say 'Hello World'";
button.onAction = myFunctionForButtonClicking;
var root = new StackPane();
root.children.add(button);
$STAGE.scene = new Scene(root, 300, 250);
$STAGE.show();
function myFunctionForButtonClicking(){
  var text = "Click Counter: " + clickCounter;
  button.setText(text);
  clickCounter++;
  print(text);
}

For a more advanced post on using Nashorn to build a high-performing UI, see JavaFX with Nashorn Canvas example.

Interoperable with frameworks like Node, Backbone, or Facebook React

The major benefit of any language is the interoperability gained by people and systems that can read, write, and use it for interactions. Because Nashorn is built for the ECMAScript specification, developers familiar with JavaScript frameworks can write their code and then have system administrators deploy and monitor the applications the same as any other Java application.

A number of projects are also running Node applications on Nashorn through Project Avatar and the supported modules.

In addition to the previously mentioned Nashorn tutorial, Benjamin has also written a post about Using Backbone.js with Nashorn.

To show the multi-language power of the Java Runtime, there is another interesting example that unites Facebook React and Clojure on JDK 8’s Nashorn.

Summary

Nashorn provides a simple and fast way of executing JavaScript applications and bridging between the best of each language. By making the full range of Java libraries to JavaScript applications, and the quick prototyping style of JavaScript to Java applications, developers are free to work as they see fit.

Software Architects and System Administrators can take advantage of one runtime and leverage any work that they have done to tune, monitor, and certify their systems.

Additional information is available within:

About

Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.

Search

Categories
Archives
« July 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today