Scripting Languages on the JVM

This year's JavaOne was unique in the number of sessions that had to do with scripting languages that run on the Java platform:

Scala

A very-clean java-like language that eliminates much of Java's verbosity. It's basically Lisp with Java syntax. Worth a look. For more: http://www.artima.com/scalazine/articles/steps.html

Groovy

An interpreted language that stays very close to Java, and which is reported to have settled down to the point that it has become usable.

JRuby

A very cool implementation of Ruby on the Java platform. Starts up Java apps without VM-initialization overhead, provides access to Java classes, installs with ease, and provides strong thread support: http://www.artima.com/weblogs/viewpost.jsp?thread=205140

JavaFX Script

A brand new language that aims to make it easy to develop dynamic web pages that run using the JVM in the browser.

Improved JRE Insallations

Sun's Ethan Nicholas gave a talk on upcoming improvments in the JRE installation and startup process. They were extensive:

• A new installer program with more graphics, way less text, and fewer clicks to get things done. It will be a lot less threatening to the average user.

• Updates will no longer create a new copy of the JRE, but will instead patch the existing version--so update releases will stop hogging all of the disk space in sight.

• Updates will happen much faster, as a result. But the initial install has been streamlined to go faster, as well, with a small initial module that downloads immediately and subsequent modules that download on demand or in the background.

• A toolkit for JRE deployment that includes a javascript file, browser plugins, and a standalone version, where the Javascript contains APIs useful for deployment:

  • getJREs(): find out which JREs are present
  • versionCheck(pattern): Use regular expressions to test for the existenc of some set of versions
  • installLatestJRE(): to "git 'er done"

  The javascript code also contains APIs to launch applets, test for the presence of Java Web Start, and create a Java Web Start launch button.

The current versions of the JRE support minimal versions of the useful behaviors. So today, you can only detect major versions (e.g. version 5). But starting in early 2008, the APIs will be fully supported, so you can determine exactly which version is on the end user's system.

Java Quick Start Service

When the JVM is already in memory (a warm start), it starts in a tenth of a second. Plenty fast. The problem is when it has to be read in from disk (a cold start). And reading the JVM into memory before you need it doesn't help--you make the user's system begin paging sooner than it otherwise would have, and it's likely to be paged out by the time you need it--so you're back to reading from disk.

The Java Quick Start service solves the problem by implementing a background process that reads from the disk every so often. That process puts the files in the disk cache, so that when the JVM is launched, it's doing a warm start. (But if memory is constrained, it disables itself so it does cause thrashing.)

It may be, too, that the same modularization that improves download speeds can be used to improve startup speed. With that system, the Java Kernel is just big enough to run HelloWorld, and other modules are brought in as needed or in a background process.

Java Modules

Speaking of modules, the new module system for Java will be pretty cool. A module will be a collection of packages in a "super jar", but:

• Some packages are public, others can be private
• Public packages can be public only in their jar
• Dependencies wil be managed, so there are no cyclic dependencies
• Different versions of a library can co-exist in the same VM
• They'll separate APIs from SPIs

A Service Provider Interface (SPI) is something the framework calls. It adds capabilities to the framework in the same way that an API adds capabilities to your application.

Interestingly, adding to an API preserves compatibility (the application never calls it), while removing from an SPI also preserves compatibility (the SPI doesn't see it, so it doesn't provide the additional functionality). So if SPIs and APIs both exist in the same class, there are no provably compatible changes you can make.

Best practice therfore suggests that APIs and SPIs should not only be in separate classes, they should be in separate packages. That way, users don't see things they don't care about, and they can more easily learn the interface by way of the IDE's code completion.

The module system aids and abets that separation, making it possible to expose module P to users, without exposing sub-package P.Q.

Java 7 Language and Tools

Peter von der Ahe, Jonthan Gibbons, and Alex Buckley held on BOF on Java 7 language features. The goal was to present a few ideas, gather some, and generally invite discussion.

As guideline for possible changes, Peter listed core language principles that are unlikely to change:

• Reading is more important than writing
• Simplicity matters
• One language, spoken the same everywhere
• Compatibility matters

Some of the possible features included:

• Abstraction: Something like closures that would keep you having nested try/finalies, for example when writing I/O code. The syntax might look like this:

  with (InputStream is: ... )
  with (OutputSrream os: .... ) {
    ...
  }
  

• Enhanced Switch Statement: Make it work with strings, and a coverage check when using enums, to identify gaps.

• Reified Generics: Getting rid of type erasure is on the table, so that types can be tested at runtime, and allowing arrays to safely use generic types. It would also allow for accurate reflection and serialization. The big issue for all that is retaining back compatibility.

The new workflow paths for the language now look like this (all three will be available through Mercurial):

• Stable Branch: Major releases like 5, 6, 7 (bug fixes)
• Development Branch: IDEs, GlassFish, JDK 7 until freeze (features)
• KSL branch: Kitchen Sink Language (experiments)

Some ideas were specifically disallowed for Java 7. They are features that may well be in the scripting languages that run on the Java platform, but they are inconsistent with the "prime directives" that Peter listed, so they are not on the table for the Java language:

• Dynamic typing
• Mixins / traits / multimethods / macros

Personal Note: Once a decade, I think it's time to cut the anchor cable and move forward without dragging all of the old stuff behind you. But there are many enterprises that would no doubt disagree with that idea, but the Java platform developers seem to have found ways to achieve similar objectives while still retaining compatibily. (One heck of an achivement, that.)

My list of desirable changes includes:

• A smaller JVM, minus the deprecated APIs, that starts faster and takes less memory. (But with the Quick Start option loading APIs in the background, the goal is achieved in a way that retains compatibility.)
• If arrays aren't type safe, I figured, toss them! Use the syntax for something like Ruby lists, instead. (But modifying the VM to support runtime types, while at the sam preserving compatibility (!) makes it possible to eliminate type erasure, make arrays safe, and still keep old apps running.)
• I'd also toss primitives, go with a pure OO syntax, and elminate the dozens of duplicate APIs that use them. (But auto-boxing means you no longer have to write them, at least. So maybe the background-loading principle of the Quick Start option and the API-separation principle of modules could be applied to classes--so you never have to load the code for those APIs, or even see them??? Probably not. But it seemed like a good thing to ask...)

Anyway, it looks as though the platform developers are figuring out ways to achive very important goals in ways that also preserver compatibility. Pretty darn clever.

Java 7 Tools

The language features session covered autmented tools capabilities, as well:

JSR 199: Compiler API

The compiler modifications let you use the javax.tools library to:

• invoke compilers and tools
• control how files are found
• give you access to diagnostics

JSR 269: Annotation Processing

With this JSR, APT is deprecated. You now get to use javac instead, which gives a full semantic model of a Java program (but not a syntactic one). The packages are:

javax.lang.model.*
javax.annotation.processing.*

Tree API

When you want a full syntactic model, the Tree API gives you the parse tree you need. It combines with compiler API and semantic model to give you access to the full source tree. The package isn't part of the standard, but it is a public API and use of it is encouraged:

com.sun.source.*

For someone who has been using the JavaDoc program as a poor man's parse-tree generator for quite a while now, the really good news from this session was:

• The new APIs designed to be very similar to the JavaDoc APIs
• The hope is that it will be possible to deprecate JavaDoc (A little bit of work still needs to be done, but's close.)

To take advantage of the new capabilities, Peter suggested that it would be a COOL PROJECT to use JackPot to transform a JavaDoc app into one that uses the new APIs. I couldn't agree more. (Race you!)

User Interface Testing with FEST

Orcacle developers Alex Ruiz and Yvonne Wang Price talked about an open source toolkit for GUI testing they've posted at Google:

FEST: Fixtures for Easy Software Testing, available at http://code.google.com/p/fest

The library is designed for functional testing of Swing apps. It presents a "fluent interface" that lets you write readable test, like:

xxx.shouldShowErrorMessage()

It's object oriented, so you're interating with a GUI object rather than poking an x,y location on screen real estate. That way, the tests are more robust--they don't suddenly start to fail when the layout changes-- something that can be a major problem when you're using test recorders that record your gestures.

Possibly the nicest thing about the system is that it takes a screenshot when a test fails--so if something failed because an Antivirus dialog popped up, for example, it would be easy to see that.

OpenID System

One of the Sun pods on the show floor was focused on identity management: "a decentralized, web-friendly single sign-on mechanism that allows consumers to reuse a single login across different websites."

For more: http://developers.sun.com/identity/

DITA Pod

Another pod at the conference centered around support for the DITA format on the JVM. I'm intrigued by the possibility of using DITA to carry on a structured discussion over the web, so it was interesting to find so many different content management systems, development frameworks, editors, and production systems running in the JVM.

For more on DITA's potential for structured discussions, see: http://www.artima.com/weblogs/viewpost.jsp?thread=202756

Writing a DSL in JRuby

Finally, there was a great session on writing DSLs in Ruby. (Coupled with the description of how to make a web app in Rails, that made two of the best tutorial-talks I've seen for Rails and Ruby, both at JavaOne!)

The talk listed all of the Ruby idioms that make it possible to construct a DSL. I was surprised to find that even with my limited use of the language, I was already familiar with them. So it seems that I do know enough to construct a DSL. But the bad news was that even after listening to the talk, I still didn't see how they all fit together.

So I've got some more work to this area. But at least now I can be confident that I'm prepared to tackle it. I'll get back to you when I've made some more progress. :_)