JavaOne 2010: Polygot Programming in the JVM

I was impressed with how Andres Almiray‘s performed as a substitute speaker for Hamlet D’Arcy‘s JavaOne 2010 presentation “Code Generation on the JVM” and looked forward to his presentation of his own talk: “Polygot Programming in the JVM: Or How I Learned to Stop Worrying and Love the JVM”. This session was my third session of the day in the same hotel (Parc 55)!

Almiray began by outlining his credentials and providing “some facts about Java” (see Java History 101: Once Upon an Oak). Almiray stated that while generics can be good, he doesn’t love them. Almiray explained that Java’s language syntax was designed to be attractive to developers in C/C++, which were the dominant languages of the day. This led to Java having more verbosity than it needs today.

After outlining some of Java’s history that have made it more challenging to use, Almiray transitioned into talking about using JVM languages other than Java to enjoy the benefits of JVM “without the pain of Java.”

The non-Java JVM languages tend to be more concise (less verbose) than Java. Almiray showed the common JavaBean example written in Java and said we have come to rely on IDEs because of the pain involved with writing these in Java. Almiray showed code for Groovy, Clojure, and Scala versions of the same JavaBean that had been written in Java originally.

Almiray moved from standard JavaBeans classes to coverage of closures. He pointed out that Java does not have closures and that Java developers commonly use anonymous inner classes to do the same thing. Java is supposed to get Lambda in a future version (JDK 8). Almiray the same proposed Java Lambda code with Groovy closures, Clojure closures, and Scala closures. In demonstrating these examples, Almiray reminded the audience that Groovy supports operator overloading and that Scala uses the val keyword to indicate a variable’s value cannot be changed.

Almiray’s next topic was “enhanced switch” which we might get in Java 7. He showed Groovy code switching on a range. In these examples, Almiray asked who likes to use regular expressions in Java.  There were no raised hands. One of Almiray’s examples showed use of Groovy’s ~ operator for regular expressions for a case to evaluate. Almiray went on to demonstrate the code for doing this with Scala and Clojure.

Almiray talked about one of my favorite features of Groovy: integration with Java without JSR 223. He stated that the same seamless two-way integration with Java is true of Clojure and Scala as well. Other things that these three alternative JVM languages have in common are operator overloading support, regular expressions “as first class citizens”, closures, everything as an object, and native syntax for collection classes.

On operator overloading, Almiray thinks that Scala has “gone over the top” because it allows developers to write any method they want to override any operator they want (he used ==== as an example). He contrasted this with Groovy which has a much smaller set.

Almiray went on to discuss each of the three alternative JVM languages advertised in his abstract on an individual basis. He stated that Groovy’s metaprogramming capability at buildtime and runtime attracted him to Groovy. He also likes the healthy Groovy ecosystem: Grails, Griffon, Gant (Groovy version of Ant), Gradle, Spock, Gaelyk (Google App Engine), Gpars (Groovy Parallel Systems), CodeNarc (code inspection), etc. Groovy was “born in 2003” and is about to celebrate its seventh birthday next month.

Scala’s syntax is different than Java’s/Groovy’s, but Scalar has a richer type system. Scala will not allow you to “put a square peg in a round hole.” Scala uses type inference and can use implicits to provide hints as to the type. Scala’s actor model deals with concurrency and threads. Almiray said that the Actor Model is not a silver bullet for concurrency, but is much better. Almiray also talked about Scala’s Traits, which support mixing in different behaviors.

Clojure, like all LISP variants, treats “data as code and vice versa.” Clojure provides immutable structures and Software Transactional Memory (STM). STM is also making its way into Scala. If STM is added to Java, it would be readily available in Groovy.

Almiray demonstrated a small example of all three of these alternative JVM languages working together. The name of the demonstrated software was appropriately named Babel. Almiray mixed this demonstration with views of the source code in the IDE. One thing I would not have realized is that the Scala Double is NOT the Java Double.

Almiray identified “other places you might find polygot development.”  Web development features many languages/formats: XML, SQL, JavaScript, JSON, CSS, Flash/Flex/ActionScript. We’re starting to see “Next-Gen Datastores (NoSQL)” (polygot persistence): FleetDB in Clojure, FlockDB in Scala, CouchDB and Riak in Erlang. Almiray stated that some people are starting to say that NoSQL is no longer “No SQL,” but is instead becoming “Not Just SQL.” Polygot build systems include Gradle/Gant for Groovy, Rake for Ruby/JRuby, and Maven 3 for XML/Groovy/Ruby.

Almiray believes that Java may have reached its maturity in terms of features. Clojure is “making a lot of noise” after being only three years old and Scala and Groovy were started in the 2000s. Although polygot programming has received more (and more favorable) press recently, it’s been around for quite some time. Almiray also referenced Stuart Halloway’s blog.

This entry was posted in JavaOne 2010, Syndicated. Bookmark the permalink.

Comments are closed.