A New Java Library for Amazing Productivity

Share Button

I’ve found this great Java library that can make developers more efficient in pretty much every source file they write. It has the following features:

  • Ferrari 458 Italiaa broad and powerful collections framework
  • collection methods that greatly reduce boilerplate
  • immutable collections that don’t have mutation methods (unlike java.util classes where e.g. List.add() throws an exception if the list is immutable)
  • an awesome switch-like function that doesn’t just match numbers, enums, chars and strings, but can succinctly match all kinds of patterns in lots of different classes, even in your own classes
  • an annotation that automatically writes meaningful equals, hashCode and toString methods for classes whose fields don’t change (without using reflection)
  • a feature for avoiding the duplication between fields and constructor parameters by declaring fields in your constructor signature
  • the ability to automatically generate property getters and setters at compile time
  • the option to define default values for parameters of methods rather than creating lots of overriding methods to do the same thing
  • the option of writing the names of parameters when you call a method to make your code more readable
  • a solution for using mixins, i.e. multiple inheritance of method definitions (not just interfaces) without ambiguity/the diamond problem
  • a nifty little class that avoids NullPointerExceptions by avoiding null altogether and instead expressing in your source code that you’re passing around or returning something that might not be present, forcing you to handle the possible ‘nothing’ but only when you want to use it
  • a way to give the appearance of adding new methods to existing classes (only where you want to use them), similar to C#’s extension methods and Objective-C’s categories.
  • the ability to easily pass around blocks of code for other classes to execute (without having to wrap them in a Callable class and a call() method signature)
  • some neat features for doing easy concurrent programs like parallel collections and an actor package
  • like all good libraries, you don’t have to convert your whole system to use it all at once; you can just use it in places where it makes the most sense to begin with. It will integrate very smoothly with all your existing code.

There are of course a few costs that come along with the benefits of using this Java library, but they’re fairly minor:

  • Your developers will have to learn how to use it. True of any new library you introduce to your team, really, and the efficiency gains will outstrip the learning cost pretty quickly.
  • Your code will look a bit different. This might take some people a bit of getting used to, but part of the reason it will look different is because there’ll be less code to write, so the Dev team can get more done.
  • If you’re growing your team, there may not be heaps of developers in the market that have experience with this library, but if you make a habit of hiring really smart programmers who can do pretty much anything you throw at them (that’s the approach we take at Tyro), then this shouldn’t be a problem.

Personally, I think this library is a godsend, and I think there’ll be a LOT of teams picking it up over the next five years, just like the popularity of Spring has swept the globe due to all the efficiencies it bestows on developers. The library, by the way, is called ‘Scala‘, and it was invented by a guy called Martin Odersky. Scala has been in development since 2001 and it’s …..

Hang on, there seems to be a question up the back. Yes? …..

Okay, the question is, “Isn’t Scala a language?” Well, of course it is. That’s what I’m talking about. The Scala language….

I’ve been calling it a “library”? Have I? Oh, sorry, I didn’t realise. Well, yes, you’re right, it is a language, although it also has a large useful library as well. But seriously, mate, what’s the difference?

SERIOUSLY, WHAT’S THE DIFFERENCE?!

Take a step back and think about this for a second: Why is it such a big deal to start using another “language” on a project, whereas for a “library” or “framework” the decision is much easier?

I know there’s sensible arguments we might use against employing a new language:

  • There’s a learning curve for developers who haven’t used the language before
  • There’s a technology risk if the language contains serious bugs or ceases to be supported
  • There may be difficulties integrating the language with existing code
  • If you decide to stick with the language, there’ll provably be legacy code from previous languages for a long time
  • It’s harder to hire developers who already know the language if it’s relatively new or novel

All of these are valid concerns and worth thinking about, but all of these concerns can just as easily be levelled at libraries and frameworks. (Read through the list again, but replace “language” with “framework”.)

Tailgate Languages

My real issue though is that this dichotomy is false. There isn’t a separation between libraries, frameworks and languages – it’s actually a sliding scale. What we’ve traditionally called libraries and frameworks will these days often introduce significant changes to the style of a codebase and even bring languages of their own tailgating in behind them.

Two examples of this are Hibernate and Spring: great projects, widely-adopted, delivering huge productivity gains. Hibernate brings with it HQL, a new language, similar to SQL, but different in the details. Employing Hibernate also means placing annotations throughout your domain model code. While the syntax of annotations is part of the Java spec, the number and complexity of annotations included in a spec like JPA 2 mean that they become a language unto themselves – a non-Java language that just happens to live inside our .java files.  Similarly, Spring does a lot for us by enhancing plain old Java classes, but the mechanisms for defining the enhancement are a language of their own, either in the form of <bean> configuration XML files or, again, using a suite of annotations.

As we’ve adopted these frameworks over the past decade, we’ve all changed our code to look vastly different to the Java of a decade ago, but we’ve embraced these changes because of the productivity the technology has delivered. Yet, when presented with the idea of adopting a new core language that would deliver similar productivity benefits, many teams baulk at the idea because… well, it would make the code look different!

What Are You Going To Do?

If Scala really was a “library” that was able to deliver all the benefits that I listed above, wouldn’t you and your team be desperate to start using it? And yet, because it has the label “language” attached to it, many people don’t even consider the possibility of using it, let alone whether the benefits outweigh the costs. It’s time to stop the xenoglossophobia (other language scardey-cat-ness), rise above the fear of learning something a bit different (because we’re doing that anyway!) and start evaluating all technologies on their merits.

And once you’ve thought about that for a while, start coding in Scala. ;)

PS – If you’re wondering how the complexity of Scala compares to Spring, the Scala SDK has around 1,000 classes while the public Spring API has over 2,700.

Update: If you’re a Scala programmer reading this, I’m now running a short survey to get some numbers around whether Scala really is more productive. Would love it if you could take 2 minutes to contribute.

Image credit: Romain Drapri

Want to learn more?

Share Button

29 thoughts on “A New Java Library for Amazing Productivity

  1. Great post. I use Scala mostly as a productivity enhancement and don’t feel like I’m losing out by not putting effort in to understanding the more functional aspects.

    One question, you claim Scala has “an annotation that automatically writes meaningful equals, hashCode and toString methods” but I can’t find this anywhere. I usually use Commons HashCodeGenerator or a (slow) helper trait that converts the object to a list first. Case classes have this behaviour out of the box but conceptually alter your classes.

  2. “immutable collections that don’t have mutation methods”

    Scala’s immutable collections are persistently immutable so they absolutely have mutation methods.

    Java 8 fixes roughly five other bullet points.

    I love Scala and use it for certain personal projects, but some tooling issue make me hesitate to push my manager for it at my day job.

    • Perhaps we mean different things by “mutation methods”. I was referring to the fact that you can get “immutable” collections in Java (Collections.unmodifiableList()), but the interface of these still have methods like add() that purport to mutate the collection but will fail at runtime if called.

  3. Minor detail you missed. Every time the “library” is updated, you have to recompile your program and all third-party software from source! Oh, and there are so many orthogonal features that Scala devs themselves don’t know how to write tests for them.

    I think two other libraries with much more promise being developed by industry users as opposed to academic folks are Kotlin and Ceylon.

    my 2 cents

        • I didn’t think it was obvious. (Otherwise I wouldn’t have asked the question.) Perhaps my question would have been better phrased as “What statistics would help convince you that developers using Scala can be more productive than with Java?” I would love to ask you this question, Steve J., except you would find it hard to respond because you left a fake email address.

    • It’s true. How does one measure such productivity? I’m not sure, but most developers _feel_ more productive using Scala, whatever that’s worth.

  4. It is a great argument for Scala no doubt. And their are several settings in which it would absolutely make sense. There are also cases where it’s impractical.

    What you’ve highlighted is a good way to look at it but there are more than a few psychological blocks that makes adopting Scala much harder than adopting a new “library”. For one, I don’t believe comparing the number of public API classes is a surefire way to estimate the complexity.

    The functional Paradigm can be a massive obstacle in and of itself. I remember probably just about 2 years ago I had to learn Scala. For someone who was spoon fed Java & C++, the object oriented jargon was baked in.

    The results of then trying to look at the functional way of doing things was “I just didn’t get it”. I’ve bounced between several languages Python, C++,Java even JavaScript to name a few, but never had it been so difficult to dive in than it was with Scala.

    From memory it took some 2-3 weeks to get familiar enough to take the training wheels off and stop writing hello world programs but even then when I wrote Scala code it was very much Java with a slightly different syntax. As most Scala devs. can probably attest Scala in that form is almost always going to be inferior to their Java equivalents. As far as I can tell I’m still “learning” Scala to this day. There are still useful things I come across by chance that just makes things so much clearer.

    To close off, I do not disagree with you entirely, I just believe there are far more things to be considered and that some of the things mentioned have been down played. It’d be great to see Scala more widely adopted because by far the biggest problem we’ve found has been finding devs. who already know Scala or have been exposed to other functional languages. That issue alone is a mammoth of an obstacle that’ll take more time than the others to be resolved.
    Perhaps the Scala circle (myself included) needs to do more to reach out to those who still find it so alien.

    • Scala for a Java dev (or C#, C, C++, Python, etc…) is like MongoDB for an SQL expert, it’s required to change the way to think to find a nice solution. You can, of course, use Scala and write Java code, but honestly, it doesn’t make sense at all, it’s like using MongoDB with the same schema used in a SQL database.
      Scala is powerful, but requires to be learned and understood, it mixes the functional programming to the “classic” structured programming in a way that the code can be shorter, faster to write and more performant, but hard to understand by someone that sees Scala for the first time and can even turn into unmaintainable code. Scala is difficult, can’t say the opposite, but it’s probably one of most promising languages.

      In term of performances, I suggest to read this document, made by a Google engineer:
      https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf

      And if you want numbers about Scala used in production environment with success, search for what Foursquare, Twitter and LinkedIn said about adopting Scala.
      Many others big companies started adopting Scala as well, like HSBC, Credit Suisse, Morgan Stanley, etc…
      http://www.scala-lang.org/node/10923

  5. I love your method of presentation. Well done!

    I find it quite fascinating how different thinkings/rationalists/etc. emotionally show their confirmation biases and passive aggressive opposition to anything that threatens their currnent comfortable understanding of the computer language world. However, they don’t think twice about diving into arcane weird libraries with which they then burden their projects for many future iterations.

    It’s the wonderful confirmation-bias confusions backed by severe insecurities that generate so much ado about nothing.

    The core worry I see is there are a huge number of people that are becoming very concerned that Scala could become the “next big thing”. And that threatens their own current big thing. So, they have a choice to adapt and respond, or fling insults, redirections (like references to Koituslin and CyaLaterLon) and other equally silly distractions which attempt to detract and distract from your key point:

    Scala’s coming no matter what. So, try and find a way to become comfortable with it’s inevitable adoption. Those that early adopt are going to do very well, just like those who early adopted on Java.

  6. I am basically not a programmer and I am comparatively new to Java technology , so I was wondering what all topics should be covered up if i have to start java from the start and has any one
    studied or got any info regarding this 6 week java training online course http://www.wiziq.com/course/12145-the-6-week-complete-java-primer-with-training-certificate and should we also have knowledge of C language before we further move on to Advance Java topics??

    • If you are not a programmer but are thinking of starting a career in software development, I would really, really suggest going to university and getting a Computer Science degree. (I mean study, take the exams and earn one – don’t just walk into the office and steal a degree.)

      If you just want to learn to do some programming in your spare time, I would NOT recommend forking out money for anything. There is so much free learning material online that you will be able to learn pretty much anything about Java online. For instance, it took me about 2 minutes of Googling to find this FREE online course from Stanford University that introduces both programming and Java. I hope that helps, and good luck!

  7. Re: “I’ve been calling it a “library”? Have I? Oh, sorry, I didn’t realise. Well, yes, you’re right, it is a language, although it also has a large useful library as well. But seriously, mate, what’s the difference?”

    One word: Tools

    • I’ve actually been using Scala for a real world application that is now in production and I can say that while tool support for Scala is not as good as tool support for Java, it is still quite good.

      For starters, many tools that work with Java work fine for Scala right out of the box (it is, after all, a JVM language) – YourKit for example.

      As far as IDEs go, well, there’s plug-ins for two of the three main Java IDEs (Eclipse and IDEA, but not, so far as I know, NetBeans). I’m an IDEA guy, and their Scala plug-in has steadily improved over the last two years. It doesn’t have all of the support that they do for Java, but it’s more than good enough. I can say that because, after all, I did get a brand new system into production using nothing more than IDEA and YourKit.

  8. Nice post! In defense of Scala there is something I would like to add: I have been working with java for 5+ years, always trying to get things done in the best possible way, always trying to find the most efficient and extensible way to solve the problem at hand and after all this time I realize most developers (included myself) start doing it wrong from their first steps.. Let’s review a very simple example: getters and setters, I have seen a looot of people generating them automatically from their IDE without thinking, just because that’s what you do when you create a class…then, what stops you from mutating those objects everywhere you can? (And possibly introducing nasty bugs by doing so?)… Then you take this people and show them a immutable version of their class and it just isn’t right for them, they don’t feel comfortable with it and think it is hard to embrace immutability… Does it mean immutability is bad? I don’t think so.. It’s just that people usually don’t understand the problem with mutation.. how can people adopt a solution to a problem they don’t know they have? Something similar happens with Scala, it isn’t hard to understand, it isn’t hard to adopt, you just need people who is open to find a better way to think and code.

  9. - There is much more to productivity than being concise. The community infrastructure (library, tools, IDE support, learning aids) is critical to “productivity”.
    - A language gains mind-share and market-share based on what you can do with it and how many people want to do that thing. New languages like Scala and Erlang make it easier to write what I call “agent oriented” architectures. They support the concept of distributed parallel processing in a robust and transparent way.

  10. Ha, I thought, I know this library you are talking about! I used it before, and it’s a joy to use! It’s fast, consistent, dynamic, used by millions… Groovy of course!

    Oh well, I was not far of anyway.

  11. Pingback: Scala Productivity. A Survey of the Community | JetBrains IntelliJ IDEA Blog

  12. �. Związane grabie Przynęcająca maszyny. uniosła do twarzy,
    na budowie zasłaniając usta.

    Trach krokodylka. Ciałko kurczy się, kiedy dalece pozwala ciasno oplatająca zrzyna

    opaska. Łup.

    . jeszcze nie.

    Rześkie punkt widzenia, przed rzeczywistość zatonie w bólu, zaś
    płuca pękną odkąd krzyku. Ich

    oczy się spotkały. Frodo proch odczucie, że zwariował, że
    przed jeszcze jego

    biednego fiuta schwyciły zęby krokodylka, startuje
    mie.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>