Why you should take a look at Scala and where to start?

Scala is advertised as the successor to Java by some and as an experimental ground for new features by others. According to its creator, Martin Odersky, it is supposed to be the swiss army knife of programming languages, something that is a scripting language and yet still offers all that Java has and more. When saying that it is a scripting language, it is referencing the usual characteristics of these languages which is dynamic typing and low verbosity (Scala is NOT dynamically typed, it does type inference which in practice means that you rarely have to declare the type of your variables.). It is very difficult at this point to determine if Scala is going to be widely used, so why should you use time on Scala? Why not Groovy or Ruby? The two latter languages are definitely worth looking at, however they truly are scripting languages and most of their popularity is not so much due to the language itself, but more due to their application in Rails frameworks. If you are already familiar with scripting languages, then these languages have very few new features but mostly polished versions of existing concepts (Ruby is as old as Java, so very few things are actually new in Ruby). Scala on the other side has a number of features that are bit more original or at least cutting edge, so even if Scala doesn’t make it as a mainstream language a lot of the features in the languages are likely to appear in whichever language makes it. So why not get a heads start? Now, I am in no way a language expert, I am practitioner not a theorist, but this is the general feeling I get from the people I talk to and the what I read around the net.

So where should you start? To understand the why of Scala and the principles it was built on, I can recommend the presentation that Martin Odersky gave at JavaOne. Audio and the slides can be found at the Sun Developer Network here (subscription required). I was at the session and I can testify that looking around the room there were quite a few of the big shots of the Java world attending (such as Joshua Bloch and Brian Goetz). A light introduction aimed at Java developers called Scala for the Java Refugee, I found very useful to get a quick start with a mapping from Java concepts to Scala concepts. After that you can move to the more Scala specific features that are appropriately presented in the Scala tutorials from the official site. I found the tutorials very concise and a good introduction to all the major concepts of Scala. As for books, there is only one I know off at this point and it is the Programming in Scala book. It is due out at the end of July, but you can already get a PDF version and preorder the book. I've heard positive things about it and I have preordered the paper version.

So after reading all this, what next? Well as for everything else in computer science, you have to start coding. Starting up is fairly easy, you can follow the documentation on the official site, and you should be compiling and running in no time. There are Ant and Maven targets available so integrating it into an existing project is fairly easy. As for which IDE to use, I've tried Netbeans, Eclipse and IntelliJ IDEA. They all have Scala plugins, at more or less advanced stages. Although I am a big IDEA fan, the Eclipse plugin is for now doing the best job, although it is by no mean very stable. I am, however, going to keep a close eye on IDEA 8 and the Scala plugin that is scheduled to come out shortly after. Scala is completely compatible with existing Java libraries, so you won't have to reinvent the wheel for every part of your program. This goes for all libraries and not just the trivial ones, I've successfully used Scala with Hibernate for example. You should have no problem running inside an application server either. Therefore, there is no reason to start from scratch with Scala, you can just take a component of your application and implement it with Scala, and keep the rest of your existing code.

Personally, I have implemented an Applet using Scala and I found the language very pleasant once you get used to the syntax. You can do some things very efficiently, and I find that the language is generally very readable. Java is definitely very verbose compared to Scala, and I found that having no checked exceptions and closures really make the code focus on the "what" of the program and much less on the "how". The use of Actors for Swing, is also very interesting and made for some really readable event driven code. I can warmly recommend that you give this a shot, if only to get a perspective on different programming constructs.

The Java Mobile & Embedded Developer Days

This week I had the privilege to go to the Java Mobile & Embedded Developer Days in Santa Clara near San Francisco. It was a most pleasing experience and taken into account that this was the first instalment (and hopefully not the last), it all went surprisingly well. Now, mind you, this is no JavaOne, I think there was between 150 and 200 people at the conference over the two days it was scheduled for, so it is at the smaller end of the scale. However, size doesn't always matter and when you come to conferences smaller is sometimes better because you can go more in depth with specialized topics. This was not necessarily true for this one though and in my opinion it may not have gone so much in depth as it could have. A disclaimer before moving on, I am not in any way an experienced embedded systems specialist and have very limited experience with Java in that field. I've done some C and assembly coding in that area, but no Java development. Yet that did not matter much at this conference even though it taunted to be aimed at intermediate to experienced developers, which left me wonder a little bit. Okay, so let's dive into what happened.

As is customary to a lot of Sun sponsored conferences, James Gosling gave the keynote of the conference. Nothing revolutionary in his talk (There was even the usual: Stop using emacs, damnit!), the mobile platform is the desktop of tomorrow and we'll end up having several billions of devices, so let's put the ease of development that Java offers in there. As a guy having coded C on embedded systems (or any other system), I certainly will not disagree with him on this point. The performance of Java has at this point surpassed C and C++ in a lot of performance benchmarks, so this should be a non issue at this point. However, still remains the large footprint of a JVM in terms of memory and power consumption, but more on that later. Announced was the open sourcing of Project Squawk which is a Java based implementation of the JVM (chicken and the egg problem, anyone?), but besides from that it was your average opening keynote. I wasn't able to find the slides online anywhere, maybe they died with James's laptop (At least I would expect this ones not going to have a long lifetime with the amount of complaining from James), but you can find all the other slides here. After that it was on to the technical sessions.

Since this was a fairly conference, there never was more than two concurrent sessions at a time, so you would never miss too much of what was going on. The first session was about JavaME security domains. It was an attempt to address the frustrations that developers have with all this damn security that prevents them from doing what they want. Listening at the presentation it reminded me a lot of the trouble with Applets, although there it could almost always be solved by just signing your application jar. With JavaME you can also sign your application, but that guarantees almost nothing since it is left up to the actual phone manufactured and network providers to define the security policies. That means that if your signed application works with one provider (although most likely with a lot of warnings and prompts thrown at the user), you have no guarantee it will work with another provider or even work with future phones of the same provider. This was a recurring theme of the conference, the providers (and the manufacturers to a certain degree) have made it pretty much impossible to easily port your application from one provider to the other by putting a lot of customized settings to their platforms. Frustrating...

Next up was a presentation of NFC (Near Field Communication) which is basically a short range communication protocol (like 4 cm). The idea is that you just bring your device up to a another NFC device and they can interact to say: Transfer business cards or process payment at the store. The idea is that, since it is such a short range, it is more secure (yeah, I already see myself curled in the corner of the metro to avoid virtual mugging through close contact). It introduces JSR 257, which introduces what I would call a very standard API with listeners, factories and extensibility through interfaces. Looks easy enough to use and potentially has a ton of possible applications, so now all we need is for some actual devices to go out there and use it.

On came Sun and their Sun SPOT team, and that is when the little geek in me got its biggest "Wow! This is cool!" moment of the conference. A Sun SPOT is a small device that is equipped with an ARM processor, temperature and light sensor, accelerometer, wireless, LEDs and a bunch of I/O ports. So what can you use that for? Well everything you want, it is basically a prototyping platform for all kinds of embedded systems. It is easy to use and you will not have all the usual hardware problems to deal with when first trying out your idea. It is fairly cheap (550$ for 3 SPOTs and a base station) and comes with a fairly impressive Netbeans integration. It is pretty much a geeks dream when it comes to toys :-) Yet, I can definitely see the commercial potential of providing hardware for companies to do quick prototyping of new products. At the conference, there was a demonstration of how these had been used to create a bunch of cheap robots to study swarm behavior. Very cool!

The rest of the first day's technical sessions was less interesting, it basically boiled down to a Netbeans tutorial (after all it is a Sun conference). Granted Netbeans is getting better and better, and version 6 definitely makes it cross line between annoying and usable, but come on, this is something that you can go read a tutorial to figure out and while one session about it is okay, let it go, we'll go check it out, stop trying to push down our throats.

To conclude the first day, and before going to Maria Elena's Mexican restaurant for a sociable evening, a panel discussion with representatives from phone manufacturers, network providers and a few software people. The moderators had a script running about what a developer needs to do to get to the mobile market with some new software. This was all very depressing, because what the panel was saying is that you basically need to bow to the network providers. They really don't want you on their phone without them making money out of it. They want to be the physical distributor and the content controller, a little bit like the music industry. Basically you buy a phone but you can't just do what you want with it. They were interrupted mid way by a rebellious voice from the audience, wanting to direct the conversation towards "Why bother making software for mobile phones?". In my opinion, the core of the problem even though the manufacturers have an incentive to get creative software on their phones, the network provider have killed creativity by closing the platform completely to external sources (at least in the US. Asia and Europe seem to have moved beyond that and at this point have a lot more mobile applications than the US). So sad, but I cannot help to wonder what the iPhone will do to this business model after the release of the SDK next month. One can hope that it will force operators to open up to third party applications.

After a good nights sleep, it was time for the second day of the conference. Sadly, it was only 2/3 of a day for me, because I had to leave early to beat the snow storm and get back to Los Angeles. So most of what I saw was dedicated to JavaFX Mobile and PhoneME. JavaFX mobile is not just a mobile implementation of JavaFX the scripting language, it is a complete operating system for the phone, much like... well, PhoneME. So why is that we have two platforms competing within Sun? I do not know and that wasn't really properly addressed. We already have a segmented platform on the mobile market, so why add even more? The talks were somewhat interesting, but it was hard to get exited by yet another phone operating system.

Lastly there was a presentation of Project Squawk. This was by far the most interesting presentation for me, the goal of the project is to rewrite as much as possible of the JVM to java code to make it easier to port to other platforms, embedded platforms among others. Another advantage is that it is a lot easier to cut parts of the JVM and only have what you need to run your application on the given platform. Sort of a customized JVM. Really interesting and since it is now open source everybody can go check out some JVM code without being a C expert. Really cool.

So what is the conclusion for this conference? If I had to sum it up in as few words as possible it would be: Embedded: Cool! Mobile: Sad. The complete clustering and lock down of the mobile platform makes it really unattractive for developers, which is really sad, since there is a lot of cool ideas to explore. So for now, I would stick with embedded if I had to go smaller.

What are closures and what do they mean to Java?

I will try and show an example of what closures can be used for and how this functionality looks like if implemented in the current version of Java. I will be using the Scala programming language to demonstrate a closure. Scala is a brand new language that is running on the JVM. I am by no measure a Scala expert, actually prior to writing this post I've only spent a few hours looking at the language. Therefore if you are a Scala guru, please be gentle if commenting about the code.

Before showing you the code, let's first define what a closure is. According to Martin Fowler: A closure is a block of code that can be passed as an argument to a function call. It's not a new idea, it has been around since Scheme in the 60's. It was usually associated with functional programming and not object oriented programming, but it now exists in many OO languages like Ruby and C# (2.0). So what is that you can do with them that you cannot do in Java now?

Let us take an example of what a closure could be used for. File manipulation is a common function in any language and in many languages it requires resource handling of some sort. Doing file operations can usually be abstracted to: Opening the file, so your stuff, close the file. If you forget to close the file, this might lead to your process running out of file pointers. So let's try and abstract resource management a bit and let's write a method on a file that will let you perform an operation on each line of a file without having to worry about opening and closing the file. The example below is as I said in Scala. One of the very nice features is that you can reuse all existing Java classes, so I'll extend the File class and add a forEachLine method to it. This method allows you to pass a block of code that will be executed on each line of the file. So here is the new class:

package ScalaApplication2

import java.io.File
import java.util.Scanner

class ScalaFile(filename: String) extends File(filename: String) {

       def forEachLine(parseLine: (String) => Unit) {

               val scanner = new Scanner(this)
               try {
                       while ( scanner.hasNextLine() ) {
                               parseLine(scanner.nextLine())
                       }
               } finally {
                       scanner.close()
               }
       }

       def compareTo(other: Any): Int = {
               0
       }

}

So what is going on here? We've extended the File class and added a new method called forEachLine. It takes on parameter named parseLine and it is defined as a function type which takes one parameter of type String and returns nothing (Unit seems to be the synonym of void). As you can see, it is very easy to define a function as a parameter to a method in Scala and it is equally easy to use it inside the while loop. So now that we've implemented this new method let us look at how it can be used.

package ScalaApplication2

object ScalaMain {

       def main(args: Array[String]) = {
               val file = new ScalaFile("C:\\testFile.txt")
               var charCount = 0
               file.forEachLine((line: String) => {
                       println(line)
                       charCount += line.length()
               })
               println("Number of characters in File: " + charCount)
       }

}

So here we use the forEachLine method to print each line and count the number of characters in the file. To do this we create an anonymous function and as can be seen it is fairly straight forward. Note that the variable charCount is defined outside the scope of the anonymous function and yet can seamlessly be used inside the code block of the anonymous function. Keep that in mind for later.

Our goal of hiding resource management is reached since opening and closing the stream in encapsulated inside the forEachLine method of the ScalaFile class. Now let us look at how we can do this in Java. To get closure like behavior in Java, we need to use interfaces and anonymous classes. Below is the implementation of the new File class that we will us.

package javaapplication1;

import java.io.File;
import java.io.FileNotFoundException;
import java.util.Scanner;
import java.util.logging.Level;
import java.util.logging.Logger;

public class JavaFile extends File {

       public JavaFile(String filename) {
               super(filename);
       }

       public void forEachLine(JavaFileCallback callback) {

               Scanner scanner = null;
               try {
                       scanner = new Scanner(this);
                       while(scanner.hasNextLine()) {
                               callback.parseLine(scanner.nextLine());
                       }
               } catch (FileNotFoundException ex) {
                       Logger.getLogger(JavaFile.class.getName()).log(Level.SEVERE, null, ex);
               } finally {
                       if(scanner != null) {
                               scanner.close();
                       }
               }

       }

       public interface JavaFileCallback {

               void parseLine(String line);

       }

}

Since we cannot pass functions or methods (at least not in a type safe way) as a parameter to our method we have to use an interface with a callback method. Still our goal is accomplished, the stream is opened and closed inside our forEachLine method. Now let's look at what the caller has to do.

package javaapplication1;

import javaapplication1.JavaFile.JavaFileCallback;

public class JavaMain {

       public static void main(String[] args) {

               JavaFile javaFile = new JavaFile("C:\\testFile.txt");
               final int[] charCount = {0};
               javaFile.forEachLine(new JavaFileCallback() {
                       public void parseLine(String line) {
                               System.out.println(line);
                               charCount[0] += line.length();
                       }
               });
               System.out.println("Number of characters in File: " + charCount[0]);
       }

}

In Java, instead of having an anonymous function, we have an anonymous class that we pass to our forEachLine method. Now we all know that variables from the parent class cannot be accessed inside the anonymous class unless they are declared final. So how do we pass on our charCount variable? Well, we have to use a final object reference which variables we can mutate. In this case, we simply use an array. This adds some overhead but it is the only way to do it.

I've just demonstrated that we can replicate the exact behavior of closures with interfaces and anonymous classes. I will even go as far as saying that anything a closure can do, you can implement using the current version of Java (I will stand by this until proven wrong :-). However, that is not so much the point. This is a very simple example and there are more complex uses of closures which require even more complex code in Java. Therefore, the point is that you can do some fairly complex things with little and simple code in a language that has closures built in. In Java, you can do it but let us be honest it does not look pretty. Yet we do it everyday. Think of how many times you've had to create a runnable or callable to simply pass it on to an execution service. It would be much nicer to simply pass blocks of code around instead of actual classes and interfaces.

This is not intended to add anything new to the debate about closures in Java, just to give you an idea of what they are through a simple example. If you're interested in knowing more about closures and the many problems that need to be resolved if we want them in Java, you should check out Neal Gafter's blog. He is one of the driving forces behind the current proposal for Java and has many more examples and in depth discussions about the pros and cons (let's face it mostly pros, but it's still good reading).