de.velopmind | The Det about Programming

February 16, 2011

Quicknote: Overcoming the Java-verbosity…

Filed under: Java, Language — de.velopmind @ 5:44 am

Interesting, what ideas people have to avoid the clutter of Java-code:

public Type someMethod() {try{

       Some   x = getA().getB().getC();
       if (x.check())
          return x.getR().createT();
          return new Type(x);

}catch(Exception e){ return null; }}

January 23, 2011

Guice 2.0 Multibinder + Java ServiceLoader = Plugin mechanism

Filed under: Java — Tags: — de.velopmind @ 12:47 am

Currently I have the task to extend an existing legacy Java Swing client with a plugin mechanism. As I hadn’t looked into this topic before, I tried to get an idea about the possibilities and what others do.

The first things to explore when talking about Java and Plugin are surely the IDEs like Eclipse and Netbeans, as for them the plugins are an elementary part, and so they should show how to do it right.

While Eclipse has an elaborated but quite obscure extension mechanism, Netbeans uses a proprietary lookup mechanism, which is an advanced version of the standard ServiceLoader feature.

This ServiceLoader, standard part of Java 6, is the simples approach to extensibility. Some part of the Software (the consumer) defines an Interface, which another part (the provider) must implement.

Then the consumer uses the ServiceLoader API to get all classes which implement that interface, and here we are.

The lookup is really simple: The provider contains in its Jar a directory named META-INF/services. In that there is a text file which is named like the fully qualified name of the interface (without any file extension). The file contains now the fully qualified name of the implementing class in this jar.

So you only have to throw that jar somewhere into the classpath of the application, and the consumer will get an instance of the implementing class.

And just here are the limitations of this approach:

  • Every lookup retrieves a new instance.
  • Every instance is constructed via its parameterless default constructor.

That’s it. As the name ServiceLoader may suggest, this mechanism is meant for loading services, not plugins.  And in its simplest form it is for stateless services. To overcome this last limitation, one would have to wrap the service loading into a singleton of a special service class which keeps the dependency to the implementing class hidden.

This seems not to be helpful so far.

Now, when we talk about plugins, we talk about Dependency Injection, and there are already nice solutions for that, for example Googles Guice, which is currently in its version 2.0,  but with 3.0 on the way, which will be based on the new JSR-330 specification,  now becoming the standard for DI in Javaland.

Guice is  a very nice thing.  DI is handled solely by annotations of classes and consuming constructors, methods or fields.

As injected instances can themselves depend on injections, and as we can declare Providers (say: factories), this system is very flexible and able to work with parameterised constructors, singleton instances and so on.

So even in complex situations Guice can provide  valid object trees.

Guice also  provides a nice Java API to declare the bindings from interface to implementation.  And here we have two problems :

  1. The standard approach is indeed, to inject the implementation for a required interface, not all of them.
  2. The configuration is provided in a Java class which inherits from Guice’s Module and implements the configure() method.  Reconfigure means: recompile.

The first problem is already addressed by the Multibinder, which was new in Guice 2.0.  With this binding approach, different providing jars can implement an interface, register the binding, and a consumer can get all the implementations. This allows for real extension points and extensions.

But Plugin is even more: It is the possibility to plug some extension in, so to configure the application on customer site, not at compile time.

As the Guice wiki states:

Finally we must register the plugins themselves. The simplest mechanism to do so is to list them programatically:

public class PrettyTweets {
  public static void main(String[] args) {
    Injector injector = Guice.createInjector(
        new GoogleMapsPluginModule(),
        new BitlyPluginModule(),
        new FlickrPluginModule()


If it is infeasible to recompile each time the plugin set changes, the list of plugin modules can be loaded from a configuration file.

Unfortunately the wiki forgot to say how. This may be left as a task to the reader.

Well, to allow for extensibility on customer site, a plugin jar would have to be put into the classpath and explored on startup. And yes, there is some work for that on the way: Guice Automatic Injection , by Daniel Manzke, which will bring the big right solution.

But wait, in the meantime there can be a simpler solution. If we look at the main method code above, which depicts the standard Guice startup, we see that all Module classes are created by their parameterless default constructor.  But wasn’t that exactly for what ServerLoader was useful for?

Indeed now we see a feasible architecture for our plugin mechanism.

  1. Create extension points by defining interfaces on consumer site.
  2. Expect to get all implementations injected by Guice’s multi mechanism
  3. Create a markup interface to mark all Module classes that configure plugin implementations.
  4. Let different parties implement the interface from 1 and register them per Multibinder in a special Module subclass which implements the markup interface from 3.
  5. Let these parties declare the Module subclass as implementation for the markup interface in the META-INF/services folder of their jar.
  6. In your application startup code (main method) use ServiceLoader to get all Module instances  that implement that markup interface and use them to create the injector.

Here are some code examples from a little test workspace:

Let’s start with the thing that causes all this trouble: The component containing the extension point:

package modone;

import java.util.Set;

public class ModOneImpl implements ModOne {
    @Inject(optional=true) Set<ModOneExtension> mPlugins = new HashSet<ModOneExtension>();

    public String getSomeval() {
        String r = "Someval from ModOneImpl ";
        for (ModOneExtension p : mPlugins)  {
            r = p.extend(r);
        return r;

So this class has a method getSomeval which returns a String value, but gives some extensions/plugins the chance to do some processing on the string before it is returned.  The class ModOneImpl defines the extension point by expecting an injected Set of implementors of  ModOneExtension, the interface that declares  the called extend method.

As there may be no plugin at all on the classpath, the injection is marked optional with an empty set as default initialisation.

Let’s assume that our application has more than one of such extension points, so we declare the application as a whole to be extensible by plugins by creating a markup interface:

package myapp;


public interface PluginModule extends Module {}

Each plugin now creates its specific implementation of the extension interface, e.g. like this:

package pluginone;

import modone.ModOneExtension;

public class PluginOne implements ModOneExtension {
     public String extend(String x) {
          return  "extended(one): "+x;

Additionally, this implementation is bound to that interface in the  module configuration class:

package pluginone;

import modone.ModOneExtension;
import myapp.PluginModule;

public class PluginOneModule extends AbstractModule implements PluginModule {
   public void configure() {
     Multibinder<ModOneExtension> mbinder = Multibinder.newSetBinder( binder(), ModOneExtension.class);

That was the Guice part, and now the ServiceLoader part.

Create a file in the directory META-INF/services named:  myapp.PluginModule .

This file only contains one line:   pluginone.PluginOneModule

Now what is left is the application’s startup code:

package myapp;

import modone.ModOneModule;
import modrep.ReportModule;


import myapp.PluginModule;
import java.util.ServiceLoader;

import java.util.List;
import java.util.ArrayList;

public class Main {
   public static void main(String[] args) {
       List<Module> modlist = new ArrayList<Module>();
       modlist.add( new ModOneModule() ); // declare app modules the standard way
       modlist.add( new ReportModule() ); 

      ServiceLoader<PluginModule> extensions = ServiceLoader.load( PluginModule.class );
      for(PluginModule ext : extensions) {
          modlist.add(ext);         // add each found plugin module

      Injector inj = Guice.createInjector( modlist );
      ReportApp appl = inj.getInstance( ReportApp.class );;

In this main method we see how the list of all modules is created and filled with the standard application modules.   The plugin modules then are looked up by the markup interface PluginModule via the ServiceLoader mechanism and added to that list.

In the end the injector is created and the application started by getting the first managed instance from the injector, like usual.

To add more plugins, simply put their jar files on the classpath and they will be configured and managed by Guice automatically.

I hope that you enjoyed this little experiment.

PS: If you want to configure only loaded plugin modules with your injector, you can directly put the ServiceLoader instance into the createInjector() method, as the latter requires an Iterable instance, and the ServiceLoader implements this interface.

Edit: After I finished this article, I found a similar approach on Stackoverflow, with a nice alternative for module loading.

August 7, 2010

Google Wave starving?

Filed under: GoogleWave — Tags: — de.velopmind @ 4:46 pm

Yesterday I got notified by my son, that Google has announced the end of Wave. I was really surprised and cannot really understand it.

The reason they give is:

“But despite these wins, and numerous loyal fans, Wave has not seen the user adoption we would have liked.”

And here I can only respond: “Hey Google, what did you expect??”. So, as a Java/Scala developer and a Wave user since December ’09,  I will try to reflect a bit about it.

To just start with a resume: “Google, you are impatient like a farmer who pulls on the plants to make them faster growing.”

They definitely should read Sernaferna’s blog post and reconsider things.

How does it look from my perspective now?

First, some history. When Wave was introduced, it was only accessible for some elitarian developers who somehow managed to get a sandbox account.  It took some time until Wave reached a broader mass with the preview access. (This was on 30. Sept. ’09, reg. german Wikipedia) But even that only worked on an invitation basis.  I remember googling about that Wave-thing, and hitting so many forum posts saying: “Would like to test it, but does anyone know how I can get an invitation?”.  It stayed being an insider thing, and even for me as a developer it took some time until I found someone who knows someone who had a preview account, so we could activate an invitation chain.

I suppose Google hoped for a more enthusiastic multi-level marketing, but that did not work as expected.


Well, for myself, I can’t use something like wave from my office, as we work half closed-shop.  So Wave was a private hobby. But outside my office I mostly use a Dell mini 9 netbook ( 8″ display), and Wave was simply not ready for use on such a device. For me it was ok to work with a slow web interface, reduced space and display problems here and there, like a jumping blip view on scrolling.  In the beginning I even lost some waves.  Say: Wave was buggy, somewhere between beta and alpha.

Nothing to sell it to my friends, even the younger ones.  Only for some fellow computer freaks it was an interesting topic, but beside Wave we already had other channels, and because of the mentioned instabilities we did not trust it with serious stuff.

Things have changed since then, but only in the last half year at most.

We would have liked to do more with Wave, if it only would have been more integrated with the “classic” channels, like email, twitter, blogs and chat. But for us using Wave was always an either-or, never an also or integrated with.

What did we do with Wave?  We tried to understand how it works. We discussed interesting use cases, and we tried to understand the spare documentation about protocols, data models and other interna.

People started some very interesting developments, even I did, by trying to give the robot API a Scala touch.

But the information came drop-wise, often one had to study the source code, and at least the Java part underwent heavy changes. Documentation was spread on a good bunch of web pages (not easily downloadable or printable), which even were target of unnoticed updates.

All these consumed far too much of my short free time, so the ideas were many, the progress low.

Only step by step the internas of Wave hit the public of interested developers, and bit by bit we got more interesting (and stable!) gadgets and robots.

Since the 18th of may this year Wave is available for everyone. So it seems to have reached a trustworthy stability, left the elitarian status, so that we can tell our friends now about it. There was June, there was July (with the start of summer holidays here in Germany, so communication went down generally). And now August has only started and instead of selling it to more and more people now with words like “i’ve experienced it for some time now, and now it it is available for you too”,  all we can tell our friends after holiday is:  Wave? Yeah, I know, but forget it. It will stop soon.

Not after one year (it isn’t even September now), but after three months now -as we should not really count the closed alpha/beta phase- Google has called for shutdown.

Was Google really expecting all the people out there to be bleeding-edgers? To be Beta-Junkies? New-Hype-Jumpers?  I can’t really believe it.

And what about the promises to make Wave available outside of Google Web apps? As a locally installable server on own domains, like all the mail servers?

Nothing to see from that. Boys, everyone can install a serious mail server on every Linux distribution. Even on windows there is no problem to install a mail server. The same for Web server (blog, wiki) and for IM (Jabber server).

We were waiting to play around with Wave in this way too, but FedOne was not really the way for freetime experimenters, as it was not as fully featured as Googles own service. I hoped there would be time for someone to bring up a usable implementation, or more feature complete software would have come out of the Google labs.

But now it ends even before it really began. This is disappointing. Have we developers and early-adopters all been only Google’s laboratory rats?

And regarding the user interface:  Google only published a console client. But I know many many people who use Outlook or Thunderbird, or comparable local clients. The web interface is always only a fallback. The same is true for chat clients. But for Wave there was never a comparable alternative, now will there ever be one, if Google now shuts down development before people had enough time to take things over and let it mature. To play with the concepts, the protocols and the libraries.

Google, for your people it may be a long time now, but many people outside Google only started to touch Wave. It needs more than this short period to see all the necessary development to get a broad adaption.  You now pinch a green plant before it carries fruit.

July 10, 2010

Scripting with Scala vs. Groovy

Filed under: Experiences, Groovy, Scala — de.velopmind @ 11:21 pm

Last week I decided to challenge Scala’s downscalability by trying to replace a Groovy script with a Scala pendant.

In this article you will read about this little experiment and a comparision of the Scala result with the Groovy predecessor.

But first some background about the script:

Some time ago my company introduced a new spam notification system.  When it thinks that a mail contains spam, it keeps it in quarantine and once or twice a day sends an email to the recipient (me) reporting all the kept mails, together with an intranet web link for each  to release it.

Here you see an example of such a mail (note: I have my mails displayed in plain text format):

Unfortunately the spam filter holds back most of the mails I receive from mailing lists like groovy-user, scala-user, log4j and others. Each morning I would have to open such a mail and for each kept item click on a link, wait for the browser result, close the page, go back to outlook, click the next link, and so on and so on.  Sure, this is very annoying, but a request to our IT personell did not solve the problem as it seems to be impossible to administer the white list in a way to generally let mailing list stuff through. It only works on a real sender address basis.

Well, I would not be a programmer if I would not solve the problem myself.

So I opened a Groovy console and quickly hacked a little script which let me automate the calls to the URL.

Let’s look at it in detail.

When started, the script opens a small window with a text box to insert the spam guard mail text.

On pressing the “convert” button,  a new frame opens with a line for each kept mail including a check box which is pre-selected:

On pressing the action button in this frame, the script  iterates through each line and calls the corresponding URL (well, only if the checkbox is still checked). You can follow the progress by watching the checkboxes on the right, where each processed line is marked.

So with a few clicks even a good bunch of kept mails is released automatically.

As I said, the source code is a very simple hack which I threw together in round about twenty minutes, including some book/web lookups as I have never really written a Groovy SwingBuilder based GUI before, and calling aURL was also not in my recordings.

Well, trying to rewrite this thing in Scala did not went as fast, and the result is not hundred percent the same.  But let us have a detailed look at both sources side-by-side.

I started at the beginning and developed top-down. So the first thing to look at is the method that starts the input window with the text area.

Here is how this method reads in Groovy:

def inputWindow() {
    inp = new SwingBuilder()
    frame = inp.frame(title:"Insert mailtext", size:[400,400],
                      defaultCloseOperation:WindowConstants.EXIT_ON_CLOSE) {
             panel(layout: new BorderLayout()) {
                scrollPane() {
                 editorPane(id:"mail", maximumSize: [300, 300],
                            minimumSize: [300,300], preferredSize: [300,300],
                button("convert", actionPerformed: {selectWindow(inp.mail.text) },
                       constraints:BorderLayout.SOUTH )
    frame.visible = true

First step is to create a SwingBuilder, which now makes it very simple to create a frame, a panel with a scrollpane containing an editor pane and a button on it and start this form. All easily done and readable due to the clear structure of SwingBuilder containment structure.

To make this code runnable we need some imports first, and here they are:

import groovy.swing.SwingBuilder
import javax.swing.*
import java.awt.*

Let’s see how Scala handles this.

First we need some imports too…

import scala.swing._
import scala.swing.Swing._

… and here’s the method:

    def inputWindow() = {
       new MainFrame {
           val mailPane = new EditorPane() { maximumSize = (300, 300);
                                             minimumSize = (300, 300);
                                             preferredSize = (300,300) }

           title = "Insert mailtext"
           size  = (400,400)
           contents = new BorderPanel {
                 import BorderPanel._
                 add( new ScrollPane ( mailPane ), Position.Center )
                 add( Button("convert"){ selectWindow(mailPane.text) } ,Position.South )

Well, all in all this structure is as concise and as easily readable as the Groovy one. But there are some differences I want to mention here.

The first difference we see immediately is, that the mailPane is created first and stored in a dedicated variable. This is not only for code layout purposes, but necessary, as it has to be referrable later in the button’s action to get the pasted text.
In Groovy this is achieved by accessing the SwingBuilder instance, which also serves as a repository for the created components.

The next difference is, that in Scala we often create new instances with ‘new’, indeed creating anonymous subclasses this way, while in Groovy all is done by applying the builder syntax as a DSL and let the builder maintain the instance creation under the hood.  In the above code the Button is special. Instead of a ‘new’ call we see a shortcut. The button is created by applying the companion object of class Button and providing that with a code block to be executed on click.

And this was the first confusing thing for me: Some components provide companion objects, but not all. And which provide an apply method as shortcut is not clear.  One has to consult the scaladoc, and even that is often too rudimentary. In the end this shortcut option seems to be special for Button.

Another confusing thing is the way to add components to a container. Sometimes ‘add’ seemed the right way, sometimes ‘contents+=’ . But the latter does not work in a frame, where it is merely ‘contents=’ . The documentation is sparse. The Swing chapter in Programming in Scala did not answer all my questions and finding documentation on the web took me some time. After stumbling over possibly outdated, too short or academic stuff, I finally returned to  this link . It is not really a tutorial (and that’s why I stepped over it first), but an at least somewhat helpful introduction to the concepts,  and eventually it took me forward.

Ok so far about my docu experience. What now happens when clicking the button? Or better: what does method ‘selectWindow’ do?

Here I want to turn things and go bottom up first. At the beginning of selectWindow the text from the editorPane is converted into a collection of rows, containing the data and the checkbox widgets.

Let’s have a look at this job first:

Here’s the original Groovy version of the Row class:

class Row {
  def selectbox
  def date
  def address
  def title
  def url
  def donebox

You see, this is very concise. But Scala is close behind with its clase class construct.

    case class Row ( selectbox:CheckBox,

This one is also a bit more helpful, as it provides the types. I could have done that in Groovy too,but due to the scriptic nature of the problem it seemed natural not to bother with such trivia. This statement will give just enough potential for long debates, I think.

But now for the conversion of a ‘text’ into a bunch of such Rows.

Again first the Groovy version:

def convert(inputtext, builder) {
    result = []
    inputtext.split("\n").each{ line ->
        matcher = line.trim() =~ /(2010\S*)\s*(\S*)\s*(.*?)\b*(Anfordern|Request) \(HTTP\)\b*.*<(.*)>.*/
        if (matcher.matches())
            result << new Row(selectbox: builder.checkBox(selected:true),
                                         title:matcher[0][3], url:matcher[0][5],
                                         date:matcher[0][1], address:matcher[0][2],
                                         donebox: builder.checkBox(selected:false))
                   // matcher[0]  [1]->date [2]->address [3]->subject [4]->wordgroup [5]->URL

And immediately the Scala solution:

    def convert(inputtext:String):List[Row] = {
        val regex = """(2010\S*)\s*(\S*)\s*(.*?)\b*(Anfordern|Request) \(HTTP\)\b*.*&lt;(.*)&gt;.*""".r
        val result = for( regex(date, address, subject, label, link) &lt;- regex findAllIn inputtext )
                         yield  new Row(selectbox = new CheckBox { selected = true },
                                        title = subject, url = link,
                                        date = date, address = address,
                                        donebox =  new CheckBox())
        return result.toList

What’s notable here is that in Groovy you are in contact with such details as the matcher and its array representation, what leads to the necessity to note in a comment what index is what.
In Scala on the other hand you work on a more abstract, more declarative level, keeping such details as the match handling and the collection maintenance under the hood.

The resulting Row list of the above method is now used to construct the second frame (Groovy):

def selectWindow(inputtext) {
    job = new SwingBuilder()
    content = convert(inputtext, job)
    frame = job.frame(title:"Uncheck real spam mail", size:[800,800] ) {
         panel(layout: new BorderLayout()) {
             scrollPane(constraints:BorderLayout.CENTER) {
               panel() {
                 tableLayout {
                   content.each { row ->
                     tr {
                        td { widget(row.selectbox) }
                        td { label(text: row.title,
                                   toolTipText: "${} ${row.address} ${row.title}") }
                        td { widget(row.donebox) }

             panel(constraints:BorderLayout.SOUTH) {
                   button("action", id: "action", actionPerformed: {process(content, job)} )
                   button("close",  id: "close",  actionPerformed: {frame.dispose()}, enabled:false)
   frame.visible = true

Here we see one of Groovy’s strengths: The table layout, which lets you declare the positioning like a table in html. Very easy and handy.  Beside that, take a look at how the buttons and their actions are declared in one expression.

Now the Scala pendant:

    def selectWindow(inputtext:String) {
        val rows = convert(inputtext)
        val frame = new Frame {
           val doit = new Button("action")
           val closeB = new Button("close") { enabled = false } 

           val listPane = new BoxPanel(Orientation.Vertical) {
                              rows.foreach { row =>
                                 contents += new BoxPanel(Orientation.Horizontal) {
                                                   contents += row.selectbox
                                                   contents += new Label(row.title) {
                                                                   tooltip =" "+row.address+" "+row.title }
                                                   contents += row.donebox
           title = "Uncheck real spam mail"
           size  = (800,800)
           contents = new BorderPanel {
                 import BorderPanel._
                 add( new ScrollPane ( listPane ), Position.Center )
                 add( new FlowPanel {
                         contents += doit
                         contents += closeB
                      },Position.South )

           listenTo( doit )
           listenTo( closeB )
           reactions += {
              case ButtonClicked(`doit`)   => process(rows, doit, closeB)
              case ButtonClicked(`closeB`) => this.dispose()
       frame.visible = true

Again things are done a bit different. First, we again notice the declaration of vals for components to refer to them later (doit and closeB). Then, with listenTo(…) and reactions+= we see the reactive way of declaring actions in Scala swing.

What is important here is that Scala swing does not provide an easy to use container layout, like Groovy’s table layout. The options would have been to introduce third party things or to fiddle with a GridBag layout or such things. But to shorten the development time (which already was longer than expected due to the need to search for documentation), I decided to simply use the BoxPanel container.  The result is a bit ugly, but is usable.

We come to the “action” button now, and to method “process” which implements its action. This is now the central purpose of this whole script: For each row call the URL and check the result box.

That is how it looks in Groovy:

def process(content, builder) {
   builder.action.enabled = false
   builder.doOutside {
     content.each { row ->
       if (row.selectbox.selected) {
           def result = callURL(row.url);
           builder.doLater { row.donebox.selected = result }
     builder.doLater { builder.close.enabled = true }

We see here another feature of the Groovy Swing Builder: A simple way to let code run in another thread with doOutside, and then push things back on the EventDispatchThread with doLater. This way the GUI is visibly updated for each row as it is processed, and in the end the close button is enabled.

Scala does the same this way:

    def process(content:List[Row], action:Button, close:Button) {
        action.enabled = false
        actor {
            content.foreach { row =>
               if (row.selectbox.selected) {
                   val result = callURL(row.url);
                   Swing.onEDT { row.donebox.selected = result }
            Swing.onEDT { close.enabled = true }

It resembles exactly the same structure. Instead of doLater we call Swing.onEDT. Most notably is the way to push code onto another thread. Coming from Java Swing and looking at the Groovy way to call a builder method, I first looked for a method on Swing as opposite to onEDT. Then I looked for a SwingWorker class, which indeed exists but is not documented and seems even to have no meaningful implementation(?). In the end I slapped on my head and thought “why, it’s Scala”. And indeed the natural way to run stuff on a new thread is the “actor” method. Nothing Swing specific here.

The method “callURL” now is the next step to get things done, supported by a method named “checkResult”. In Groovy this is:

def callURL(urlstring) {
    try {  def url = new URL(urlstring)
           return checkResult(url.text)
    } catch (Exception e) {
           println "Exception when Accessing URL: "+e.message
           return false

def checkResult(content) {
    if (content =~ /Ihre Anfrage wurde verarbeitet/) {
        println "CONTENT OK"
        return true
    else {
        println content
        return false

Interesting to see that with new URL and url.text the call is done.

The Scala pendant:

    def callURL(urlstring:String):Boolean = {
        try {
           val txt:String = Source.fromURL(urlstring).getLines().mkString
           return checkResult(txt)
        } catch {
          case e:Exception =>  println ("Exception when Accessing URL: "+e.getMessage())
                                          return false

    def checkResult(content:String):Boolean = {
        val rgx = "Ihre Anfrage wurde verarbeitet".r
        rgx findFirstIn content match {
            case Some(x) => println ("CONTENT OK"); true
            case None    => println (content) ; false

Once again the structure is analogous to the Grooy one. The interesting difference here is the way to call the URL. Again it took some time to find the solution, as I first looked for what class URL might offer, but Scala simply uses the Java one. And I was led into the wrong direction by an old post which gave me the impression some time ago that object Source has to do with reading files. But after some googling I detected that I was wrong: Source is the way to go, as it is an abstraction for textual data sources, not for source files or source code.
Also the getLines() and mkString needed a bit of exploration, but in the end I got the feeling that I should have known that. I had seen this before.

Well, that was the complete program in the two languages so far. What remains is, how it is started. And here we have a big difference.

The Groovy script was … well, a script. That means, adding a line which calls the topmost method “inputWindow()” and I had a runnable script which could simply be started with e.g. “groovy releaseSpam.groovy”.

The Scala way was not as simple. Although the Scala Swing API was used to instanciate and control widgets, we miss the infrastructure so far, which we get by Groovy SwingBuilder.
To gain this, the Scala code shown so far must be wrapped inside an object which extends SimpleSwingApplication and defines a method “top” which returns the main frame.

Here is the structure:

object Main extends SimpleSwingApplication {
      // .... the code shown so far

   def top = inputWindow()

Normally we can now add a line at the end calling the main method like:
And run that as a script.

But that does not work together with Scala.swing and SimpleSwingApplication.
Trying to put the code in a file named “releaseSpam.scala” and call it with the scala command results in :

cmd.exe /c  scala releaseSpamMail-WIP.scala
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: Main$$anon$12$Main$
        at Main$$anon$12$Main$.inputWindow(releaseSpamMail-WIP.scala:125)
        at Main$$anon$12$Main$.top(releaseSpamMail-WIP.scala:139)
        at Main$$anon$12$Main$.top(releaseSpamMail-WIP.scala:13)
        at scala.swing.SimpleSwingApplication.startup(SimpleSwingApplication.scala:7)
        at scala.swing.SwingApplication$$anonfun$main$1.apply$mcV$sp(SwingApplication.scal

So the best way to run it is to compile it, jar it, and run the resulting jar with:
scala -cp .\releaseSpam.jar Main

At the of this article now let us talk about another aspect:  The way I programmed the scripts.

With Groovy it was a very fluent experience, as I used the GroovyConsole to continuously work in a edit-run loop and store the script when appropriate.

Scala has only the REPL, which is no adequate replacement.  I worked with Vim to get a comparable feeling, but after detecting that I cannot run code containing Swing as a script, it mutated to an edit-compile-run cycle. Well, this is also easily done out of Vim, so no real disadvantage.  But you need and external editor with good developer support to achieve that flow and that is a bit a pity.


So what is the result now?  Well, all in all Scala seems as well fit for scripting tasks as Groovy is. The code is concise and expressive and readable in both cases. But currently Groovy wins for this task, because of better documentation and/or more intuitive API,  because of Scala.swing  not including a simple layout for quick tasks, because of Scala.swing  not being runnable in a script, and because of the necessity to use an external development tool.

But if you are familiar with the API (which I am much more for the next task now), use a specific IDE tool anyway and don’t bother keeping the solution as a program instead of a script, Scala is indeed a good match. And improvements will come with further development efforts of the community, for that I am sure.

I hope you liked this little article.

April 26, 2010

GPDL – Gui Path Description Languange

Filed under: Tool — de.velopmind @ 4:46 am

Do you know that problems?  A colleague asks you how to set a specific option in MS windows, and now you want to send him a mail declaring how he gets to the deeply hidden checkbox to set the field.

Or: You are an enterprise developer and get a bug report in one of your forms.  But the tester has difficulties to tell you, how he got to the point where the error occurs.

Would be quite helpful if there would exist a simple but expressible Language to Describe the Path in the Gui one has to take. Or in reverse: a Gui Description Path Language.

I will present here a draft proposal for it.

The elements:

(foo)   means:  Select menu item labelled “foo”

(foo->bar->baz)   means:  Open menu labelled “foo”, select submenu “bar” and in it item “baz”

[foo]   means: Press button labelled “foo”

/foo/   means:  Select tab labelled “foo”

_foo_:bar  means: In the widget labelled “foo” enter or select “bar”

{foo}  means: On the widget labelled “foo” select the context menu

{foo:bar->baz} means: On the widget labelled “foo” open the context menu, select submenu “bar”, and in it item “baz”.

%foo% means: you will see a dialog with title “foo” now.

With this elements you can describe  typical gui steps like the following (pseudo) use case:

(Extras->Options) -> %Options% -> /Display/ -> [Advanced…] -> _resolution_:1024×600 -> [OK] ->[OK]

With this syntax, the reader does not have to think about, if “Advanced” is a menu entry, a button or a tab.  With only a short training it leads your eyes directly to the right location to search for the text.

Really simple, isn’t it?

February 16, 2010

How to setup NB for GAE with Scala – Part III

Filed under: GoogleAppEngine, Netbeans, Scala — de.velopmind @ 5:10 am

Additional Scala configuration for writing Servlets

To write Servlets in Scala, the Scala Project has to import at least the Geronimo Servlet Spec jar from the appengine directory. This one is sufficient to let your Scala class implement the Servlet interface.

Add Servlet-Spec Jar

Step 1: Select “Add Jar/Folder” in the context menu of the Libraries entry in your Scala project tree. Go to the lib/shared folder of your app-engine SDK installation.

Step 2: Select the geronimo-servlet-spec.jar

Write Test servlet in Scala

In the Scala project in our package testapp create a new Scala class named e.g. MyScalaServlet, and put in the following code example:

package testapp

import javax.servlet.http.{HttpServlet         => HServlet,
                           HttpServletRequest  => HSRequest,
                           HttpServletResponse => HSResponse}

import scala.xml.Elem

class MyScalaServlet extends HServlet {

  def processRequest(request:HSRequest, response:HSResponse) {

        val theTitle = "A first Scala Servlet"

        val content = (
                    is at: {request.getRequestURL()}

        writeContent(response, content)

  def writeContent(response:HSResponse, cont:Elem) {
        val out:PrintWriter = response.getWriter()
        try     { out.println(cont) }
        finally { out.close() }

  override def doGet(request:HSRequest, response:HSResponse) {
      processRequest(request, response);

I should mention that at the time of this writing there seems still to be a little bug in the Scala plugin which results in the first import displayed as erroneous. The message is: value servlet is not a member of package javax.

Truth is, you can simply ignore this message and build the project as usual.

Well, the source above is a little example of Scala’s features and how a servlet may look like in Scala. But this is only one way to create Scala servlets, and except for the embedded XML/HTML stuff it is very close to a Java solution. You may come up with better and more sophisticated solutions, or find some in the internet.

So far that’s fine. We now only have to configure the Servlet in the Web Application’s web.xml file

Select the web.xml file in the configuration files folder of the Web Application project and double click it to open.

Now you get a form based editor for the different parts in the configuration file. Select Servlets and click Add Servlet Element . You should see an input form, which you can fill like in the following example:

Please note that the Browse button won’t work in this scenario, as the source is not located in this same project. So the full qualified servlet class name has to be inserted manually.

After pressing OK and rebuilding/deploying the WebApp project, you can see the result by calling the following URL in your browser: http://locahost:8080/test/scalaservlet

The End

I hope you enjoyed this little tutorial about Scala in Netbeans for the Google App Engine.

If you want to go further into using the app engine services –for example the persistence–, you will need further libraries which are configured in the same way like described above for the geronimo jar.

For tutorials about using e.g. JDO or JPA with Scala look for other sources in the internet, as this exceeds the topic for this little howto.

The basics are laid out, now it’s your turn!

February 10, 2010

How to setup NB for GAE with Scala – Part II

Filed under: GoogleAppEngine, Netbeans, Scala — de.velopmind @ 12:55 am

Create Projects

After we set up Netbeans with the necessary plugins and user defined libraries, we will now create our first Google App Engine  web project and corresponding Scala project.

Create a Web Application Project for Google App Engine

First we create a typical Web Application project with Google App Engine (GAE) as the server. You should have already read how this works in the plugin’s starter tutorial linked above.

This project will be our main project for packaging and deployment, and will contain all the web specific stuff like JSPs or GWT code and so on.

Step 1: Select New Project in the project view’s context menu or the file menu and choose type “Web Application”

Step 2: Set Name and Location

Step 3: Select Google App Engine as Server

After pressing Finish you see the project in the project view. If you do this the first time, you perhaps want to follow the guideline of the linked starter tutorial to do a first local and possibly remote deployment and enjoy the Hello World jsp example. For the next steps I assume that you have already done such playing with GAE and now are interested in the Scala steps.

Create a new Scala Library project

So let’s now create a new Scala project by applying almost the same steps like before.

Step 4: Create a new Scala project of type Scala Class Library

Step 5: Set again theName and Location

Now your Project View should look like this

At this point we merely have two separate projects which know nothing about each other. The next part will be to construct a connection between them.

Configure the Web App project

To prepare the web project for the Scala part, we have to do two things.

First the Scala runtime library must be part of the project so that it is deployed together with the rest. Otherwise the compiled Scala will not find its dependencies.

Add Scala library

Step 5: Open library configuration dialog for your Web project

Step 6: Add Scala library

Connect Scala Project

Second, the Scala project is connected so that its eventually built jar file will also be referenced and deployed together with the other configured libraries.

Step 7 Now add the Scala Project to the Web Project

Step 8

Configure the Scala project

Step 9: Add App Engine Libraries to Scala Project

Ready for first test

Your project should now look like this

At this point you can write Scala code which is called for example in JSPs located in the Web project.

As an example create in your Scala project a package named “testapp” and in that create a Scala class with the following source:

package testapp
class FirstScala {
  def someMethod() = {
    "This comes from Scala!!"

Then in your web project change the autmatically created index.jsp like this:

    Document   : index
    Created on : 23.01.2010, 12:05:46
    Author     : Det

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@page import="testapp.FirstScala"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>JSP Page</title>
        <h1>Hello World!</h1>
        <p>Test: <%= new FirstScala().someMethod() %></p>

After deploying this app to your local GAE server or to your App Engine space on the google site, you should see a web page containing:

Please note that for local test deployment you only need to call “deploy” in the context menu of your Web project. The compilation of the connected Scala project and the packaging of all dependent libraries into the application’s war will work automatically without any further build file manipulation.

This example would not need the app-engine libraries we configured above. We did it to prepare access to all the GAE services from within Scala code without getting compile time errors. These two libraries are deployed with your app, but it is the Web project’s build process that automatically takes care about that.

In this state it is NOT possible so far to write Servlets in Scala.

So in the upcoming installment we will further setup our Scala project for Servlet development:  Follow me …

February 5, 2010

How to setup Netbeans for Google App Engine with Scala

Filed under: GoogleAppEngine, Netbeans, Scala — de.velopmind @ 10:29 pm

This little tutorial describes an easy way to combine in Netbeans 6.8 Google App Engine development with the Scala programming language.

When I started trying to write a first App Engine application with Netbeans and with Scala, I detected that in Netbeans you can’t simply “Add Scala Nature” and have a project that is able to compile Scala sources. So I was under the impression that I had to figure out what the special configurations in the Scala project’s build files are and to mingle them by hand into Web Application build files to get a combined project in the end.

But, as I found out, it is much easier to think of the “application” as a project group and to keep the Web Application project separate from the Scala project and let Netbeans pull everything together.

So in the next steps you will see what I eventually did to set up a Google App Engine application with Scala in Netbeans.


So, well, what you need to write Scala code in Netbeans for Google App Engine is:

Install the plugins

I do not want to repeat here the work which others have done already fairly well. So for installation and setup of the Google App Engine Plugin and the Scala plugin simply follow the instructions to be found under the following links:

Google App Engine:


Be aware that the Scala plugin is based on the Scala version 2.8 which is still under development, as well as the plugin itsself is. Scala has to be installed separately.

On my computer (and therefore in this example) it is installed in

C:\Programme\Scala\scala-2.8 .

For the Google App Engine Plugin you must install the App Engine SDK separately. I did that in C:\appengine-java-sdk-1.3.0 .

So after following these instructions you should see something like the following two pictures in your Installed Plugins View

Installed Google App Engine Plugin

Installed Scala Plugin

Configure the libraries

In this step we will configure some library entries which will later be used to setup the projects’ compile time and runtime dependencies. We start with an entry for the Scala runtime library.

In menu Tools select the item Libraries to open the configuration dialog.

Now press New Library and create a new entry named “Scala28” of type “Class Libraries”.

Then select the jar file scala-library.jar in the /lib folder of your Scala installation directory.

You have a new entry for Scala now. This can later be used to define runtime dependencies in non-Scala projects.

Do the same for the Google App Engine jars. I named the entry “AppEngineLibs” here. You have to add the two appengine-api-*.jar files which you find under the /lib/user path in your App Engine SDK installation directory. This entry will later be used to define compile time dependencies in a non-GAE project, for example our Scala project.

So far it was merely a basic netbeans setup procedure which has to be done once.

In the next installment I will show how to setup the combination of projects for each application:   Follow me …

January 14, 2010

My current playground (NB, GAE, Groovy, Scala, Wave)

Filed under: Experiences, Groovy, Scala, Tool — de.velopmind @ 8:24 pm

As a developer the greatest joy for me is to experiment with new tools, right at the bleeding edge.  So what are the toys of today?

While I am obliged to use Eclipse in office, I use Netbeans for my private play projects since a while, and more and more I like this tool.  Now the current version NB 6.8 seems to be really mature and stable, and it is a joy to work with it. As I often want to test this and that at very different locations, I appreciate that I can even work with NB on my Netbook on a 1024×600 resolution display.

Another hype I am eagerly following is Scala, and at least until now the NB Scala plugin by Caoyuan Deng was always a much better experience than the Eclipse plugin.  NB always seemed more smart and simple than the complex doing-it-my-own-way IDE with the hidden sun.

Well, mentioning Scala, this is really a language which captivated me.  Groovy was a great experience, and in some areas still is:  Especially for scripting and embedding and where dynamic is the most effective way to do things. But from a Java perspective I never learned so much about programming since when I started to learn Scala.  I would really like to see it become main stream in enterprise development.

The most recent hype that caught my attention is Google Wave. A really interesting new approach to communication and collaboration, even if in its very early stages yet.  It fuels the phantasy very much, although I often see that my very interesting new ideas are already thought and even implemented by some smarter guys 😉 .

Well, when you start learning more about Wave from a developer’s perspective, you will come to Google App Engine very fast, as the robot extensions currently are only supported on that platform.

Nice to see that a Netbeans plugin already supports development of Google Apps, although it is not promoted on the famous pages. And hey, Guillaume Laforge’s  Gaelyk library seems a really nice thing to work with Groovlets on the GAE.  Unfortunately it is in Netbeans not easy to create a mixed project, being of GAE and of Groovy nature…

So I had to put hands-on now and start a template project for Gaelyk development in Netbeans. You find it now on Github.

Yeah, Git and Github, the next big thing in my toolkit. I started to explore git some weeks ago, and I really like the decentralised approach of it. I had experienced sccs and cvs, and in my company we are now working with subversion (and tortoise), which substituted PVCS and was a really big step forward.  But yes, with the central repository, commiting code or creating a branch was always “a big thing”.  The rule was:  Never check in uncompilable or vulnerable code.  So often large parts of develepment are kept on the local hard drive of developers. Well, you even don’t want to pollute the already complex repository with even more branches, do you?  It is enough to find the branches of the different supported versions and of larger projects in it.

But beware, if you have to stop working on a complex development to fix this bug or prototype that feature in the same version of your software.  With subversion this means:  setting up a whole new workarea for each task.

How other is the development with git, where you keep all data locally in one workarea, and you commit and branch as often as you like.   Switching from one task to another means simply switching the branch.  And if your code is mature enough, you push into the central repo. A real joy to work with.

BTW: I stumbled over git because many people in the Scala user list seem to use it and I was curious.  And there is also a Netbeans Git Plugin which is in early stages and has a somewhat moderate progress pace, but the most common tasks you can do directly in Netbeans.

The only thing that is a bit sad is, that it is not easy to combine all this nice things easily in one Netbeans project.  You often have to create separate projects to explore the build.xml and properties, and than merge the different things together in one project, just as I startet with Gaelyk-NB-template.

So what do you think, if you read that all?  I changed my tool box in the last two years heavily, but I feel really good with it. The time has come to look forward to program the first Wave robot with Gaelyk and with Scala/GAE, and make that experience even more convenient.

Well, another sad thing is that this is miles away from my company, where Java, Eclipse and Subversion is set …

September 10, 2008

JVM – languages … what a hype!

Filed under: Language, Other-lang — de.velopmind @ 2:12 pm

After Groovy and later Scala tried to get the attention of the ordinary Java developer by arguing that they are not too different to what he is already used to, this argument now has become the must-have of new JVM languages, what results in some really weird statements.

Some minutes ago I got notice of the new programming language Fan, which web site has a funny start page:

It shows first the code example:

// find files less than one day old
files := dir.list.findAll |File f->Bool|
  return - f.modified < 1day

// print the filenames to stdout
files.each |File f|
  echo("$f.modified.toLocale:  $")

and then states:

Familiar Syntax
Java and C# programmers will feel at home with Fan’s curly brace syntax.

Yep! Indeed!

It has curly braces, so it feels SOOOO familiar!!  I would really feel desoriented if it would use do…end instead. But with this {…}  it will be very easily adoptable by all my Java colleagues.

ARGH. Does anyone beside me feel that assignment with := , lack of semicolons, use of code blocks, pipes as parameter list separators, String templates and ‘echo’ for printing on screen is IN NO WAY FAMILIAR for Java programmers ???

It does indeed feel very familiar to me, but not due to the curly braces, but because of my knowledge of Ruby, Pascal and Unix Shell.  Taken that languages, every mentioned aspect seems covered. So what stays as being typical Java?  Nothing!

Fine introduction, Fans.

« Newer PostsOlder Posts »

Blog at