JVMOne

This morning, my co-worker Jason Swartz had the great idea of a conference focussing on JVM languages. This seemed like a particularly good idea, given the uncertainty surrounding JavaOne. Personally, I think the JavaOne powers-that-be have done a good job showcasing other languages, especially the last two years. Anyways, I joked that we could probably host it at our north campus, since it has proper facilities and regularly hosts medium sized conferences,  and that we just needed the support of folks from the Groovy, JRuby, Scala, and Clojure communities. A lot of folks seemed to like the idea, and had some great feedback/questions. So let me phrase some of these questions in the context of "a JavaOne-ish replacement, focussing on alternative languages on the JVM, but ultimately driven by the community". Ok here are some of the questions.

1.) What about Java?
2.) What about languages other than Groovy, JRuby, Scala, and Clojure?
3.) What about first class technologies with their roots in Java, like Hadoop, Cassandra, etc.?

Certainly I have opinions on some of these, but obviously any kind of effort like this requires huge participation from the developer community. So what do you think? What other questions need to be asked? If there is enough interest, I will definitely try to organize it. So please leave comments below!

Metaprogramming in Groovy and Scala

This morning I read an excellent pair of articles by Scott Davis on metaprogramming in Groovy. It reminded me of some of the different ways to approach this kind of problem. The second article in particular detailed a new feature in Groovy 1.6, the delegate annotation. Here is an example of using this feature:

public class Monkey {
 def eatBananas(){
   println("gobble gulp")
 }
}

public class RoboMonkey{
 @Delegate final Monkey monkey
 public RoboMonkey(Monkey m){
   this.monkey = m
 }
 public RoboMonkey(){
   this.monkey = new Monkey()
 }
 def crushCars(){
   println("smash")
 }
}

This allows for the following usage:

def monkey = new RoboMonkey()
monkey.eatBananas()
monkey.crushCars()

What is interesting here is that you cannot just create a Monkey and call crushCars on it. RoboMonkey is meant to be a way to add functionality to the Monkey class (in this case the crushCars method), while still being able to treat the RoboMonkey as if it was a Monkey. I point this out because of how this would be done in Scala:

class Monkey{
  def eatBanaas = println("gobble gulp")
}

class RoboMonkey(val monkey:Monkey){
  def this() = this(new Monkey)
  def crushCars = println("smash")
}

object Monkey{
  implicit def makeRobo(monkey:Monkey):RoboMonkey = new RoboMonkey(monkey)
  implicit def makeNormal(robo:RoboMonkey):Monkey = robo.monkey
}

Now arguably this is more complicated, because you have to create the Monkey object in addition to the Monkey class. What Scala requires is that you get those implicit functions (makeRobo, makeNormal) in scope. This is just one way to do that. The added benefit is the following usage:

 val monkey = new Monkey
 monkey.eatBanaas
 monkey.crushCars

I guess the Groovy way to do this is to use the meta class:

Monkey.metaClass.crushCars =  {-> println("smash")}
def monkey = new Monkey()    
monkey.eatBananas()
monkey.crushCars()

In both languages you can accomplish similar things, though with very different ways to implement it. Meta programming in Groovy is very powerful, and there are things you can do in Groovy that you cannot do in Scala -- see methodMissing and propertyMissing. Of course you lose some of the benefits of static typing, but software is all about tradeoffs.

The Strange Loop

In October, I am speaking at the inaugural Strange Loop conference in St. Louis. This is not your run of the mill conference. It is organized by Alex Miller, who you might have seen speak the last couple of years at JavaOne. The speaker list is sweet: Alex Payne and Bob Lee are doing the keynotes, with sessions by Charles Nutter, Dean Wampler, Stefan Schmidt, Guillaume Laforge, Jeff Brown, and Alex Buckley. I am doing a talk on iPhone/Android development. It will probably be pretty boring compared to the other sessions. I may try to spice it up with some shameless plugging of Scala+Android balanced by some Fake Steve Jobs quotes about Android.

JavaOne Talk: Performance Comparisons of Dynamic Languages on the Java Virtual Machine

Below are the sldies. Major thanks to Charlie Nutter for great feedback and advice on the Ruby code and tuning JRuby performance. Thanks to Chouser and Timothy Pratley for help with the Clojure code. And major thanks to Brian Frank for help with the Fan code.

Performance Comparisons of Dynamic Languages on the Java Virtual Machine

View more PDF documents from michael.galpin.

JavaOne Talk: RIAs Done Right

RIAs Done Right: Grails, Flex, and EXT GWT

View more PDF documents from michael.galpin.

JavaOne Talk: Groovy Reversible Numbers

See this post about why this code is being shown. See this post for the Java version to compare against.

public class GroovyReversible {
  final Integer max
  final Integer numReversible = 0
  public GroovyReversible(max){
    this.max = max
    this.numReversible = this.countReversible()
  }

  def countReversible(){
    numReversible ?: (11..max).findAll{reversible(it)}.size()
  }

  def reversible(n){
    allOdd(reverse(n))
  }

  def allOdd(n){
    n.toString().toList().collect {it.toInteger()}.every{it % 2 == 1}
  }

  def reverse(n){
    n + n.toString().toList().reverse().join().toInteger()
  }
}

JavaOne Talk: Groovy Word Sort

See this post about why this code is being shown. See this post for the Java version to compare against.

public class GroovyWordSort {
  File dataFile
  List words = []
  public GroovyWordSort(fileName){
    dataFile = new File(fileName)
  }

  def sortedWords(){
    if (!words){
      dataFile.eachLine{it.tokenize().each {words.add(it) }}
      words = words.sort{w,w1 -> w.toLowerCase() <=> w1.toLowerCase()}
    }
    words
  }
}

JavaOne Talk: Groovy Prime Sieve

See this post for an explanation on why this code is being shown and what kind of responses would be useful. See this post for the Java algorithm to compare against.

public class GroovyPrimes {
  int cnt = 0
  final def primes = []
  final int size

  public GroovyPrimes(int n){
    size = n
    init()
  }

  int last() {
    primes[cnt-1]
  }
  
  private void init(){
    int i = 2
    int max = calcSize()
    def nums = [true]*max
    
    while (i < max && primes.size() < size) {
      int p = i
      if (nums[i]) {
        primes << p
        (p..(max/p)).each{ j-> if (p*j < max) nums[p*j] = false}
      }
      i += 1
    }
  }

  private int calcSize(){
    int max = 2
    while ((max / Math.log(max)) < size && 
        max < Integer.MAX_VALUE && max > 0) {
      max *= 2
    }
    max
  }
}

Finally Grails

It sure took me long enough, but I finally got around to writing about Grails. This article gives some introduction to Grails, but also talks about using Grails with Geronimo. The most valuable info in there might be the Geronimo deployment plan. This shows which packages to exclude from Geronimo's classpath when deploying a Grails application. This prevents classpath implosion.

Dynamic Language Performance

A couple of days ago, I read Charlie's post explaining the performance boost seen in Groovy 1.6. Reading stuff like this always leaves me with a great feeling. Not only do you learn something, but it makes other things make more sense. It brings order to chaos, or something like that. Around the same time I read that, I was working a new article about Grails, so the Groovy angle was particularly interesting. I love benchmarks, so it was time to have some fun.

I wrote a Groovy version of the same Ruby code I had used to benchmark JRuby. This was an extremely straightforward port. I was amazed at just how similar Groovy's syntax is to Ruby. Here is the code:

def expo(n,p){
  def r = n % p
  def exp = 0
  def div = p
  while (r == 0){
      exp += 1
      div *= p
      r = n % div
  }
  return exp
}

def factor(n){
  def factors = new java.util.HashMap<Integer,Integer>()
  def s = n * 0.5
  def p = (2..s).toArray()
  p.each{
      if (it) {
          def r = expo(n,it)
          if (r){
              factors[it] = r
          }
          def val = it*2
          while (val <= s){
              p[val -2] = null
              val += it
          }
      }  
  }
  return factors
}

def numDivisors(n){
  def total = 1
  factor(n).values().each{
      total *= (it+1)
  }
  return total
}

def n = 2
def num = 1
def max = Integer.parseInt(this.args[0])
def Integer triangle = 0
while (num <= max){
  triangle = n*(n+1) * 0.5
  num = numDivisors(triangle)
  n += 1
}
println(triangle)

Anyways, here is the chart.

There is definitely a performance boost for long running processes where JIT'ing can happen more easily in 1.6. It was not as dramatic as I thought it might be, but it is there. Of course this is just one silly benchmark that is heavy in integer math, so take that for what it's worth. 

I also compared Groovy and JRuby. This was also surprising: 

Pretty close! Groovy seems to start-up a little slower, but pulled ahead slightly on bigger tasks. Perhaps the apprentice has overtaken the master.

Also, just for kicks, I tried out Scala. Here is the code:

import scala.collection.mutable._

object Euler12{
   def expo(n:int, p:int):int = {
       var r = n % p
       var exp = 0
       var div = p
       while (r == 0){
           exp = exp + 1
           r = n % div
           div = div * p
       }
       if (exp == 0 ) 0 else (exp-1)
   }
  
   def factor(n:int):Map[int,int] = {
       var factors = new HashMap[int,int]()
       var s:int = (n/2) + 1
       val p = (2 until s).toArray
       p.foreach( (num) => {
           if (num > 1){
               val r = expo(n, num)
               if (r > 0){
                   factors.put(num, r)
               }
               var i = num*2
               while ((i-2) < p.length){
                   p(i - 2) = 0
                   i = i + num
               }
           }
       })
       return factors
   }
  
   def numDivisors(n:int):int = {
       var total = 1
       factor(n).values.foreach((num) => {
           total = total * (num+1)
       })
       factor(n).values.foldLeft(1)((p,m) => {
           p * (m+1)
       })
   }
  
   def main(args:Array[String]) : Unit = {
       val t = new java.util.Date()
       var n = 1
       var num = 1
       val max = Integer.parseInt(args(0))
       var triangle = 3
       while (num <= max){
           triangle = n*(n+1)/2
           num = numDivisors(triangle)
           n = n + 1
       }
       println(triangle)
   }
}

This turned out to not be fair. Scala's performance is exactly on par with Java and thus blows away JRuby and Groovy. 

I guess that is what happens when you have a language written by a guy who once wrote javac... Actually I would guess this is mostly a function of the static typing in Scala. It certainly bodes well for initiatives to bring features of Scala, like (BGGA-style) closures and type inference, to Java. It seems possible to implement all of this with no impact on performance, even on a JVM that has not been made to support such features. 

Metaprogramming in Grails

Groovy is a swing-and-a-miss. It will go down like OS/2 did. People will say "man that Groovy language was so good, I don't know why it didn't catch on." Here's an example of why it is a fail.

I was reading this article on developerWorks about GORM, the OR framework in Grails. Like everything else in Grails, it is "inspired" by Ruby on Rails. In this case GORM was inspired by ActiveRecord. In GORM here is an association:

class Airline {
 static hasMany = [trip:Trip]

 String name
 String url
 String frequentFlyer
 String notes
}

Compare this to the same thing in Rails

class Airline < ActiveRecord::Base
 has_many :trips
end

Forget the explicit listing of fields for a minute, concentrate on the has-many notation used by both frameworks. In Grails, you have a static field that has a special name. In ActiveRecord you use a meta-API or macro (or whatever you want to call it) to dynamically add methods to each instance of Airline. Grails accomplishes the same thing, but it is much more of a hack. You just happen to have a static field that has a special name.

It just feels like "wow that feature is cool, we can't do it the same way ... but we can hack something together that is pretty close!" Just seems like Groovy comes up short.

Language Wars 2008

Two interesting blogs inspired this post. First, there is the amazing analysis of the great Neal Gafter. And then there is the insightful rant of Rick Hightower.

I have to admit that I am getting on the Scala bandwagon. Here is why I think Scala is important. Note, most of this is just me ripping off Neal Gafter :-)

There is great potential in languages with control abstraction. Scala is just such a language. It is possible to implement the actor model, a shared nothing, message based design for parallel computing, in Scala. This is not possible in Java. You can do it in Groovy, sort of, but it can be awkward. The reason for this is simple. If you have a object call method call closure (for example) the closure can return control back to the object in Scala, but only to the method in Groovy. The extra control structure coupling in Groovy makes some aspects of control abstraction awkward at best.

And then there are pattern matching (no not regexp) and case classes... The point is that there are syntactical advantages in Scala that make it possible to handle concurrent programming in a completely different, more scalable way. So it is not just about lines of code and what not, it is about being to do practical things in a better way.

Now Rick's main point in his rant, is why invest in JRuby and Scala when there is Groovy. Hopefully I've given at least one reason why Scala has potential that Groovy does not. When it comes to Ruby, the answer is less technical and more social.

On the technical side, it is very conceivable that by the end of the 2008, the absolute best way to deploy a Rails application will be to use JRuby. That is partially because of the current state of native Ruby interpreters, but also just because of how powerful the JVM has become. Sun really wants this to be the case, and here is why.

Sun knows what it takes to introduce a new language and platform and make it the de facto standard in the industry. It is very hard and expensive. They have done it once, and it cost them dearly. Java cannot stay at the top forever. They do not want to fight this battle again. However, if they can get the Rails on JRuby scenario described above to exist, then they could "stay on top" without having the fight all of the battles this time. They let the Rails community do it for them. They let guys like DHH and Martin Fowler win over the hearts and minds, while they simply concentrate on making JRuby run screaming fast.

But wait, there's more. Sun really wanted NetBeans to be the premiere Java development platform, but IBM beat them with Eclipse. They get a second chance if Ruby becomes the new de facto standard, and this time they have a head start on IBM. Sun is imagining a future where there are armies of IT developers writing Rails apps using NetBeans and deploying them to Glassfish.

Now all of the above may be possible, maybe even easier, with Groovy. But then they have to fight the language wars all by themselves. They have to win over the hearts and minds of developers to get them to use Groovy instead of C# or PHP.

That is why it makes more sense for Sun to back JRuby than to back Groovy.

That is also why you should not expect Sun to get behind Scala until they have no choice.

Scala

There is a lot of hype this year about Scala....



Heck, even al3x is talking about it. As someone who has no problem being called a Java guy, but has been doing a lot of work in ActionScript and Ruby recently, I am intrigued at Scala. However, I was also intrigued by Groovy a couple of years ago, and was mostly let down by it. Still, I have a strong feeling that I will wind up either writing about Scala this year or use it for a small project of some sort.

JavaFX

I guess the big news out of JavaOne today is JavaFX. The more I heard about it, the more it sounded familiar. Sure there's the obvious comparisons to Flex and SilverLight (more on that soon) but there was something even more familiar about it. Then I realized it: F3! I had read about F3 just last week (you can see it on my del.icio.us links) and had given it a try. So it turns I've already been running JavaFX.. Here's a picture of the F3 Calculator running on my laptop:

One of the most interesting things is the white space on my desktop. The F3 Calculator is part of it actually (or vice versa really.) There's probably some bugs to be worked on here! Also notice the little F3 icon in my system tray. You have to use that to close the calculator. The whole thing launches using Java Web Start, which is a good thing.

So yeah, JavaFX has a lot in common with Flex and SilverLight. Even in name. Microsoft had WinFX which became Windows Presentation Foundation which became Windows Presentation Foundation / Everywhere which became SilverLight. I'll say some of the same things about JavaFX as I said about SilverLight. If they could actually achieve "my dream" of writing a UI once and having it render nicely as a web app, a desktop app, and (most importantly) a mobile app, then it will be a huge success. I don't think anyone is close to that, yet.

JavaFX could actually have a lot more legs to it than SilverLight. It will be completely open, unlike either of its competitors. That should give it a huge advantage. That open nature should also mean a lot of creative integrations with the huge open source Java ecosystem. That's how JavaFX could win over developers. The key will be for Sun et. al. to deliver adequate tooling for it, as it is a UI language. Adobe already provides good tooling and Microsoft is sure to do the same. Sun's doesn't have to be as good as the Flex/SilverLight tooling, but it needs to be close. If it's not as good, you can expect to see other folks in the Java community step in.

Speaking of tooling, Cedric has a good rant against JavaFX. He smelled Sun trying to get people to use NetBeans, but as you'll see in the comments, there is an Eclipse plugin. Maybe the Jigloo guys can work with it, too. The better point that he makes is that Groovy SwingBuilder does a lot of the things that JavaFX promises to do. Maybe Sun should have leveraged that. I haven't tried JavaFX out yet, so I can't say if it has any syntactical advantages over Groovy. I must agree with another commenter that Sun doesn't seem too fond of Groovy. They seem much more interested in embracing Ruby via JRuby.

Update: I tried out the JavaFX plugin for Eclipse last night. It is quite bare-bones. It basically just lets you run a .fx file from Eclipse. No visual editing. It didn't even seem like there was any extra syntax help. I will try out the NetBeans one, but it sure looks like Cedric was right on about Sun once again trying to push NetBeans on people.