Real world feedback from a Java dev using Scala

It’s no secret that a large proportion of Scala programmers originate from the Java developer community. I’ve been writing Java code since the late 90’s and have recently starting doing some dev work in Scala. Since I fall squarely within the target audience for Scala I’ve decided to share my experiences and impressions using Scala from a Java programmer’s perspective. Overall I’m very impressed by Scala and plan to use it more, but do have plenty of constructive criticism which I provide at the end of this blog post.

The first thing that struck me when reading up on Scala was just how many times I thought “that’s a really good way of doing things, it’s much cleaner than the way Java does it”. I’d been reading up on the language for a few months and experimenting with code, but I’ve now used Scala for actual dev work and I’ve learned a lot. The standard approach for learning to code in Scala is to start using it as “java without semicolons“. This was how I started a few months ago and I’ve gradually learned more and written more idiomatic Scala. The result of writing code the Scala way is code which is much cleaner (and more compact). At first it seems like you’re simply saving yourself a bit of typing over Java and not asking the IDE to generate code all the time. That doesn’t seem like much, but as I learned and coded more Scala I began to realise just how much easier it was to express ideas. Everything in Scala just seems to fit together better. Strings, Arrays, Lists, StringBuilders etc. all “feel” the same with common syntax and methods for common tasks such as accessing values, and adding items. Methods like groupBy, filter and map make common tasks such as processing a list of items surprisingly simple.

Overall I was very happy my decision to use Scala. The code was clear, it ran as fast as Java code and simply put the best word to describe Scala is elegant. For the first time in about many years I find myself wanting to switch my primary dev language. In terms of tooling and documentation I strongly recommend the IntelliJ Scala plugin (intelliJ has an open source community edition of their IDE these days and the plugin is free $0). In terms of books to learn Scala I found Scala for the Impatient (published a month or two ago) to be by far the best introduction to the language.

I was working on a Java codebase after the Scala work, and it struck me how dissatisfied working with Scala had made me with Java the language. It was like taking a giant leap backwards after being spoiled by the elegance of Scala.

As stated in the introduction I’m very pleased with Scala, but do have some constructive criticism to provide. It’s quite a long list, so before anyone tries to twist this as a “anti-Scala” post let me make it clear that if I were to come up with a similar list of issues for the other languages I use that list would be significantly longer. Here goes:

[Update: check Simon’s response in the comments. Very informative!]

  1. The syntax for providing package level access to a method (a very common need when writing unit tests) is rather nasty: private[mypackagename] def doStuff = {…} Even the Java equivalent of void doStuff() looks better.
  2. Some Scala standard library classes are slower than their Java counterparts e.g. HashMap and StringBuilder. Scala’s mutable Map doesn’t seem to provide a constructor that lets me specify initial capacity (so I’m forced to pay the cost of rehashing). This is easily worked around by using Java collections together with the implicit conversion classes provided by Scala (which work transparently and fantastically well)
  3. Scala API documentation seems very terse and unfriendly. It’s not uncommon for a method to come with virtually no understandable information on what it actually does or a nice example. I very frequently found myself on StackOverflow to figure out how to use classes. [update: to fast-track better API docs perhaps providing a wiki-fied version would enable more community contributions]. Due to alphabetical sorting of method names overloaded operators are always at the top of the method listings. This makes the docs for a class very intimidating for beginners. Just move the operator docs to the end of the listing so that we’re not faced with the same storm of punctuation at the top the table each time.
  4. Compiling takes a lot longer than Java. For a small project I would estimate (roughly) around a 5x difference. I’m willing to put up with a slower compiler for a better language, but would appreciate it if it were much faster.
  5. There are some inconsistencies regarding which collections support the readOnly method to provide the Scala equivalent of java.util.Collections.unmodifiableList(). Do I really need to call toMap to make my mutable.Map an immutable one? I should probably check the source to see if the toMap call is expensive or not.
  6. The various collections interfaces were a source of confusion. In Java the common class to use is Collection. In Scala I’m not so sure there’s Iterable, Traversable, GenTraversable, TraversableLike, GenTraversableLike, TraversableOnce, GenTraversableOnce, Iterator etc. There seems to be an endless list of options. If I invested a day reading up on the differences I could probably figure it out. For now Traversable or Iterable seem to be reasonable choices for a java.util.Collection equivalent. [update: it seems the non-intuitively named GenTraversable is the preferred choice]
  7. Looking at my profiling data implicit conversions do appear to generate a small amount of overhead (apparently this is to be fixed in 2.10)
  8. for loops seem to introduce more overhead when iterating compared to while loops or Java for loops. There was some talk of optimizing this in 2.10

16 thoughts on “Real world feedback from a Java dev using Scala

  1. I agree that the API docs often aren’t enough, but another good resource for learning is Programming in Scala. The first edition is available freely online ( It’s the best resource I’ve found for learning idiomatic Scala (along with the reasoning behind many of the language design decisions), and it of course helps that it’s co-authored by Martin Odersky.

    • I’ve bought various Scala books including Programming in Scala. I’d recommend Programming in Scala 2nd Ed. as a good second book on the topic. My first choice is still Scala for the Impatient though. The first 9 chapters of the book are available for free as a pdf.

      • Scala for the impatient is half the size and has fewer long winded examples. The Odersky book is brilliant, but gets side-tracked a lot and is too long for all but the most patient readers.

  2. “and it struck me how dissatisfied working with Scala had made me with Java the language. It was like taking a giant leap backwards after being spoiled by the elegance of Scala.”

    My feeling exactly if you replace Scala with C#.

  3. Thanks for your constructive thoughts, here is my take of it, hopefully it helps you a bit:

    1. I stopped adapting visibility for testing purposes a long time ago and use ScalaTest’s PrivateMethodTester for private/not accesssible methods instead. Maybe this works for you, too.

    2. A lot of work has happened in Scala 2.10 to optimize and tune collection algorithms, would be interested if it improves things for you.

    3. Yes, documentation needs improvements, absolutely. is a step into the right direction (and the new web site will hopefully launch soon, too). but a lot of work needs to be done. I can recommend using the nightly documentation instead of the “stable” documentation, because it has more documentation:
    Moving the symbolic methods to the bottom is an interesting idea!

    4. Yes, compilation speed is still an issue. Make sure to use SBT, which removes most of the pain already and stay tuned for 2.10, which ships with considerable performance improvements.

    5. Agree. Better documentation is needed here. Afaik it just returns the same map, but with a super-type which doesn’t provide any means for mutation.

    6. I totally agree, this should be better documented. I wonder if it is mentioned in the collections guide.

    7. and 8. should both be non-issues in 2.10.

    If you are interested in more information about the improvements shiping in Scala 2.10, there is an overview here and notes from Odersky’s ScalaDays keynote here

    Thanks for sharing your experience!

    • Thanks Simon! A very informative response. I’m definitely looking forward to 2.10. In terms of compilation I’m currently using whichever build tool the IntelliJ Scala plugin uses. I’m guessing it’s not SBT.

      In terms of the docs it seems that the focus on the docs site is to have user-submitted tutorials rather than giving users the ability to command on API docs. An option for users to add comments to the official docs would go a long way towards alleviating the pain of the current docs.

  4. I have to say after trying Scala for a while, I don’t see the big deal with it. It’s a little more concise but not really all that much more elegant than C# and the perf issues alone make me want to avoid it. Just wish C# was viable in non-win environments. As a language, it’s hands down the best overall.

  5. After 4 months of deep Scala diving, I must say that when I come back to Java (like this morning, I almost forgot how to write a class in Java 🙂 ), I feel really frustrated because everything seems really tedious in Java when you have tasted the power of functional programming. It’s as if I re-found an old deprecated toy, I feel nostalgy for it but I don’t want to go back…
    Anyway, I think Scala requires some efforts at the beginning for the reasons you evoke and because the compact syntax requires some time to get used to. Moreover IMHO Scala is really different from Java and shouldn’t be presented as a Java++ as some people tend to do to attract Java devs. Scala is OO yes but it’s mainly functional and if you don’t understand this, you write terrible Scala and you won’t understand 75% of Scala code which uses mainly functional features. Yet, those functional features are sometimes a bit more complicated than classic programming style and this is certainly the biggest effort to provide if you have never seen any functional aspects before. But This is also great because you learn lots of new things and you can improve your coding style for sure.
    Finally, I feel “satisfaction” coding in Scala, the kind of feeling I had lost with Java since years.

  6. Use SBT, IntelliJ, Install the IntelliJ Scala plugin and the SBT plugin for IntelliJ.
    Also add to your SBT build, then you can automatically generate the IntelliJ project FROM the SBT build script and then IntelliJ will automatically find all the JAR’s.
    Also – use ~compile command in SBT to have incremental compile working, then whenever you save a file, it only compiles the saved file.
    If you want to go further, consider JRebel.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s