A Java geek

This week saw another flame war from some of the Scala crowd. This time, it was toward Stephen Colebourne, the man behind Joda time.

The article in question can be found here, and Stephen’s answer here.

To be frank, I tend to agree to Stephen’s predicat but for very different reasons. Now, if you’re a Scala user, there are basically 2 options:

• either you react like some did before, telling me I’m too stupid or too lazy to really learn the language and stop reading at this point. In this case, I’m afraid there’s nothing I can say apart from ‘Please, don’t harm me’ because it has a feeling of religion war coming from supposedly scientific-minded people.
• Or you can read on and we’ll debate like educated people.

Truth is, I’m interested in Scala. I try to program in Scala for personal projects. So far, I’ve gotten the hold on traits (what I would do to have them in Java) and closures and I’ve understood some of the generics concepts (so long as it’s not too complex). I plan on diving in the Collections API to better use closures next.

I think that Scala, like EJB2, was designed by smart, even brilliant people, but with a different experience than mine.

In real life, projects are full of developpers of heterogeneous levels: good developers, average developers and bad developers. And please don’t blame it on the HR department, the CEO or the global strategy of the company: it’s just Gaussian distribution, just like in any population.

In effect, that makes Scala a no-go in most contexts. Take Java as an example. What did it make it so successful, even with all its lackings? The compile-once, run-everywhere motto? Perhaps, but IMHO, the first and foremost reason behind Java success is the change of responsibility in memory management, from developers (like in C/C++) to system administrators. Before, the worse the developer, the higher the probability of a bug in memory management but Java changed all this: it’s not perfect, but much simpler.

Like Freddy Mallet, I’m sure a technology has to be simple to become mainstream and Scala has not taken this road. As a consequence, it’s fated to stay in a niche market… Stating this should raise no reactions from anybody, it’s just a fact.

Note: aardvarks will be a point for a future blog post.

My article from last week left me mildly depressed: my efforts trying to ease my Vaadin development was brutally stopped when I couldn’t inherit from a Java inner class in Scala. I wondered if it was an impossibility or mere lack of knowledge on my part.

Fortunately, Robert Lally and Dale gave me the solution in their comments (many thanks to them). The operator used to access an inner class from Java in Scala is #. Simple, yet harder to google… This has an important consequence: I don’t have to create Java wrapper classes, and I can have a single simple Maven project!

Afterwared, my development went much better. I tried using the following Scala features.

Conciseness

As compaired to last week, my listener do not use any Java workaround and just becomes:

@SerialVersionUID(1L)
class SimpleRouterClickListener(eventRouter:EventRouter) extends ClickListener {

 def buttonClick(event:Button#ClickEvent) = eventRouter.fireEvent(event)
}

Now, I can appreciate the lesser verbosity of Scala. This becomes apparent in 3 points:

• @SerialVersionUID : 10 times better than the field of the same name
• No braces! One single line that is as readable as the previous Java version, albeit I have to get used to it
• A conciseness in the class declaration, since both the constructor and the getter are implicit

Trait

CustomComponent does not implement the Observer pattern. Since it is not the only one, it would be nice to have such a reusable feature, in other words, a Scala trait. Let’s do that:

trait Router {

  val eventRouter:EventRouter = new EventRouter()
}

Note to self: next time, I will remember that Class<?> in Java is written Class[_] in Scala. I had the brackets right from the start but lost 10 minutes with the underscore…

Now, I just have to declare a component class that mixin the trait and presto, my component has access to an event router object.

Late binding

Having access to the event router object is nice, but not a revolution. In fact, the trait exposes it, which defeats encapsulation and loose coupling. It would definitely be better if my router trait would use the listener directly. Let’s add this method to the trait:

def addListener(clazz:Class[_], method:String) = eventRouter.addListener(clazz, this, method)

I do not really know if it’s correct to use the late-binding term in this case, but it looks like it, since this references nothing in the trait and will be bound later to the concrete class mixing the trait.

The next stop

Now, I’ve realized that the ClickListener interface is just a thin wrapper around a single function: it’s the Java way of implementing closures. So, why should I implement this interface at all?

Why can’t I write something like this val f(event:Button#ClickEvent) = (eventRouter.fireEvent(_)) and pass this to the addListener() method of the button? Because it doesn’t implement the right interface. So, I ask myself if there is a bridge between the Scala first-class function and single method interfaces.

Conclusion

I went further this week with my Scala/Vaadin experiments. It’s getting better, much better. As of now, I don’t see any problems developing Vaadin apps with Scala. When I have a little more time, I will try a simple app in order to discover other problems, if they exist.

You can find the sources of this article here, in Maven/Eclipse format.

To go further:

• Adventures with Scala and Vaadin, another experiment on the same path, more than one year ago
• Scala limitation regarding Java static inner class

People who are familiar with my articles know that I’m interested in Vaadin (see the “Go further” section below) and also more recently in Scala since both can increase your productivity.

Environment preparation

Thus it is only natural that I tried to embed the best of both worlds, so to speak, as an experience. As an added challenge, I also tried to add Maven to the mix. It wasn’t as successful as I had wished, but the conclusions are interesting (at least to me).

I already showed how to create Scala projects in Eclipse in a previous post, so this was really a no-brainer. However, layering Maven on top of that was trickier. The scala library was of course added to the dependencies list, but I didn’t found how to make Maven compile Scala code so that each Eclipse save does the compilation (like it is the case with Java). I found the maven-scala-plugin provided by Scala Tools. However, I wasn’t able to use it to my satisfaction with m2eclipse. Forget the Maven plugin… Basically what I did was create the Maven project, then update the Eclipse configuration from Maven with m2eclipse and finally add the Scala builder: not very clean and utterly brittle since any update would overwrite Eclipse files. I’m all ears if anyone knows the “right” way to do!

Development time

Now to the heart of the matter: I just want a text field and a button that, when pressed, displays the content of the field. Simple enough? Not really. The first problem I encountered was to create an implementation of the button click listener in Scala. In Vaadin, the listener interface has a single method void buttonClick(Button.ClickEvent event). Notice the type of the event? It is an inner class of Button and wasn’t able to import it in Scala! Anyone who has the solution is welcome to step forward and tell it.

Faced with this limitation, I decided to encapsulate both the listener and the event class in two standard Java classes, one in each. In order to be decoupled, not to mention to ease my life, I created a parent POM project, and two modules, one for the Java workaround classes, the other for the real application.

Next obstacle is also Scala-related, and due to a lack of knowledge on my part. I’m a Java boy so, in order to pass a Class instance, I’m used to write something like this:

eventRouter.addListenerVisibleClickEvent.class, this, "displayMessage")

Scala seems to frown upon it and refuses to compile the previous code. The message is “identifier expected but ‘class’ found”. The correct syntax is:

eventRouter.addListener(classOf[VisibleClickEvent], this, "displayMessage")

Moreover, while developing, I wrote a cast the Java way:

getWindow().showNotification(button.getCaption() + " " + (String) field.getValue())

My friend Scala loudly complained that “object String is not a value” and I corrected the code like so:

getWindow().showNotification(button.getCaption() + " " + field.getValue().asInstanceOf[String])

Astute readers should have remarked that concatenating strings render this cast unnecessary and I gladly removed it in the end.

Conclusion

In the end, it took more time than I I had done the example in Java.

• For sure, some of the lost time is due to a lack of Scala knowledge on my part.
• However, I’m not sure the number of code lines would have been lower in Java, due to the extra-code in order to access inner classes .
• In fact, I’m positive that the project would have been simpler with Java instead of Scala (one project instead of a parent and 2 modules).

The question I ask myself is, if Scala cannot extend Java inner classes – and that being no mistake on my part, should API evolve with this constraint? Are inner classes really necessary in order to achieve a clean design or are they only some nice-to-have that are not much used?

In all cases, developers who want to code Vaadin applications in Scala should take extra care before diving in and be prepared to have a lower productivity than in Java because there are many inner classes in Vaadin component classes.

You can find the sources for this article here in Maven/Eclipse format.

To go further:

• Vaadin Spring Integration
• Chicken and egg problem with Spring and Vaadin
• Server-client push with Vaadin
• Playing with Spring Roo and Vaadin

In this article, I will show you how to tweak Eclipse so that you will be able to code “classical” webapps in Scala.

Note: I know about Lift, I just want to see how Scala can integrate in my existing infrastructure step-by-step.

Setting up your Eclipse project

Eclipse has a plugin(found at the Scala IDE site) that let you help develop with Scala. The plugin is by no mean perfect (autocompletion does not works in Ganymede), but it gets the job done, letting you create Scala projects that automatically compile Scala code with scalac.

The Web Tools Platform, another Eclipse plugin, let you create web application projects that can be deployed to application servers.

Most projects created with one or another Eclipse plugin are compatible with one another. For example, you can create a new Dynamic Web Project, then add a JPA extension and presto, you can now use the Java Persistence API in you project. Likewise, you can add a Vaadin extension to your Web Project and you can use Vaadin in it. These extensions are called “Facets” in Eclipse. Each project can have many facets: Java, JPA, Vaadin, etc. depending on the plugins you installed.

Unfortunately, the Scala plugin does not use the Facet mechanism. Thus, Dynamic Web Projects cannot be enhanced with the Scala facet. Creating a web project that compiles your Scala code requires a little tweaking. First, you should create a simple Dynamic Web Project. Then, open the .project file. If you do not see the file, go to Customize View in the view and uncheck .*resources in the Filter tab (the first one). It should look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
    <name>scala-servlet-example</name>
    <comment></comment>
    <projects>
    </projects>
    <buildSpec>
        <buildCommand>
            <name>org.eclipse.wst.jsdt.core.javascriptValidator</name>
            <arguments>
            </arguments>
        </buildCommand>
        <buildCommand>
            <name>org.eclipse.jdt.core.javabuilder</name>
            <arguments>
            </arguments>
        </buildCommand>
        <buildCommand>
            <name>org.eclipse.wst.common.project.facet.core.builder</name>
            <arguments>
            </arguments>
        </buildCommand>
        <buildCommand>
            <name>org.eclipse.wst.validation.validationbuilder</name>
            <arguments>
            </arguments>
        </buildCommand>
    </buildSpec>
    <natures>
        <nature>org.eclipse.jem.workbench.JavaEMFNature</nature>
        <nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
        <nature>org.eclipse.wst.common.project.facet.core.nature</nature>
        <nature>org.eclipse.jdt.core.javanature</nature>
        <nature>org.eclipse.wst.jsdt.core.jsNature</nature>
    </natures>
</projectDescription>

Replace the org.eclipse.jdt.core.javabuilder with org.scala-ide.sdt.core.scalabuilder. Note: you can remove the Java builder with the IDE but you cannot add another one so hacking the configuration file is a necessary evil. Now add the Scala nature to your project: <nature>org.scala-ide.sdt.core.scalanature</nature>.

The .project file should now look like this:

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
    <name>scala-servlet-example</name>
    <comment></comment>
    <projects>
    </projects>
    <buildSpec>
        <buildCommand>
            <name>org.eclipse.wst.jsdt.core.javascriptValidator</name>
            <arguments>
            </arguments>
        </buildCommand>
        <buildCommand>
            <name>org.scala-ide.sdt.core.scalabuilder</name>
            <arguments>
            </arguments>
        </buildCommand>
        <buildCommand>
            <name>org.eclipse.wst.common.project.facet.core.builder</name>
            <arguments>
            </arguments>
        </buildCommand>
        <buildCommand>
            <name>org.eclipse.wst.validation.validationbuilder</name>
            <arguments>
            </arguments>
        </buildCommand>
    </buildSpec>
    <natures>
        <nature>org.scala-ide.sdt.core.scalanature</nature>
        <nature>org.eclipse.jem.workbench.JavaEMFNature</nature>
        <nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
        <nature>org.eclipse.wst.common.project.facet.core.nature</nature>
        <nature>org.eclipse.jdt.core.javanature</nature>
        <nature>org.eclipse.wst.jsdt.core.jsNature</nature>
    </natures>
</projectDescription>

If you made the right change, you should see a S instead of a J on your project’s icon (and it should keep the globe!).

The last thing to do should be to add the Scala library to your path. Depending on your application server configuration, either add the Scala library to your build path (Build Path -> Configure Build Path -> Add Library -> Scala Library) or manually add the needed library to your WEB-INF/lib folder. You’re all set to create your first Scala servlet!

Creating your servlet

In order to create your servlet “the easy way”, just do New -> Other -> Scala Class. Choose a package (it is a good practice to respect the Java guidelines regarding the class location according to its package name). Choose the HttpServlet as the superclass. Name it however you please and click OK.

It seems to compile but you and I know there will be some problem later since you don’t override the servlet’s doGet() method. Do it:

override def doGet(request:HttpServletRequest, response:HttpServletResponse) {

}

Don’t forget the imports. Let’s use the Scala way:

import javax.servlet.http.{HttpServlet, HttpServletRequest, HttpServletResponse}

Last but not least, let’s code some things for your servlet to do. Since I’m feeling very innovative, I will print the good old “Hello world!”:

override def doGet(request: HttpServletRequest, response: HttpServletResponse) {

  response setContentType ("text/html")

  val out = response getWriter

  out println """<html>
  <head>
      <title>Scala Servlet
  <body>
      <p>Hello world!"""
  }
}

Don’t forget to add the servlet to your web.xml and presto, you should see some familiar example, in a familiar IDE, but with some unorthodox language.

Conclusion

Once Eclipse correctly set up, it’s pretty straightforward to develop your webapp in Scala. I do hope the next version of the Scala IDE plugin will definitely improve Scala’s integration into Eclipse and WTP further.

Here are the sources of the example, in Eclipse format.

To go further:

• The Scala Programming Language
• The Scala IDE site
• Scala for Java refugees