2010-03-25

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.

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!

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:

2010-03-03

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:

2010-03-01

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

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

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.