As a technology manager, one of my teams consists of a web development group building  both internal and external business applications. The core platform is built on ColdFusion, a JVM based technology, mixed in with various other frameworks and technologies (jQuey, Flex, ColdBox, SQL Server, etc…).

A couple of years ago we had a project that involved integrating JBoss Drools (a business rules workflow engine), and we needed a way to easily bridge ColdFusion and Drools together, and came across the works of Barney Boisvert and his CFGroovy project. using CFGroovy, we were able to successfully complete the project, while being able to assess the Groovy language itself.

Meanwhile as the years went by, whenever we had to recruit additional talent we found it increasingly difficult (you can find an article I wrote on the topic at RIARockStars). We don’t even bother looking for ColdFusion developers any more, we look for any talented individual with a web engineering background willing to learn.

With the success that we had on that one project, and the seemingly shrinking ecosystem we decided on a strategy of switching over to another JVM language. The reasoning and hypothesis include:

  • Ability to progressively evolve our existing platform (we can do it feature by feature, vs. total rewrite)
  • Opens up access to the larger Java talent pool
  • Keeps the product on a more relevant platform
  • Keeps the staff’s skills relevant

Why not Java itself?

One of the huge benefits of ColdFusion is the incredible productivity and low learning curve. What one ColdFusion developer can do in a day would take 3-5 (if not more) Java developers to do. So productivity and learning curve remain priorities in order to maintain rapid turn around time on product updates.

The big assumption

There’s a big assumption – would a Java developer actually be interested in these non-Java JVM languages? We know from experience that Sr. level Java and .NET developers will not switch to ColdFusion as they feel invested in Java. So I threw a survey out (results below) to get a feel for what the Java community feels about these platforms.
I realize I didn’t quite ask the question directly in the survey, and as soon as I had sent it out I had received a number of responses and didn’t want to abandon that progress. So I’ll probably follow up with a much more direct survey, but big thanks to the Twitterverse for all the retweets in getting the word out.

Assessing the risk/potential

From a business perspective, going down a new technology path has its risks and rewards, and the information collected in this article is part of a series of analysis I’m conducting in order to validate/challenge the strategy. As a CIO/CTO, you’re investing hundreds of thousands if not millions in development time, thus your interest is to make sure of the merits behind the strategy by evaluating as much as you can:
  • Is the technology gaining traction in the community?
  • Who is backing it (corporation, random collection of open source guys, etc…)?
  • Is there corporate support?
  • What is the size of the community (aka talent pool)?
  • What is the momentum of the community (shrinking/growing, accelerating/decelerating, etc…)?
  • How long will it take for a team to achieve a degree of proficiency?
  • How do you get a team to proficiency (training, books, blogs, magazines, etc…)?
  • How fast is the technology improving (rate of releases, etc…)?
  • Have other companies been successful with the technology?
So to other technology execs out there, I hope this data proves useful.


This article is from the eyes of management, and not that of a developer. The findings are equally useful, but the conclusions a developer would make would be different than that of management. Most importantly as a developer, you should make it your mission to learn as many technologies as possible, it opens your eyes to new techniques and trends, and makes you an adaptive individual – and this is something a business values (Seven Languages in Seven Weeks is a particularly good book in this context).

Another thing to note is that I’m not evaluating the technologies themselves – there’s no shortage discussions and articles out there that cover this, so you can read up on those as part of evaluating technological fit (you’ll find some good ones on StackOverflow and Quora).

I’m by no means an expert on any of these platforms, and this was the result of a series of Googling for a week to gather various angles. If my perception is off on anything, I welcome the feedback. Thanks!



I just didn’t have the time to fully evaluate all of the JVM languages and their ecosystems, so I had to focus on (from my analysis) the biggest three: Groovy, Scala, and Clojure. Given more time, what I would need to do is focus the research on specifically web development as all these languages (including Java) encompass more than just web applications.

But I needed to start somewhere, and you can see where I try to rope in some web perspective.


Groovy at this point in time would be the conservative/safest bet, business wise. It’s like the Ryan Seacrest of non-Java JVM languages; its conservative, clean, polished, and very active. Groovy is like the athletic younger brother of the lethargic and obese Java.

It appears to have the overall largest ecosystem of the three, and is backed by a huge well known entity (VMWare/EMC). Grails being the web framework of interest, they’re also about to release a big 2.0 update.

I am very disappointed that although SpringSource mentions they have a Groovy and Grails courses, they actually don’t conduct any. This could be used as clue that there’s not enough interest to warrant hosting such classes (well more than a clue, that is the case), but you figure just for strategic reasons they’d take a loss on the training (the classic Gillette move, sell the razor at a loss and make it up on blades).

However, I found the Scala and Clojure training availability just as disappointing.


Scala would be the other strong contender. Although its ecosystem is smaller than Groovy’s, it has a noticeably more passionate community. As well, having Twitter as the big success story is a massive notch on its belt.

The funding of Scala would be on my things to keep an eye on. Part of Scala is backed by a Swiss university (EPFL), and educational institutions tend to be extremely bureaucratic and their funding dependent on government entities. And then you have a business also involved ( who has only been able to generate $3M in venture capital, based on the size of their corporate team, that money won’t last long if they’re not generating revenue (since they are private there’s no way to know).

Trending wise it appears to be accelerating in popularity – it’ll be interesting to resample six months from now and evaluate the landscape. Although not as many books as Groovy, its books are more current.


From a business perspective, I wouldn’t even put Clojure on the radar for now, I’d need to see if it gains more traction in order to justify investing in it, as well as a much more solid foundation behind it.


Although I don’t fully analyse it, the ColdFusion ecosystem is much larger than any of these languages. Extremely passionate community, backed by Adobe who invests millions per year in it, vast array of physical and online user groups, etc… As of right now, going by numbers, ColdFusion wins.

But, we wouldn’t be looking to hire a Groovy/Scala developer, just a developer willing to learn. I know that Java/.NET/PHP folks have no interest in ColdFusion (beleive me, we tried on many occasion). So the question is, is that the same situation with Groovy/Scala/etc…, and trend wise is it a matter of time and we’re just at the infancy stages?


The Data

JavaRanch Posts

  • Groovy: 2398
  • Scala: 625
  • Clojure: 532

Books on Amazon:

  • Groovy: 12
    • Grails; 7
  • Scala: 7
    • Lift: 2
  • Clojure: 6
    • Conjure: 0
    • Noir: 0

Note: The current offerings of the Groovy & Grails books are relatively old (most recent Groovy one being from 2008, and the most recent Grails ones from 2009).

User Groups:

  • Scala: 53
    • Lift: 4?
  • Clojure: 33
    • Noir: 0?
    • Conjure: 0?
  • Groovy: 23
    • Grails: 63

Email List Activity:

  • Groovy: 50/day
    • Grails: 83/day
  • Scala: 38/day
    • Lift: 46/day
  • Clojure: 33/day
    • Noir: 2/day (Google Groups)
    • Conjure: 1/day (Google Groups)

Tiobe Index:

  • Scala: 50
  • ColdFusion: 59
  • Groovy: 69
  • Clojure: not on the list

eWeek Article 09/12/11 (

  • “Groovy, JavaScript, Ruby among the fastest growing programming languages”
  • Note: the early relative percentages are interesting, but as impressive as a 100% increase is, going from 1 job to 2 jobs isn’t.
  • The more relevant thing here is the industry perception an article like this generates.

StackOverFlow Search on terms:

  • “groovy” : 4390
    • “grails” : 3391
  • “scala” : 3222
    • “lift” : 1608
  • “clojure” : 3059
    • “conjure” : 89
    • “noir” : 34

Source of funding/corporate support:

  • Groovy
    • SpringSource a VMWare company, subsidiary of EMC Corporation
      • VMWare: Publicly traded on the NYSE (VMW)
        • Employees: 9000 employees
        • Market Cap: $42B
        • Revenue: $3.54B
        • Gross Profit: $2.36B
      • EMC Corporation: Publicly traded on the NYSE (EMC)
        • Employees: 48,500
        • Market Cap: $51B
        • Revenue: $19B
        • Gross Profit: $10B
    • Team Size: 68? (
  • Scala:
    • Ecole Polytechnique Federale De Lausanne (EPFL), a Swiss Federal Institute of Technology organization.
    • Scala Solutions, acquired by TypeSafe.
      • Privately held
      • Founded in 2011 by the creators of Scala.
      • Received $3M (euro) in Series A funding on 5/12/2011 by Greylock Partners.
    • Team size: 12? (
  • Clojure
    • Primarily via the personal “commercial endeavors” of the creator of Clojure (Rich Hickey) and private donations.
    • Team size: 8? (

Who’s using it:

  • Scala
    • Twitter, LinkedIn, EDFT, Novell, The Guardian, Xebia, FourSquare, Sony, Siemens, Thatcham, OPower, GridGain, AppJet, Reaktor
  • Groovy
    •,,, Aegeon, eHarmony, EverBank, ExpertPlan, NetJay, NimBuzz, XWiki, Vodafone Music Store,
  • Clojure
    • BackType, Sonian, Fightcaster, Akamai, BankSimple, Relevance, KamaGames, Stere, Infinitely Beta, Wusoup, Factual, The Deadline, holodb, Prismatic, Amazon

Job Searches on

  • ColdFusion: 343
  • Groovy: 247
  • Scala: 126
  • Clojure: 20

Job Searches at

  • ColdFusion: 196
  • Groovy: 120
  • Scala: 64
  • Clojure: 9

Indeed/SimplyHired trends

Survey Responses

With just under 2000 responses, I don’t think the sampling is enough to be representative of the community as a whole, but it does provide some perspective. I even found out about even more JVM languages that I hadn’t heard of yet (Visage, Dart, Quercus, Frege, Dash, Mirah), and got a couple of Railo’s (which I wouldn’t count as a language as it’s an open source ColdFusion server).

12 Responses to “Sizing up the business perspective on Groovy, Scala, and other JVM languages”

  1. Couple things to note on the JAVA front: JSR 223 – Support for Dynamic Scripting Languages inside Java.

    Also note ColdFusion Zeus announced ability to work with java inline..

    I see much more merging of these technologies, and a good developer should then know how to advantages of the strengths of each.

  2. Tariq Ahmed says:

    @Sami: Yep, product strategy wise I think the big opportunity for the ColdFusion platform is to position itself as not an alternative to Java, but as an integration hub for all JVM languages.

  3. Great post Tariq.

    We are facing the exact same dilemma… 😉
    Compare to all those new comers, ColdFusion is a much mature technology and next release “Zeus” looks promising.
    But even if we still love it, it starts to show its age in terms of language/syntax (despite latest CFCs/CFScript improvements).
    Here in France, the ColdFusion ecosystem is nearby zero…

    Right now, Groovy/Grails seems to be the best option, pretty active in Europe.
    Grails is such great framework summarizing all the latest best practices in web/dev.

    We have designed our latest ColdFusion-based platform with a model 100% compatible with Grails. Since both use Hibernate ORM under the hood, it is easy to share the same model/DB so we could mix both technologies easily and migrate step by step.
    We also use FW/1 front-controller framework and ColdSpring IoC framework, so our applications architecture are very similar to Grails ones.

    Our goal is to build our next project on Grails, if we have the time and resources…
    Let’s keep in touch to share our thoughts on those subjects!

  4. Tariq Ahmed says:

    Thanks @Benoit! I’d love to hear about you and your team’s experiences as you go down this approach, I’ll be sure to do the same.

  5. Kurt Wiersma says:

    Our company is also looking to do new development in Grails instead of CF. We are in a very similar situation to Beniot. So far our team has really taken to Grails since it is structured in a very similar way to our current Mach II/ColdSpring/CF ORM apps.

  6. Eric Weimer says:

    IMHO the view you express as a “technology manager” needs to be understood by developers, especially if they wish to be marketable in the future.

    Thank you for a well written, clearly thought out, and most importantly, unbiased article.

    Since I consult I perform similar evaluations on the market. The metrics tend to be approximate and error prone, but trending can be seen over time.

    But I wonder if we have forgotten the lessons from COBOL which made programming accessible to a much wider audience.

    Functional languages tend to be hard and require more mathematically adept developers. They also may perform well on multi-core architectures and seem to be a good fit for specialized computation like business rules.

    Java shops seem to run under the illusion they benefit from a single language, but the reality is web developers also use HTML, JavaScript, CSS, XML, etc.

    Grails folks remind us we can resort to Java for special cases like computationally intensive code Do you think that will apply to functional languages as well?

  7. Nice comparison.

    I’ve been using Groovy on a Jboss Seam project in my company and recently started learning Scala.

    We got some developers in the team that just started coming to Java from Delphi, so they already have some work to do, and Groovy is easier for its learning curve; also, pretty productive.

    I tried using Jboss Seam plugins with Scala Eclipse plugin and it proved itself to be somewhat unstable. Since Groovy++ worked neatly (giving us compilation errors where pure dynamic groovy wouldn’t), probably we will be sticking with groovy for now.

    Seasoned Scala developers seems to be able to deliver some very powerful and hard-to-understand code, and we are nowhere near a scala developers nest or something like that. That is a problem when you got developers starting on it. Also our company is just starting, so it’s better to stick with a technology which doesn’t eat our budget on courses, consulting and the likes.

    We are nowhere in need for what scala offers, at least for now. But i’ll keep an eye on it and check its development and new resources.

  8. “Seasoned Scala developers seems to be able to deliver some very powerful and hard-to-understand code, and we are nowhere near a scala developers nest or something like that.”

    That’s reason enough for me not to use Scala. Far more time is spent reading code than writing code.

    I’ve been developing with Grails for a little more than 2 years. There is a lot of exciting stuff in the upcoming 2.0 release. Its also clear the community has been putting a lot of effort into the documentation. With over 700 plugins, its very easy to wire in new features.

    Another important aspect to consider is the quality of the community support. VMWare has hired core team members of Grails and Groovy. When I’ve turned to the forums or twitter for support, I’ve found that the VMWare guys are prompt to respond & are very helpful.

  9. Adrian says:

    Im the Dev Manager for a Technical Publishing Co in London and I’m currently going through the process of changing technology. We use CF 9, Coldbox etc and generally like developing with it, mostly choosing grads that we train up.

    But we want to change technologies for similar reasons Benoit mentioned (even though CF in London is not impossible to recruit for).

    I wanted to go to Grails/Groovy but found it near impossible to recruit for. Most developers seemingly being contractors in London and charging a lot of cash. The recruiters are telling me its a shrinking sector after an initial bit of popularity a few years back, which i found surprising (and disappointing).

    So my next choice was .Net MVC which I’m in the early stages of familiarising myself with since we use an MS stack already IIS7, SQLS 2008, and a couple of the dev guys have some if limited experience. Compared to the horror of web forms its actually quite a pleasant experience.

    Scala would be a bit too much I fear. I have played with it, but fear the syntax could get quite impenetrable and I’m not sure there is a mature web platform yet.

    I came from a Java background but was reluctant to go there, needing something lightweight, quick to develop for and easy to deploy.

  10. Tariq Ahmed says:

    @Adrian – thanks for sharing your story! The only thing I’d add about Groovy/Grails is that you wouldn’t bother trying to look for a Groovy developer. Instead find a Java developer as they’d be able to jump right into Groovy using the same syntax they’re already used to and can adopt the unique bits of Groovy that they feel comfortable with. Grails is just a collection of common frameworks glued together that a lot of Java enterprise developers are already used to (Hibernate, Spring, Quartz, jQuery). That’s really it’s main advantage is empowering Java developers to leverage their existing skills.

  11. Hey, i tried to go through your emaxples but come across this issue:No signature of method: static org.codehaus.groovy.grails.validation.ConstrainedProperty.registerNewConstraint() is applicable for argument typesthis happens when i add:org.codehaus.groovy.grails.validation.ConstrainedProperty.registerNewConstraint(PhoneNumberConstraint.PHONE_NUMBER_CONSTRAINT, PhoneNumberConstraint.class) to the Config.groovy class. Any idea how i could get past it ?thanks!

  12. Excellent post. I definitely appreciate this site.
    Keep writing!

Leave a Reply

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