Oct 18

Although Scala is tool-agnostic, the Scala community seems to have a preference for the Apache Maven build tool. I am not quite sure why. Given that most people who learn Scala come from a Java background, what could be more natural than using Ant for Scala development? As a tried-and-true build solution, Ant avoids the headaches and additional learning curve that comes with an unfamiliar build tool. Although I have spent considerable time with Maven as part of my job, Maven and I haven’t become friends, and we probably never will. I won’t go into the details of the how and why. Instead I’m going to present and explain a few Ant scripts for Scala development. If you are new to Scala, I hope that this will give you a headstart with your new Scala projects. After all, you have a new language to learn and little time to bother with tools.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
<?xml version="1.0"?>
<project name="helloworld" default="run">
 
  <!-- root directory of this project -->
  <property name="project.dir" value="."/>
 
  <!-- main class to run -->
  <property name="main.class" value="app.HelloWorld"/>
 
  <!-- root directory of Scala installation -->
  <property name="scala.home" 
    value="C:\\Program Files\\Scala"/>
 
  <!-- location of scalatest.jar for unit testing -->
  <property name="scalatest.jar" 
    value="C:\\Program Files\\...\\scalatest-1.0.jar"/>
 
  <target name="init">
 
    <!-- derived path names -->
    <property name="build.dir" value="${project.dir}/build"/>
    <property name="source.dir" value="${project.dir}/src"/>
    <property name="test.dir" value="${project.dir}/test"/>
 
    <!-- scala libraries for classpath definitions -->
    <property name="scala-library.jar" 
      value="${scala.home}/lib/scala-library.jar"/>
    <property name="scala-compiler.jar" 
      value="${scala.home}/lib/scala-compiler.jar"/>
 
    <!-- classpath for the compiler task definition -->   
    <path id="scala.classpath">
      <pathelement location="${scala-compiler.jar}"/>
      <pathelement location="${scala-library.jar}"/>
    </path>
 
    <!-- classpath for project build -->   
    <path id="build.classpath">
      <pathelement location="${scala-library.jar}"/>
      <fileset dir="${project.dir}/lib">
        <include name="*.jar"/>
      </fileset>
      <pathelement location="${build.dir}/classes"/>
    </path>
 
    <!-- classpath for unit test build  -->
    <path id="test.classpath">
      <pathelement location="${scala-library.jar}"/>
      <pathelement location="${scalatest.jar}"/>
      <pathelement location="${build.dir}/classes"/>
    </path>
 
    <!-- definition for the "scalac" and 
      "scaladoc" ant tasks -->
    <taskdef resource="scala/tools/ant/antlib.xml">
      <classpath refid="scala.classpath"/>
    </taskdef>
 
    <!-- definition for the "scalatest" ant task -->
    <taskdef name="scalatest" 
      classname="org.scalatest.tools.ScalaTestTask">
      <classpath refid="test.classpath"/>
    </taskdef>
 
  </target>
 
  <!-- delete compiled files -->
  <target name="clean" depends="init" description="clean">
    <delete dir="${build.dir}"/>
    <delete dir="${project.dir}/doc"/>
    <delete file="${project.dir}/lib/scala-library.jar"/>
  </target>
 
  <!-- compile project -->
  <target name="build" depends="init" description="build">
    <buildnumber/>
    <tstamp/>
    <mkdir dir="${build.dir}/classes"/>
    <scalac 
      srcdir="${source.dir}" 
      destdir="${build.dir}/classes" 
      classpathref="build.classpath"
      force="never"
      deprecation="on"
    >
      <include name="**/*.scala"/>
    </scalac>
  </target>
 
  <!-- run program -->
  <target name="run" depends="build" description="run">
    <java classname="${main.class}" 
      classpathref="build.classpath"/>
  </target>
 
  <!-- build unit tests -->
  <target name="buildtest" depends="build">
    <mkdir dir="${build.dir}/test"/>
    <scalac 
      srcdir="${test.dir}" 
      destdir="${build.dir}/test" 
      classpathref="test.classpath"
      force="never"
      deprecation="on"
    >
      <include name="**/*.scala"/>
    </scalac>
  </target>
 
  <!-- run unit tests -->
  <target name="test" depends="buildtest" description="test">
    <scalatest runpath="${build.dir}/test">
      <reporter type="stdout" config="YFABRT"/>
      <membersonly package="suite"/>
      <!-- <reporter type="graphic" config="YFABRT"/> -->
      <!-- <suite classname="suite.TestSuite"/> --> 
    </scalatest> 
  </target>
 
  <!-- create a startable *.jar with proper 
    classpath dependency definition -->
  <target name="jar" depends="build" description="jar">
    <mkdir dir="${build.dir}/jar"/>
    <copy file="${scala-library.jar}" todir="${project.dir}/lib"/>
    <path id="jar.class.path">		
       <fileset dir="${project.dir}" >
         <include name="lib/**/*.jar"/>
       </fileset>
    </path>
    <pathconvert property="jar.classpath" pathsep=" " dirsep="/">
      <path refid="jar.class.path"></path>
      <map from="${basedir}${file.separator}lib" to="lib"/>		
    </pathconvert>
    <jar destfile="${build.dir}/jar/${ant.project.name}.jar" 
         basedir="${build.dir}/classes"
         duplicate="preserve">
      <manifest>
        <attribute name="Main-Class" value="${main.class}"/>
        <attribute name="Class-Path" value="${jar.classpath}"/>
        <section name="Program">
          <attribute name="Title" value="${ant.project.name}"/>
          <attribute name="Build" value="${build.number}"/>
          <attribute name="Date" value="${TODAY}"/>
        </section>
      </manifest>
    </jar>
  </target>
 
  <!-- create API documentation in doc folder -->
  <target name="scaladoc" depends="build" description="scaladoc">
    <mkdir dir="${project.dir}/doc"/>
    <scaladoc 
      srcdir="${source.dir}" 
      destdir="${project.dir}/doc" 
      classpathref="build.classpath"
      doctitle="${ant.project.name}"
      windowtitle="${ant.project.name}"/>
  </target>
 
  <!-- create a zip file with binaries for distribution -->
  <target name="package" 
    depends="jar, scaladoc" description="package">
    <zip destfile="${build.dir}/${ant.project.name}.zip">
      <zipfileset dir="${build.dir}/jar" 
        includes="${ant.project.name}.jar"/>
      <zipfileset dir="${project.dir}" includes="lib/*"/>
      <zipfileset dir="${project.dir}" includes="doc/*"/>
      <zipfileset dir="${project.dir}/txt" includes="*"/>
    </zip>
  </target>
 
</project>

Download “helloworld.scala” with Ant build file.

Fortunately, the designers of Scala provided built-in Ant tasks in the compiler library, which makes the integration of Ant straightforward. The XML code above shows the build.xml for a typical Scala standalone application, such as a GUI program or a console application. It is reasonably complete and it provides Ant targets for all common tasks:

  • build = compile your project and put class files into the ./build directory.
  • run = run program.
  • jar = create a startable jar archive from class files.
  • test = build and run unit tests (using Scalatest).
  • scaladoc = create API documentation from sources and put it into the in ./doc directory.
  • package = create a distributable zip archive that contains all dependencies plus Scaladocs.

The directory tree is kept as simple as possible:

Scala Project Skeleton
  • build - temporary directory for class files and other binaries
  • lib - contains external dependencies (*.jar files)
  • src - contains Scala source code tree
  • test - contains Scala unit tests
  • txt - contains files (such as license text) that are packaged with the distributable zip archive

If your project depends on external jars, all you have to do is to drop these into the ./lib folder. Ant will take care of creating appropriate class paths, entering them into the manifest of the startable jar file, and including them in the distribution package. The Scala library is packed automatically so that the resulting package can be deployed on computers that don’t have Scala installed (only a standard JRE is required). To use this Ant script on your computer, you need to change the values of the scala.home and scalatest.jar properties to match the location of your Scala and Scalatest installations (never mind the latter if you use another unit testing framework). If you are working in a team, it is good practice to put Ant properties into a separate properties file, so that the build file can be checked into a source code management tool. I have included them here for simplicity.

One of the advantages of using Ant is that it has very good integration with IDEs, such as Eclipse. The only twist is that Eclipse does not honour the classpaths defined in build.xml for its own incremental compilation process used to mark syntactical errors. Thus if you import the Ant project into Eclipse, you have to tell Eclipse about the dependencies using the Project/Properties/Java Build Path option.

Ant in Eclipse

Share and Enjoy:
  • Digg
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • YahooMyWeb
  • Slashdot
  • LinkedIn
  • blogmarks
  • Live
  • description
  • StumbleUpon
  • Ma.gnolia
  • MisterWong
  • NewsVine
  • Reddit
  • Spurl
  • Yigg
  • E-mail this story to a friend!
Sep 18

Is there such a thing as a Scala job market? According to my sporadic research during this month, not really. A quick keyword search for “Scala” on monster.com came up with 14 listings in the US, 1 listing in the UK, 4 in Germany and 1 in India. In addition, I found 2 listings on javajobs.net and 2 on technojobs.co.uk. Most employers in these listings don’t hire people for Scala development, but the job ad says something like “…knowledge of a second JVM language, such as Scala, etc. is advantageous…” Freelancer markets like elancer.com, rentacoder.com, etc. show a similar picture. There are virtually no bids for Scala programmers at this time. On elance.com you can find 19 people who offer Scala development services (compared to roughly 11,000 Java programmers); on the German gulp.de site there are 30 Scala programmers (compared to roughly 12,000 Java programmers).

The Scala job statistics published today at www.itjobswatch.co.uk does not look all that promising either. Scala skills are requested only in 0.025 % of all IT Jobs, however, this number has grown tenfold since last year.

Scala Job Market (UK)

Source: http://www.itjobswatch.co.uk/jobs/uk/scala.do

So what does this tell us?

If you program in Scala, you must be either an academic, a hobbyist, or a programmer with too much leisure time. Currently, there is no significant demand for Scala professionals. But this might change. The Java community has received Scala quite positively so far and the language has a rapidly growing fan base. There are several high-profile websites that have recently begun development efforts in Scala, notably Twitter and LinkedIn. There are also a number of large-scale commercial projects in Scala being started recently. Martin Odersky, the creator of Scala, is quite upbeat about the commercial future of Scala. In this talk, given at LinkedIn earlier this summer, he outlines his vision for the near future of Scala. He also mentions a number of companies that have taken up projects in Scala, among them Ebay, LinkedIn, NatureNews, OfficeDepot, SAIC, Siemens, Sony, Twitter and Xerox.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • YahooMyWeb
  • Slashdot
  • LinkedIn
  • blogmarks
  • Live
  • description
  • StumbleUpon
  • Ma.gnolia
  • MisterWong
  • NewsVine
  • Reddit
  • Spurl
  • Yigg
  • E-mail this story to a friend!
Aug 10

The topic of performance of specific programming languages has provided material for endless debates among developers. Proponents of a certain language often cite examples that show their chosen language in a particularly good light. For example, I have come across the claim that PHP and Ruby are performing just as well as Java. Often these claims are supported by nothing but a firm tone of voice and a stern mien. Thankfully, we have benchmarks. A playful yet credible approach to performance measurement was taken by this website.

It contains an array of typical benchmark algorithms implemented in 35 popular (and not so popular) programming languages all running on various Linux servers. There are many complexities involved in measuring programming languages execution speed. The web development arena adds even more complexities. Much depends not only on how the algorithms are implemented, but also on how the compiler and the server are configured. For example, there are different JVMs, there are script caches, accelerators, server tunings, and what not. The languages I’d like to compare here are Java, Scala, and PHP. You will find comparison graphs for each of these below.

Three charts:

1. Java vs. PHP
2. Scala vs. PHP
3. Scala vs. Java

Java, Scala, PHP Benchmarks
Three bar groups:

1. Execution time
2. Memory use
3. Size of source code

Bar pointing down means: faster performance, lower memory usage, and reduced source size.

Basically, these charts confirm what experienced programmers already know. Both, Java and Scala outperform PHP by several magnitudes. To be precise, Java and Scala execute 28 times faster on average. The performance of Java and Scala is similar, which has to be expected since both languages run on the Java virtual machine. Java gives slightly better performance in some algorithms while its memory requirements are lower. For PHP fans who find these benchmarks disappointing, there is some consolation. PHP appears to be less of a memory hogger, and perhaps more importantly, it performs quite favorably when compared to other dynamic interpreted languages, such as Perl, and Ruby.

You can compare more language benchmarks yourself at the following URL: http://shootout.alioth.debian.org/u64q/benchmark.php.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • YahooMyWeb
  • Slashdot
  • LinkedIn
  • blogmarks
  • Live
  • description
  • StumbleUpon
  • Ma.gnolia
  • MisterWong
  • NewsVine
  • Reddit
  • Spurl
  • Yigg
  • E-mail this story to a friend!

« Previous Entries Next Entries »