Skip to content

Scala for Java Refugees Part 1: main(String[])

7
Jan
2008

This article is also available in Spanish and Bulgarian.

You know who you are.  You’re the developer who picked up Java years ago, maybe as a second language and better alternative to C++, maybe as your first language coming into the industry.  You’re comfortable with Java, you know its ins and outs, its moods.  It’s like an old girlfriend; you may not feel the vibe anymore, but you know just how to rub it so it smiles.  In short, you’re a craftsman, and Java is your workhorse tool.

You’re starting to to become a bit pragmatic about your language choice though.  To put it mildly, the Java honeymoon is over.  While you can hardly find enough fault with the language to just walk away, you’re certainly open-minded enough to consider alternatives.  You’ve heard of this new-fangled thing called Ruby – how could you not have heard, given the sheer noise level produced by its followers.  You’re impressed by the succinctness of its constructs and the power of its syntax, but you’re not sold on the idea of using a scripting language to build your enterprise app.  Dynamic typing and TextMate are all well and good, but for the real-world iron horse you’re going to need something with a bit more backbone.  As a good pragmatist, you stick with the tool that works: Java.

The good news is that there’s light at the end of the tunnel.  There’s a new language on the scene that’s taking the developer world by storm.  Scala seems to offer everything you’ve been looking for in a language: static typing, compiled to bytecode (so you can run it on all those ancient Java-capable servers), a succinct and expressive syntax.  You’ve seen a few examples which have really caught your eye.  It looks the spitting image of Java, except with half the useless constructs thrown out.  No semi-colons, no public static void method qualifiers; it even seems to have some sort of static type inference mechanism.

The only problem you have now is figuring out where to start.  You’ve tried looking on the Scala website, but what you found stopped you in your tracks.  Everything’s so…functional.  Lamdas, high-order functions, immutable state, recursion out the wazoo.  Suddenly things are looking less promising.

Have no fear, ye refugee of Java EE grid iron, all is not lost.  True, Scala is a functional language, but it’s also imperative and highly object oriented.  What does this mean?  It means that you don’t have to write code with the sole purpose of pleasing Haskell Curry.  You can write code that you can actually read a week from now.  You may even be able to show this code to your Java-loving coworkers and they just might understand it.  You don’t have to curry every function and avoid loops at all costs.  You can write your Java applications in Scala.  You just need the right introduction.

Introductions

If you’re like me and can identify with the above, then this series is for you.  I’ve read a lot of articles and tutorials on Scala (Alex Blewitt’s series is highly recommended, especially if you’re interested in the more functional side of life), but few of these tutorials have even attempted to make things easier for the run-of-the-mill Java developer to make the transition.  I personally have very little FP (Functional Programming) experience, so I don’t think I could write an article about porting Scheme code to Scala even if I wanted to.  Instead, this series will focus on how Scala is just like Java, except better.

Did I mention Alex’s Scala introduction series?  Seriously, this is great reading, and not a bad introduction to Scala in and of itself.  Once you’re done reading my ramblings, you should run over and read some of his more coherent stuff.   The more the merrier!

Getting Started

object HelloWorld extends Application {
  println("Hello, World!")
}

Nothing like getting things rolling with a little code.  Notice the refreshing lack of mandatory semicolons.  We can use them anyway, but they aren’t required unless we need multiple statements on a single line.  This code sample does exactly what it looks like, it defines an application which (when run using the scala interpreter) will print “Hello, World!” to stdout.  If you put this code into a file with a .scala extension, you can then compile it using the scalac compiler.  The result will be a single .class file.  You could technically run the .class using the java interpreter, but you would have to mess with the classpath a bit.  The easiest thing to do is just use the scala command like so:

scalac hello.scala
scala HelloWorld

Notice the name of the file in question?  Unlike Java, Scala doesn’t force you to define all public classes individually in files of the same name.  Scala actually lets you define as many classes as you want per file (think C++ or Ruby).  It’s still good practice to follow the Java naming convention though, so being good programmers we’ll save our HelloWorld example in a file called “HelloWorld.scala”.

Editors

Just a brief note on your first few moments with Scala: using the right editor is key.  As you must have learned from your many years in the Java world, IDEs are your friend.  Scala, being a much younger language doesn’t have very good IDE support yet.  It is a static, general purpose language like Java, so IDE support will be forthcoming.  For the moment however, you’re stuck with a very limited set of options.

  • Eclipse (using one of two shoddy and unstable Scala plugins)
  • Emacs
  • IntelliJ (basically just syntax highlighting support)
  • TextMate
  • VIM
  • jEdit

There are a few other options available, but these are the biggies (to see a full list, look in the misc/scala-tool-support/ directory under the Scala installation root).  My personal recommendation is that you use jEdit or TextMate, though if you’re feeling adventurous you’re free to try one of the Eclipse plugins too.  Scala support in Eclipse has the advantage (at least with the beta plugin) of features like semantic highlighting, code completion (of both Scala and imported Java classes) and other IDE-like features.  In my experience though, both Eclipse plugins were unstable to the point of unusable and as such, not worth the trouble.  Scala is a much cleaner language than Java, so it really does have less of a need for a super powerful IDE.  It would be nice, no question about that, but not essential.

More Hello World

object HelloWorld2 {
  def main(args:Array[String]) = {
    var greeting = ""
    for (i <- 0 until args.length) {
      greeting += (args(i) + " ")
    }
    if (args.length > 0) greeting = greeting.substring(0, greeting.length - 1)
 
    println(greeting)
  }
}

Save this in a new file (we’ll call it “HelloWorld2.scala”), compile and run using the following commands:

scalac HelloWorld2.scala
scala HelloWorld2 Hello, World!

Once again, this prints “Hello, World!” to stdout.  This time we did things a little differently though.  Now we’ve got command line arguments coming into our app.  We define a variable of type String, iterate over an array and then call a bit of string manipulation.  Fairly straightforward, but definitely more complex than the first example.  (Note: Scala mavens will no doubt suggest the use of Array#deepMkString(String) (similar to Ruby’s Array::join method) instead of iterating over the array.  This is the correct approach, but I wanted to illustrate a bit more of the language than just an obscure API feature).

The first thing to notice about this example is that we actually define a main method.  In the first example, we just extended Application and declared everything in the default constructor.  This is nice and succinct, but it has two problems.  First, we can’t parse command line args that way.  Second, such examples are extremely confusing to Scala newbies since it looks more than slightly magical.  Don’t worry, I’ll explain the magic behind our first example in time, but for now just take it on faith.

In the example, we define a main method that looks something like our old Java friend, public static void main.  In fact, this is almost exactly the Scala analog of just that method signature in Java.  With this in mind, an experienced developer will be able to pick out a few things about the language just by inspection.

First off, it looks like all methods are implicitly public.  This is somewhat correct.  Scala methods are public by default, which means there’s no public method modifier (private and protected are both defined).  It also looks like Scala methods are static by default.  This however, is not entirely correct.

Scala doesn’t really have statics.  The sooner you recognize that, the easier the language will be for you.  Instead, it has a special syntax which allows you to easily define and use singleton classes (that’s what object means).  What we’ve really declared is a singleton class with an instance method, main.  I’ll cover this in more detail later, but for now just think of object as a class with only static members.

Upon deeper inspection of our sample, we gain a bit of insight into both Scala array syntax, as well as an idea of how one can explicitly specify variable types.  Specifically, let’s focus on the method declaration line.

def main(args:Array[String]) = {

In this case, args is a method parameter of type Array[String].  That is to say, args is a string array.  In Scala, Array is actually a class (a real class, not like Java arrays) that takes a type parameter defining the type of its elements.  The equivalent Java syntax (assuming Java had an Array class) would be something like this:

public static void main(Array<String> args) {

In Scala, variable type is specified using the variable:Type syntax.  Thus, if I wanted to declare a variable that was explicitly of type Int, it would be done like this:

var myInteger:Int

If you look at the sample, we actually do declare a variable of type String.  However, we don’t explicitly specify any type.  This is because we’re taking advantage of Scala’s type inference mechanism.  These two statements are semanticly equivalent:

var greeting = ""

var greeting:String = ""

In the first declaration, it’s obvious to us that greeting is a String, thus the compiler is able to infer it for us.  Both greetings are staticly type checked, the second one is just 7 characters shorter.  :-)

Observant coders will also notice that we haven’t declared a return type for our main method.  That’s because Scala can infer this for us as well.  If we really did want to say something explicitly, we could declare things like this:

def main(args:Array[String]):Unit = {

Once again, the type antecedes the element, delimited by a colon.  As an aside, Unit is the Scala type for I-really-don’t-care-what-I-return situations.  Think of it like Java’s Object and void types rolled into one.

Iterating Over an Array

var greeting = ""
for (i <- 0 until args.length) {
  greeting += (args(i) + " ")
}

By the way, it’s worth noting at this juncture that the convention for Scala indentation is in fact two spaces, rather than the tabs or the four space convention that’s so common in Java.  Indentation isn’t significant, so you can really do things however you want, but the other four billion, nine hundred, ninety-nine million, nine hundred, ninety-nine thousand, nine hundred and ninety-nine people in the world use the two space convention, so it’s probably worth getting used to it.  The logic behind the convention is that deeply nested structure isn’t a bad sign in Scala like it is in Java, thus the indentation can be more subtle.

This sample of code is a bit less intuitively obvious than the ones we’ve previously examined.  We start out by declaring a variable, greeting of inferred type String.  No hardship there.  The second line is using the rarely-seen Scala for loop, a little more type inference, method invocation on a “primitive” literal and a Range instance.  Developers with Ruby experience will probably recognize this equivalent syntax:

for i in 0..(args.size - 1)
  greeting += args[i] + " "
end

The crux of the Scala for loop is the Range instance created in the RichInt#until method.  We can break this syntax into separate statements like so:

val range = 0.until(args.length)
for (i <- range) {

Oh, that’s not a typo there declaring range using val instead of var.  Using val, we’re declaring a variable range as a constant (in the Java sense, not like C/C++ const).  Think of it like a shorter form of Java’s final modifier.

Scala makes it possible to invoke methods using several different syntaxes.  In this case, we’re seeing the value methodName param syntax, which is literally equivalent to the value.methodName(param) syntax.  Another important action which is taking place here is the implicit conversion of an Int literal (0) to an instance of scala.runtime.RichInt.  How this takes place isn’t important right now, only that RichInt is actually the class declaring the until method, which returns an instance of Range.

Once we have our Range instance (regardless of how it is created), we pass the value into the magic for syntax.  In the for loop declaration, we’re defining a new variable i of inferred type Int.  This variable contains the current value as we walk through the range [0, args.length) - including the lower bound but not the upper.

In short, the for loop given is almost, but not quite equivalent to the following bit of Java:

for (int i = 0; i < args.length; i++) {

Obviously the Java syntax is explicitly defining the range tests, rather than using some sort of Range object, but the point remains.  Fortunately, you almost never have to use this loop syntax in Scala, as we'll see in a bit.

The body of the loop is the one final bit of interesting code in our sample.  Obviously we're appending a value to our greeting String.  What I'm sure struck you funny (I know it did me) is the fact that Scala array access is done with parentheses, not square brackets.  I suppose this makes some sense since Scala type parameters are specified using square brackets (rather than greater-than/less-than symbols), but it still looks a little odd.

To summarize, the upper sample in Scala is logically equivalent to the lower sample in Java:

var greeting = ""
for (i <- 0 until args.length) {
  greeting += (args(i) + " ")
}

String greeting = "";
for (int i = 0; i < args.length; i++) {
    greeting += args[i] + " ";
}

A Better Way to Iterate

In Java 5, we saw the introduction of the so-called for/each iterator syntax.  Thus, in Java we can do something like this:

for (String arg : args) {
    greeting += arg + " ";
}

Much more concise.  Scala has a similar syntax defined as a high-order function - a function which takes another function as a parameter.  I'll touch on these more later, but for the moment you can take it as more magic fairie dust:

args.foreach { arg =>
  greeting += (arg + " ")
}

Here we see that foreach is a method of class Array that takes a closure (anonymous function) as a parameter.  The foreach method then calls that closure once for each element, passing the element as a parameter to the closure (arg).  The arg parameter has an inferred type of String because we're iterating over an array of strings.

Now as we saw earlier, Scala methods can be called in different ways.  In this case we're calling foreach omitting the parentheses for clarity.  We also could have written the sample like this:

args.foreach(arg => {
  greeting += (arg + " ")
})

Scala actually defines an even more concise way to define single-line closures.  We can omit the curly-braces altogether by moving the instruction into the method invocation:

args.foreach(arg => greeting += (arg + " "))

Not bad!  So our fully rewritten sample looks like this:

object HelloWorld2 {
  def main(args:Array[String]) = {
    var greeting = ""
    args.foreach(arg => greeting += (arg + " "))
    if (args.length > 0) greeting = greeting.substring(0, greeting.length - 1)
 
    println(greeting)
  }
}

The syntax looks great, but what is it actually doing?  I don't know about you, but I hate having to use APIs that I don't know how to replicate myself.  With a bit of work, we can recreate the gist of the Scala foreach method in pure Java.  Let's assume for a moment that Java had an Array class.  In that Array class, let's pretend there was a foreach method which took a single instance as a parameter.  Defined in code, it might look like this:

public interface Callback<T> {
    public void operate(T element);
}
 
public class Array<T> {
    // ...
    public void foreach(Callback<T> callback) {
        for (T e : contents) {   // our data structure is called "contents"
            callback.operate(e);
        }
    }
}

I could have defined foreach recursively (as it is defined in Scala), but remember I'm trying to keep these explanations clear of the tangled morass that is FP.  :-)

Sticking with our goal to see an analog to the Scala foreach, here's how we would use the above API in Java:

public class HelloWorld2 {
    public static void main(Array<String> args) {
        final StringBuilder greeting = new StringBuilder();
        args.foreach(new Callback<String>() {
            public void operate(String element) {
                greeting.append(element).append(' ');
            }
        });
        if (args.length() > 0) {
            greeting.setLength(greeting.length() - 1);
        }
 
        System.out.println(greeting.toString());
    }
}

Starting to see why Scala is legitimately appealing?  If you're like me, you just want Scala to be a more concise Java.  In this case, that's exactly what we've got.  No strange functional cruft, no immutable state.  Just solid, hard-working code.

A Word About Built-in Types

Because Scala is built on the JVM, it inherits a lot of its core API directly from Java.  This means you can interact with Java APIs.  More than that, it means that any code you write in Scala is using Java APIs and functions.  For example, our sample HelloWorld2 is using a string variable greeting.  This variable is literally of type java.lang.String.  When you declare an integer variable (type Int) the compiler converts this to the Java primitive type int.

It's also worth noting that there are a number of built-in implicit conversions (just like the Int to RichInt we saw earlier with the Range creation).  For example, Scala's Array[String] will be implicitly converted to a Java String[] when passed to a method which accepts such values.  Even Scala type parameters are available and interoperable with Java generics (in the current development version of Scala and slated for inclusion in 2.6.2).  In short, when you use Scala you’re really using Java, just with a different syntax.

Conclusion

Scala doesn’t have to be complex, needlessly academic or require a master’s degree in CompSci.  Scala can be the language for the common man, the 9-5 developer who’s working on that next enterprise web application.  It has real potential to provide the clear syntax Java never had without forsaking the power and stability of a trusted, first-class language.  Convinced?

Up next, classes, methods and properties: everything you need to know to get rolling with object-oriented programming in Scala.

Wicket 1.3 Released…Broken Guice and All

3
Jan
2008

I usually try to avoid such negative topics, but this time I really couldn’t help myself.  Once in a while something in the “current events” section of the blogosphere will bug me enough to merit a slam post.  The “support” for Google Guice in the latest stable release of Wicket is one of those things…

To start with, the good news: Martijn Dashorst has announced the release of Apache Wicket 1.3!  This really is a great release all-around and the guys in the band deserve a round of applause.  This release fixes the number one “bug” with Wicket: it’s rather odd package namespace.  (wicket.*:-)   Welcome to the land of happy packages and tired fingers.

Wicket is really starting (or just proceeding at an accelerated rate) to feel like a rock solid, production-ready framework.  I’ve used it quite a bit over the last few years, and I’ll say flat-out that I don’t think any framework matches it for productivity and maintainability (that includes Rails, dynlang notwithstanding).

One of the new features in 1.3 (important enough to merit inclusion in Martijn’s 20-odd points) is support for Google Guice dependency injection.  This is a huge deal for those of us who have nominated Guice for the “cleverest framework of the decade” award.  Support for Guice in Wicket makes it possible to utilize dependency injection right in your page classes (where it’s most needed).  Wicket has had similar support for Spring for a while now, but it was only recently that Al Maw got the chance to refactor the guts out into the wicket-ioc project and thus enable support for alternative DI frameworks like Guice.

This all seems well and good, but unfortunately Wicket’s Guice support is not quite up to par with the rest of the framework.  I tried the support a while back in beta4 and ran headlong into a fairly serious problem.  The following code doesn’t work:

public class MyModule extends AbstractModule {
    // ...
 
    @Override
    public void configure() {
        EntityManager manager = new EntityManager(uri, username, password);
        bind(EntityManager.class).toInstance(manager);
    }
}

This is fairly standard Guice configuration code.  All that’s happening here is I’m binding all injected fields of type EntityManager to a given instance.  Of course the classic use of DI is to have it instantiate the injected values based on classname (or class literal in Guice’s case).  However, this panacea of IOC breaks down when working with classes which lack default constructors (like EntityManager).  This is why Guice enables developers to bind classes to instances (as I’m doing above).  The problem is this code will crash when executed using wicket-guice.

I opened an issue in the Wicket JIRA back in November when I first identified the bug (WICKET-1130).  I even included some simple example code I could use to repeat the problem!  Since then the issue has been reassigned and bumped back in fix version twice, all without any word on if the problem is being looked at or how soon I could expect a solution.  Now I know the Wicket devs are busy and all with tons of more sweeping issues and last-minute polish for the 1.3 release, but this is pretty absurd.

Honestly, if this were a trivial edge-case that only effected me and my neighbor’s cow, I wouldn’t put up much of a fuss.  But the fact is, this is something so broad and repeatable that it will touch just about anyone who seriously uses Guice with Wicket.  Even if there wasn’t time to fix the problem before the 1.3 release, I would hope there would be some sort of prominent notice (“KNOWNBUGS” anyone?) included with the distributable.  Unfortunately the only reference to the problem I was able to find on the Wicket site was an obscure wiki article (well written though) done by Uwe Schäfer.  All this entry serves to do is further aggravate me since it means someone else has run headlong into this problem and been annoyed by it enough to write an article (still without receiving response from the Wicket core devs).

Uwe does propose a workaround (add a protected no-arg constructor to the injected class), but that’s impractical for my use case (and if I ran into it, you can bet your boots half a dozen other people did too).  I’m certainly not going to randomly add broken constructors to the ActiveObjects API, and I wouldn’t even have the option to consider doing so except for the fact that I’m the developer on the class I was trying to bind.  If I was trying to bind an instance from a third-party library, I’d be out of luck completely.

I’m very disappointed in the Wicket project for dropping the ball on this issue.  I really have the utmost respect for those guys, which is why it’s so surprising to see something like this happen.  As it stands, WICKET-1130 is slated for 1.3.1, but given its track record of reassignment I’m not holding my breath.  Hopefully this posting will serve as a more prominent warning for those considering using Wicket and Guice together in their project.

Diving into Scala

2
Jan
2008

I came to the realization this week that I really don’t know enough Scala (like I say, just enough to be dangerous).  After all, most experts agree that this is the general purpose language of the future, and it may just be a more productive language of the present.  With that in mind, I think it’s a fair conclusion that no Java developer should be without at least a working knowledge of the language.

In truth, I’ve been putting off learning more about Scala.  Yes, I’m sold on its benefits and what it could become, but I’m very comfortable in my cozy IDE and often it seems like there’s no immediate reason to change.  More than that, I was slightly put-off by all the functional goodies.  I mean, currying?  Function parameters?  Lazy evaluation?  It’s enough to make an upstanding imperative developer’s hair stand on end.  And every time I thought I had worked up the courage to try a more in-depth experiment, I’d browse over to the Scala site and there would be that demonic monocharacter-variabled quicksort implementation staring me in the face.  A word of advise, guys: that’s not the best example for how readable and intuitive Scala can be!

But in the end, my curiosity and dislike-for-anything-I-can’t-understand won the day.  A while back, I wrote an extremely naive chess engine in Java.  It was horribly inefficient (working recursively, rather than using a more conventional graph search algorithm) and it barely worked for even simple analyses, but it was at the time a diverting weekend project.  Remembering this project set me thinking about how I could have done it better.  Obviously some redesign would be needed on the core algorithm.  An astounding amount of graph theory comes into play (no pun intended) in chess analysis.  Graph search algorithms are usually profoundly functional in nature, which got me thinking about Scala again.  Working with closures, cheap recursion and first class functions can make such algorithms far more expressive, easy-to-read and efficient.  So I updated my Scala runtime, dusted off the “scala” mode definition for jEdit and got to work.

I won’t deny, I was somewhat leery of stepping out of my nice Eclipse environment.  Granted, I program in Ruby all the time and rarely use an IDE for it, but somehow that’s different.  Scala is a peer to Java from a language standpoint, so mentally I expected my experience to be similar to the time I wrote Java code in Notepad.  Nothing could be farther from the truth.

Writing code in Scala was like a breath of fresh air.  To my surprise, the code I was turning out was both more concise and more readable than the equivalent Java (a rare combination).  Add to that the fact that much of the Scala core API is based on (or actually is) the Java lang libraries and I found myself almost oblivious to the lack of code completion, inline documentation and incremental compilation (almost).  I did find myself keeping a Scala interpreter running in a separate shell (a habit I picked up doing Ruby with IRB), as well as using Google frequently to find little tidbits.  There’s no doubt that the experience would have been more fluid with a toolset of the JDT caliber, but I wasn’t totally dependant on my life support anymore.

Things were flowing smoothly, and I was just starting to pick up steam when my passenger train derailed on a tiny piece of miss-placed syntactic jello: arrays.

In Scala, arrays are objects just like any other.  Yes, I’m sure you heard that when transitioning to Java, but Scala really carries the concept through to its full character (think Ruby arrays).  This is how you allocate an array of size 5 in Scala:

var array = new Array[String](5)

Or, if you just have a set of static values, you can use the factory method (ish, more on that later):

var names = Array("daniel", "chris", "joseph", "renee", "bethany", "grace")

It was at this point that my warning sirens began going off.  Any syntax which looks even remotely like C++ deserves extremely close scrutiny before it should be used.

The first invocation is fairly straightforward.  We’re creating a new instance of class Array parameterized on the String type.  Scala has type parameterization similar to Java generics except significantly more powerful.  In fact, Scala type parameters are really closer to lightweight templates (without the sytactical baggage) than to generics.  The Javascript-style variable declaration is actually typesafe because the compiler statically infers the type from the assignment (yet another “well, duh!” feature that Scala handles beautifully).

The second syntax is a bit more complex.  It is best understood once a bit of groundwork is laid analyzing the rest of the array syntax:

var array = new Array[String](5)
array(0) = "daniel"
array(1) = "chris"
println(array(0))

No, that’s not a typo. Scala uses parentheses to access array values, not the C-style square brackets which have become the standard.  By this time, the syntax was starting to look more and more like BASIC and the warning sirens had become full-blown air raid alerts.  My vision blurred, my knees got week and I desperately groped for a fresh slice of pizza.  Any language that reminds me of C++ and VB6 successively within the span of 30 seconds deserves not just scrutiny, but all-out quarantine.

It turns out that somewhere in the Array class, there’s a set of declarations that look like this:

class Array[T](size:Int) {
  def apply(index:Int):T = {
    // return the value from the underlying data structure
  }
 
  def update(index:Int, value:T):Unit {
    // set the value at the corresponding index
  }
 
  // ...
}

Ouch!  Seems the other shoe just dropped.  It turns out that the apply and update methods are special magic functions enabling the array access and modification syntax.  The same code in C++ might look like this:

template <class T>
class Array {
public:
    Array(int length);
 
    T& operator()(int index);
 
private:
    // ...
};

For those of you who don’t know, there’s a reason that syntax passed into “bad practice” years ago.  In short: it’s cryptic, relies heavily on magic syntax tricks (thus is quite fragile) and by its very nature redefines an operation that is understood to be basic to the language (parentheses).  It’s the absolute worse that operator overloading has to offer.

But the fun doesn’t stop there!  Remember I said the (sort of) array factory constructor would make more sense after analyzing arrays a bit more?  You probably know where I’m going with this…

object Array {
  def apply[T](values:*T) = values
}
 
class Array[T](length:Int) {
  // ...
}

Try not to think about it too much, it’ll make your brain hurt.  Scala doesn’t really have a static scope, so any class that needs to do things statically (like factories) has to use the singleton construct (object).  Extend this concept just a bit and you can see how classes which must be both instance and static can run into some trouble.  Thus, Scala allows the definition of both the singleton and the class form of the same type.  In Java, the same concept might look like this:

public class Array<T> {
    public Array(int length) {
        // ...
    }
 
    // ...
 
    public static <V> Array<V> createInstance(V... values) {
        // ...
    }
}

Obviously the correspondence isn’t exact since Java array syntax can’t be replicated by mere mortals, but you get the gist of it.  It seems this is one time when Scala syntax isn’t more concise or more intuitive than Java.

So what does this all mean for our array factory construct?  It means we’re not actually looking at a method, at least, not a method named “Array” as we might reasonably expect.  The array factory construct can be written equivalently in this fashion:

var names = Array.apply("daniel", "chris", "joseph", "renee", "bethany", "grace")

Are you starting to see why overloading the parentheses operator is considered bad form in civilized lands?  The syntax may look nice, properly used, but it’s a major pain in the behind if you have to read someone else’s badly-designed code to understand what’s going on if you can’t rely on parentheses to be parentheses.

Things keep going from bad to worse when you consider all the trouble you can get into with method declarations.  Try this one on for size:

class Pawn {
  def getSymbol = "P"
}

Famously concise and readable…except it’s not going to do what you probably expect it to.  To use this class, you might write something like this:

var pawn = new Pawn
println(pawn.getSymbol())

The above code will fail with a compiler error on line 2, saying that we passed the wrong number of arguments to the getSymbol method.  Here’s a heads-up to those of you designing the Scala syntax: this confuses the hell out of any newbie trying the language for the first time.  It turns out that declaring a method without parentheses means that it can never be invoked with those parentheses.  Changing the invocation to the following alleviates the error:

println(pawn.getSymbol)

And just when you’re beginning to make sense of all this, you remember that declaring a method with parentheses means that it can be used both ways!  So the following code is all valid:

class Pawn {
  def getSymbol() = "P"
}
 
var pawn = new Pawn
 
// method 1
println(pawn.getSymbol())
 
// method 2
println(pawn.getSymbol)
 
// method 3
println(pawn getSymbol)

One final, related tidbit just in case you thought these were isolated examples.  It may come as a shock to those of you coming from C-derivative languages (such as Java), but Scala doesn’t support constructor overloading.  Seriously, there’s no way to define multiple constructors for a class in Scala.  Of course, like many other things Scala provides a way to emulate the syntax, but it’s far from pretty.  Let’s suppose you want to be able to construct a Person with either a full name, a first and last name or a first name, last name and age.

object Person {
  def apply(fullName:String) = {
    var names = fullName.split(' ')
    Person(names(0), names(1))
  }
 
  def apply(firstName:String, lastName:String) = Person(firstName, lastName, 20)
}
 
case class Person(firstName:String, lastName:String, age:Int) {
  def getFirstName() = firstName
  def getLastName() = lastName
  def getAge() = age
}
 
var person1 = Person("Daniel Spiewak")
var person2 = Person("Jonas", "Quinn")
var person3 = Person("Rebecca", "Valentine", 42)

“Where are your Rebel friends now?!”

Of course it all makes some sense from a theoretical standpoint, but in practice I can’t see this being anything but clumsy and annoying (not to mention visually ambiguous.  Try to trace the code that creates person1 to see what I mean).

Update: As has been pointed out in the comments, Scala does support a primitive sort of constructor overloading (using def this()) which allows for simple delegate constructors (like I demonstrated above).  However, the fact remains that Scala’s constructor overloading is neither as powerful nor as uniformly intuitive as the corresponding feature in Java.

Conclusion

I really don’t mean to be a pain.  After all, someone could write exactly the same sort of rant about any language.  Overall, I still think Scala is a big win over any imperative language I’ve ever seen.  The point I’m trying to get across is that there’s no silver bullet.  No language is perfect (not even Scala).

Scala’s at an interesting place right now.  When I work with it and when I read the buzz around the blogosphere, I get the same feeling as I did about Ruby 5 years ago.  Back then Ruby was a virtually unknown Asian language with some interesting dynamic constructs.  Now there’s so much hype built up behind the language it could choke a mule.  People are rallying to its cause and breaking out the ACME flame-throwers to deal with any dissidents.  I would hate to see that happen to Scala.

Final word to Java developers everywhere who haven’t tried Scala yet: you’re missing it!!  Learn Scala.  Try a few applications.  Trust me, you won’t regret it.  Just be sure to drink plenty of fluids, I’m sure you’ll run into your share of oddball syntax corners.

ActiveObjects 0.7 Released

22
Dec
2007

Just in time for the Christmas holidays, I give you ActiveObjects version 0.7!  This release sports a whole slew of minor performance tweaks and bugfixes, providing better reliability.  Also, we’ve greatly increased the number and scope of the unit tests running against the core.  This gives us more confidence that the code is indeed as stable as we hope.

Actually, the big ticket item for 0.7 is the introduction of polymorphic relations.  This feature is fully tested and stable, so I don’t anticipate it introducing any issues in the coming days as we narrow our focus to 1.0.  However, no feature is so well tested as to be certainly bug free under all circumstances.  I look forward to fixing any problems you may encounter with the library!

A few minor feature additions:

  • Support for persisting enum values
  • One-to-one relations
  • EntityManager#flush(…) now also flushes the relations cache

Looking toward the road ahead, things are really starting to settle down a bit.  The main feature I’m looking to implement for 0.8 is extensible value caching, which should allow you to determine how and where the cached field values are stored.  The main use-case behind this is support for memcached, which has been requested a few times and has actually been on the agenda since 0.3.  With memcached driving the value cache, ActiveObjects should be almost perfectly scalable.

To that end, it’s also worth mentioning that I did some profiling (using the NetBeans Profiler) using a Wicket-based web application I’m developing on the side.  I’m happy to report that the overhead imposed by ActiveObjects is extremely minimal.  In each test, the bottleneck was in the PreparedStatement#execute method (in JDBC).  Since ActiveObjects generates very streamlined and natural queries, it seems that this is really the minimal execution time possible for such database access.  Extrapolating further from this data, and given that the JDBC exec time was avg 40ms, while the execution time in the ActiveObjects API was on the order of 1ms-5ms, we can safely say that ActiveObjects is less than 10% slower than using JDBC directly (compare that to the 50% overhead claimed by ActiveRecord).  This “estimate” doesn’t even take into account the many performance advantages offered by ORMs over hand-coded database access (such as relations caching, optimal query construction, etc).

Anyway, enough shameless boasting.  As Hibernate has often pointed out, ORM benchmarks are usually worse than useless.  The only benchmark which really matters is how well the ORM performs in your application.  Try it out, see what you think.

Java Needs Map Syntax Sugar

18
Dec
2007

I’ve never been a big fan of useless syntax sugar.  I’ve always thought that the simpler a language is syntactically, the better.  If you think about it, there’s a lot of merit to this sort of viewpoint.  I mean, which of these is easier to read?

public class Test {
    public void put(Object key, Object value) {
        // ...
    }
 
    public Object get(Object key) {
        // ...
    }
}
 
// ...
Test test = new Test();
test.put(String.class, "blah");
test.put(StringBuilder.class, "blahblah");
 
String value = (String) test.get(StringBuilder.class);

Or this?

public class Test<K, V> {
    public void put(K key, V value) {
        // ...
    }
 
    public V get(K key) {
        // ...
    }
}
 
// ...
Test<Class<? extends CharSequence>, String> test = 
        new Test<Class<? extends CharSequence>, String>();
test.put(String.class, "blah");
test.put(StringBuilder.class, "blahblah");
 
String value = test.get(StringBuilder.class);

The only thing that has different between the examples is one makes use of generics, the other doesn’t.  The top example makes use of a cast, the bottom avoids this.  The lower example also has some trivial compile-time checking, but that’s about it. 

So what have we done here?  We complicated a trivial example with 50-100 extra, cryptic characters and managed to avoid a single, 9-character cast.  Not really an improvement.  I’ll grant you that generics are usually very beneficial, and I won’t deny that I like them and make use of them myself, but the point of the example is unchanged: extra “beneficial” syntax constructs are not always a good thing.

With all this said, I still have to admit that I’m (grudgingly) in favor of certain syntax additions.  Closures for example are probably the absolute best proposal for Java 7 I’ve heard yet.  Obviously we can quibble over the syntax, but I think the construct itself is a very valuable one.  I’m also (again grudgingly) in favor of another syntax sugar having to do with method parameters.

Many methods these days take a Map as a parameter.  It’s a fairly common thing to pass values that way.  JDBC is a good example (well, actually it’s a Properties instance).  ActiveObjects has a method to create an entity, passing a map of field => value pairs to be set on the INSERT.  Often times, such methods are an enormous pain to call.  Example:

Map<String, Object> params = new HashMap<String, Object>();
params.put("firstName", "Daniel");
params.put("lastName", "Spiewak");
Person person = em.create(Person.class, params);

Alright, not horrible. But imagine you had several dozen values to pass. It’s not that uncommon for such a situation to arise, and right now it always leads to vast quantities of syntax cruft.

Of course, there is a shortcut notation, but it’s almost as verbose and virtually unknown (which makes it a bad choice due to readability concerns):

Person person = em.create(Person.class, new HashMap<String, Object>() {{
    put("firstName", "Daniel");
    put("lastName", "Daniel");
}});

What this is actually doing is declaring a constructor for an anonymous inner class extending HashMap.  It’s not too bad in terms of syntax, but very few Java developers are aware of this construct, thus it should probably be avoided.

Now if we consider the corresponding syntax in a language like Ruby, things fall out beautifully (here using symbols instead of Strings for the keys):

person = em.create(Person, :firstName => "Daniel", :lastName => "Spiewak")

Obviously I’m taking a bit of artistic license with the API, but you get my drift.  This code is so much cleaner because Ruby has a syntax construct which allows the implicit creation of Hash objects (the Ruby equivalent of Map) as required within the method invocation.  The above syntax is equivalent to the following:

params = Hash.new
params[:firstName] = "Daniel"
params[:lastName] = "Spiewak"
person = em.create(Person, params)

So nothing too complex, Ruby just makes it cleaner.  Most scripting languages actually have a similar construct, for example Groovy allows for the key:value syntax in method parameters, dynamically creating a Java Map as necessary.

I think Java should add a similar syntax.  There are enough cases where such a construct would greatly simplify the code in question.  We wouldn’t even need to add symbol literals to the language, we could just use standard Java types.  Perhaps something like the following is in order:

Person person = em.create(Person.class, "firstName":"daniel", "lastName":"Spiewak");

Completely unobtrusive, easy to read, and even more compact than the Ruby version.  The syntax is familiar to anyone using Groovy (more and more these days) and it doesn’t require the introduction of a new keyword or clumsy over-riding construct.  It’s type-checked, so compile-time safe, and totally backwards compatible (you could use this syntax on legacy APIs without modification).

So the question: is it worth it?  Since Java was open sourced, we’ve been seeing more and more efforts like KSL (the Kitchen Sink Language).  People have been hearing so many new language proposals that there’s beginning to be an anti-change backlash.  Many of the developers I respect are more and more of the opinion that Java should remain the way it is.  Those who want all the fancy language additions should use Scala.

In a lot of ways, I agree with them.  In my opinion, Java’s too bulky and inconsistent in its syntax already, but I think this might just be one area where an exception could be made.  Perhaps this construct is simple enough, unobtrusive enough and ubiquitously useful enough to be worth the effort of putting it into the language.