Allen is a published fiction and non-fiction writer working on his second novel. He currently resides in Hanoi, Vietnam where he is traveling around SE Asia. He is an avid reader and lifelong geek interested in fiction, philosophy, and technology. Allen is a DZone Zone Leader and has posted 284 posts at DZone. You can read more from them at their website. View Full User Profile

A New Java Library for Amazing Productivity

02.15.2013
| 19296 views |
  • submit to reddit

Editor's Note: This article has been republished with the permission of the original author, Graham Lea

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:a 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.



Reference: http://www.grahamlea.com/2013/02/a-new-java-library-for-amazing-productivity/

Comments

Michael Faes replied on Fri, 2013/02/15 - 3:06am

 Let me tell you what's the difference. The difference is that using a new language means that you need new high-quality tools and IDE support. And this is where Scala fails big time. If I'm not able to (reliably!) apply quick fixes, do refactorings like rename, extract local or method or even do simple things like search references or quickly display the Javadoc when hovering over a method, then this new language simply doesn't make me more productive.

If Scala really were just a library, I would immediately use it in every Java project of mine. But since it is a language, I will have to wait until there is a decent (!) IDE for it. But before this happens, Java 8 will be out, featuring some of the most useful things in Scala as well. And good IDE support, of course!

Barry Smith replied on Fri, 2013/02/15 - 5:00am


Funny - up until you said Scala I thought you were talking about Groovy.

Of course, Groovy has pretty much the same benefits as Scala, plus it's production ready. Though for real JVM productivity you probably want Groovy+Java+Clojure+Grails.

Wujek Srujek replied on Fri, 2013/02/15 - 5:53am in response to: Barry Smith

I also thought of Groovy. Plus, as a response to the other commenter, Groovy does have good IDE support - try IDEA. Eclipse has something as well, but it's been a long time since I've given up on it...

Karl Peterbauer replied on Fri, 2013/02/15 - 6:11am

Uhh ohh, ascribing xenoglossophobia to anybody which is not willing to join the Scala fanboy parade seems quite disrespectful. Scala is a complex beast. If you do not agree to this statement, then please explain the difference between Scala's Null, null, Nil, Nothing and None to a newbie.


Serge Bureau replied on Fri, 2013/02/15 - 8:13am in response to: Karl Peterbauer

 Karl,

do not worry I am sure there is a cure to narrow vision.

With Scala, having 5 times less code makes many of those tools less useful, although many are on the way.

And as far as waiting for Java 8, it still miss so many features. Including a very low abstraction capability, pattern matching, tuples, a decent type system, ...

So please wait, others have work to do

Barry Smith replied on Fri, 2013/02/15 - 8:45am in response to: Serge Bureau


True, but still - why Scala when Groovy has pretty much all the same benefits, *plus* good IDE support and no inter-version compatibility issues and some great GUI RAD bolt ons in Griffon and Grails. Instead of simply saying how great Scala is, why not explain why someone might choose it over Groovy?

Wujek Srujek replied on Fri, 2013/02/15 - 9:02am in response to: Barry Smith

And before you say 'Groovy is not statically typed', do your homework first ;d

Silvio Bierman replied on Fri, 2013/02/15 - 12:10pm in response to: Wujek Srujek

Being statically typed is like being pregnant, either you are or you are not. And Groovy isn't.

I agree with the criticism of Scala being complex. But the Eclipse Scala IDE has improved enormously the last year.

If you can handle the langage it does deliver enormous productivity. If not, it may bring you down As always, you have to choose wisely.

Serge Bureau replied on Fri, 2013/02/15 - 1:27pm in response to: Barry Smith

 I Barry,

how about "because the creator of Groovy itself said he would not have created it had he known Scala was coming"

Enough said ?

Barry Smith replied on Fri, 2013/02/15 - 3:18pm in response to: Serge Bureau

That's another one ticked off my logical fallacy  bingo sheet. Got any actual reasons?

Besides, my argument is not about the superiority of one language or the other. Scala may be a better language if you judge them purely in the syntax. My point is that it's not better by a wide enough margin to justify its choice when you take into account the better third-party support and stability of Groovy.



Martin Gee replied on Fri, 2013/02/15 - 3:46pm in response to: Barry Smith

Groovy is what I was thinking too. And you can use it without learning a new language. 

Thai Dang Vu replied on Fri, 2013/02/15 - 4:03pm

I agree that Scala looks complex, but I don't think it will take you more time to learn Scala right now (when you know at least 1 programming language) than to learn C, Pascal, Java .... when you didn't know any programming language. Moreover, knowing 1 more language (no matter it's a programming language or a natural language) is good for you.

Barry Smith replied on Fri, 2013/02/15 - 4:06pm in response to: Martin Gee

 True - if you're going to put the effort into learning a new language why not learn Clojure and use Groovy :-) Certainly as a combination I think Groovy/Clojure blows away Scala. Clojure reigns supreme in the concurrent world while Groovy is easily Scala's equal for productivity.

Serge Bureau replied on Fri, 2013/02/15 - 4:20pm

Actually Barry,

I did use Groovy before I knew Scala and liked it, it is improving Java.

But Scala is at another level, incredibly consistent, Akka, pattern matching, integration of functional and object, type system,macros, ...

Groovy is nice, but no match. And on the abstraction level, Scala loose it even more in the dust.

And on parallel collections.

Too many things to even remember.


As far as productivity, you can always dream.

Wujek Srujek replied on Fri, 2013/02/15 - 4:51pm

The creator of Groovy, James Strachan, had been long gone from the development team at the time he made this statement. At this time Groovy had already become something completely different as it used to be before. I honestly don't know why he isn't doing Groovy any more, but it seems strange to say the least.

As for productivity, take a look at Clojure. It eats Scala for breakfast, IMHO. With Java 8, Groovy for scripting, and Clojure I see no place for the complex abomination Scala has become.

Serge Bureau replied on Fri, 2013/02/15 - 5:08pm in response to: Wujek Srujek

Sorry but Clojure has an abominable syntax, no objects, no Akka, a pityful way of doing abstraction. Sorry but I would prefer Groovy to it.

Java 8 will be an improvement, but still far from the mark.

As far as Scala abomination, I prefer facts to opinions.

Barry Smith replied on Fri, 2013/02/15 - 5:46pm in response to: Serge Bureau

 

"Sorry but Clojure has an abominable syntax"

Sorry but that syntax has been one of the longest surviving in the software industry for a very good reason. It is extremely powerful and expressive - Groovy and Scala's closures are but a pale imitation of the full Lisp style. I can only suggest you try using Clojure for a while until you properly understand it.

As for "no objects" - you should take a look at the leanpub book "Functional Programming for OO Programmers" - you can implement virtually a full OO system in Clojure in a couple of hundred lines.

Serge Bureau replied on Fri, 2013/02/15 - 6:03pm in response to: Barry Smith

Happy for you that you like Clojure.

But changing the name was necessary to gain some traction.

Sorry but I find Clojure badly lacking on abstraction, true I am not an expert. But I unfortunately do not have time to become expert on many languages.

As far as Lisp syntax, you can keep it. I,totally prefer Scala's one and it's type system, and so many other things missing to Clojure.

I know nobody around doing project using it.

Vitalii Tymchyshyn replied on Sat, 2013/02/16 - 12:30pm

The main difference between using library and using language is the scope. When you switch to another language, all your code is usually in that language. As far as I know mixed projects are considered anipattern in scala world. 

At the same time, library has it's place. When I use spring, I dont have it all over the code. Developer not knowing spring can write beans easily. Developer not knowing hibernate can use hibernate-based dao layer. 

This is impossible with language switch, that's why its more riskie.


Lund Wolfe replied on Sat, 2013/02/16 - 6:09pm

I like the analogy of language, libraries, and frameworks.

We do judge a language based on the quality and maturity of its available libraries and frameworks.  I can easily live without all of the Scala (or Ruby On Rails or Spring/Hibernate) features and productivity, so it isn't tempting to me, but when and if Scala matures to the point of available, quality libraries, frameworks, tools, and job and skilled developer numbers, then we will all become Scala developers.

If Scala or (insert favorite language here) is the right tool for the job, then use it now, but I think wide adoption is probably years away.

Nicolas Bousquet replied on Mon, 2013/02/18 - 9:27am

 It's funny how this post started a flame war on Clojure vs Groovy vs Scala... Why do we need to be so offencive? Thinking that only *our* choice is good and other are wrong?

I tend to agree with the API metaphor. It stick well because we can write each class in the (JVM) language we want. Like we can use a framework/API or not depending on the situation.

And theses languages don't come alone, they come with their (idiomatic) API that allow to leverage the language benefit the easy way.

Java is sure going to get some support for lambda expression. It's not available right now, but soon. But, by the time it's available on your application server of choice and validated by your company you may have to wait some more years. Also because the language was not designed for it, and it is carefully choosen syntaxic sugar to stay backward compatible, you may not be able to fully benefit of iy like you would in scala, clojure or groovy.

And, in all honestly, this cover only one of the features. Not to say that staying with java is bad. You just have to understand what you really have. And that scala is not just java with lambda expressions. That clojure and groovy are two totally different beasts than java too.

Developpers tend to think the programming language they use or like is "enough". Every feature it has are quite usefull, and they would not agree to use another language that might miss it. On the other side, whatever feature other languages might have that they miss is obviously useless... Until the day their prefered language start to use it.

I still remember when Java didn't have generics. People where arguing that the equivalent feature in C++ was useless, error prone and that Java designers where smart enough to avoid to have it in one form or another in java. Not so long ago, same argument was used for lambda expressions. Now that everybody know that they are added to all languages, and that even java is going to have them, people stop saying they are useless. They say they just have to "wait" for them being available in Java.

Just to say we are not alway very honest with ourselve and that sometime we often defend our prefered language for the wrong reasons.

Raging Infernoz replied on Mon, 2013/02/18 - 4:23pm

 WTF FAIL, and no messing.

Scala is not Java syntax, it not a library, it is a damned sight more complex, minority language, so forget about decent IDE support!

Hmm ..... Are there no moderators to stop ridiculous language trolling excuses for articles like this?

Edward Garson replied on Wed, 2013/02/20 - 10:33am

If Scala were a library, many developers would have stopped using it long ago because of "API stability" issues. 


Alan Escreet replied on Wed, 2013/02/20 - 12:34pm

I love the IDE support that comes with Java, but the boilerplate code is really bloating and annoying... still, things like Project Lombok do the job of solving that issue without requiring extra libraries to be shipped. That's some of the way toward the advantages of Scala without anyway...

Sergey Starodubtsev replied on Wed, 2013/02/20 - 9:10pm in response to: Michael Faes

Yeah. This is cruel reality.:)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.