Dutch Province 2010

I uploaded a bunch of pictures I took last weekend, North of Amsterdam, in the Beemster area.

Please take a look.

Scala 2.8 Showcase - Type Specialization

Scala 2.8 introduces type specialization. Because Scala is based on JVM, type erasure occurs. Type erasure is a bummer, but it has to be there for backwards compatibility with older Java versions.

Backwards compatibility is an important asset (for Java), but the downside of type erasure is (among others) that in case of primitive types autoboxing is used extensively which causes developers to favor non-generic classes over generic ones (for performance reasons; autoboxing is quite slow).

Now, Scala 2.8 has a solution for this, and that's a new annotation called @specialized.

class MyCollection [@specialized A]{
    def simplyReturn(x: A): A = {
        x
    }
}

What it does is it causes the compiler to generate specialized versions for primitives, so that autoboxing does not have to occur, which is faster. I should investigate the performance difference in future and share the results!

You can also specify which primitive classes should be specialized.

class MyCollection [@specialized("Int") A]{
    def simplyReturn(x: A): A = {
        x
    }
}

Read more about it in the official Scala document (PDF).

Scala 2.8 Showcase

1. Scala 2.8 Showcase - Collections
2. Scala 2.8 Showcase - Arrays
3. Scala 2.8 Showcase - Type Specialization

Maven archetype lexical error

I got this nasty little error today. I thought I would share it, in case someone has the same problem and finds this page.

[ERROR] ResourceManager.getResource()
parse exception:
org.apache.velocity.exception.ParseErrorException:
Lexical error:
org.apache.velocity.runtime.parser.TokenMgrError:
Lexical error at line 3570, column 172.  Encountered:
<eof> after : ""

(Line breaks added for readability)

Now, what that means is that while reading your archetype files, Maven encountered a (likely binary) file that it could not parse. Arguably, this error message could be more clear, in particular it could provide the file name itself.

The solution is simple.

For archetype.xml:

<resource filtered="false">x.gif</resource>

That is, you simple add filtered="false" to your binary resource reference in the archetype.xml file.

For archetype-catalog.xml it is similar; however, there filtering is disabled by default. So, you can either have a declaration similar to the following:

<fileSet encoding="UTF-8">
            <directory>src/main/webapp</directory>
            <includes>
                <include>**/*.gif</include>
            </includes>
        </fileSet>

... or, more explicitly, set the filtered attribute.

<fileSet filtered="false" encoding="UTF-8">
           ...
        </fileSet>

Scala 2.8 Showcase - Arrays

In Scala 2.8, arrays have undergone a major redesign for many reasons - the necessity for compatibility with a bit cumbersome JVM array implementation, as well as other reasons, which are described in the official Scala 2.8 arrays document (PDF).

You should study this document if you seek implementation details; as I understand, Scala developers will not feel a change in array handling other than seeing better performance.

Repeated parameters

To conclude this short article with a bit of code, I will present this interesting example I found in the Programming in Scala book by Martin Odersky and others.

You probably know repeated parameters (they also exist in Java as of version 5 and are known as varargs).

def blah(args: String*) {
        args foreach println
    }

This function prints every string it gets - you can pass it 0 or more String arguments.

blah()
        blah("One", "Two")
        blah("Zero")

This all works. However, here's the surprise:

val array = Array("Three", "Four")
        blah(array) // mismatch!!!

This does not compile!

type mismatch;  found   : Array[java.lang.String]  required: String

Nasty; and I do not understand why this shouldn't work. Nevertheless, here is the solution:

blah(array: _*)

Strange, but works. Thank you for your attention.

Scala 2.8 Showcase

1. Scala 2.8 Showcase - Collections
2. Scala 2.8 Showcase - Arrays
3. Scala 2.8 Showcase - Specialized Types

Maven Intimidation-Over-Convention

The beginning

Some time ago I looked at my Ant files, maybe a 1000 lines each, and I thought: this needs to change!

With Ant, everything is possible, but at the end of the day you just copy your Ant stuff from your previous projects to your new ones because things like compiling or running tests require a lot of boring and mindless XML coding, so you want to save yourself from it and do a bit of copy-paste instead. That's a little sin everyone commits. No need to mention that it quickly becomes hard to modify and maintain.

The long awaited solution?

So I decided to try Maven. Everyone has probably seen the Maven adoption curve by now, I'm sure. Nevertheless, I called Maven to the rescue and... now I'm looking at 1000 lines long Maven files. Great.

The complaining

Wait a second! What about those promises that Maven is so concise compared to Ant? What happened to convention-over-configuration?

Okay, so a large number of those 1000 lines is dependencies. But then - have you ever tried integration tests with Maven? Not supported by default. Copying a file after the build is done? Hmm... problem. What's more, I've seen people posting questions about Maven and getting an arrogant response similar to "If Maven can't do it then you're doing it wrong; you don't need it, you just don't realize it yet". Quite buggy support for Maven in Eclipse (and IDEA, I heard. Update 2010-03-02: However, Lieven suggested that IDEA support has been greatly improved, thanks Lieven. I tried it myself and found it a bit rough (how do I even add repositories? I can't modify the list), but at least it works.) is another thing... Eventually, I even mastered writing Maven plugins.

This stuff makes your pom.xml file damn long! That's not what we wanted!

The consolation for Maven

Anyway, the list of problems with Maven is quite long and it is not my intention to write another one. Don't get me wrong, Maven is a fair tool, it does bring some conventions after all (at least the projects look similar which makes them easier to pick up) and at least it solves the compilation, unit tests, and dependency management for you (but then, some say it is too much for one tool and against the Unix philosophy - do one thing well).

The expectations

Now, what would I like to see in a project management tool like Maven?

• Relieve me from tons of XML
• Provide application-type-specific solutions (something like JEE Profiles?), more sophisticated than just selecting the output file extension
• Provide support for more than one kind of testing
• Allow for scripting flexibility (like Groovy or Scala; this is happening)
• Support all JVM languages seamlessly
• Nice documentation

And if only it had strong IDE support...

The conclusion

I don't regret trying Maven and if you haven't done it yet yourself, it's time to get your feet wet! But before you decide to migrate to Maven, perhaps you should:

• Wait for Maven 3 - with Groovy instead of ugly XML
• Try Gradle instead; you may also want to read this nice article by Aaron Freeman
• See other Maven alternatives

To conclude, I think that Maven is a righteous step on our difficult and perplexing road leading to a mature and flexible project management tool so that .NET can copy it and rename it by adding an N in front of its name everyone is happy. A righteous step. And it's time to make a new one.

Please feel free and encouraged to leave your thoughts below the article.