Looks like Scala is widening its adoption lead over Clojure. I think the latter is going to become a niche language for large-scale data processing, while the former takes its place as the next enterprise language.
Same old story: Developers aren't interested in it if it isn't friendly to the old school OOP + MVC approach. If you give most professional developers something like Clojure, their first thought is "How do I architect a large application this way?" and they don't know the answer.
(This is speaking as someone who thinks Clojure is the best language on the planet right now...)
I find this to be true of a lot of promising new technologies.
None of my day-to-day work is the kind of flashy/bleeding edge stuff that HN tends to cater to, but I'm always on the lookout for new tools that'll make things easier or more reliable.
Oftentimes I'll go to evaluate something new only to find that their examples are the tried and true "get some tweets and do something with them" or "here's how you make yet another blog platform."
Great. If my job consisted of making blogging platforms I might be interested. Show me how your product will free me from having to handle the drudgery of setting up yet another similar-yet-slightly-different form. Show me how your new framework makes it easier to do integration with several developers. Show me something that'll let me ease the technical debt we've accrued. That kind of thing.
While I have absolutely no problem with your opinions on programming languages (or anyone's, for that matter), I do not believe you are being very accurate when representing the views of the majority of developers.
When you give most professional developers something like clojure, they ask: Where are my objects? where are my types? Going back to a relatively typeless system and having to go to documentation to figure out what operations have been written for a data structure, instead of just pushing dot and seeing a bunch of them, is quite the cultural shock.
It's really about the strengths of the language being things your average developer is relatively uninterested in. You pay the price of S expressions to make it easier to do metaprogramming. But what if you don't want to spend your time metaprogramming? Then suddenly what seem like strengths to some suddenly turn into weaknesses.
Clojure has its niche, probably as a better alternative to R in scientific environments where metaprogramming can give you tremendous gains, but it doesn't really fit what most of us have to do in a daily basis any more than writing it all in C.
This was my initial struggle with Clojure too, trying to fit my existing world views into the language. It didn't take me long to realize my world views were completely wrong, not Clojure.
Most developers don't want to learn, they want to ship. Even if this means reusing the same old school OOP+MVC approach and all the potential bugs and balls of muds it almost always creates over time.
Yet this is what I like most about Clojure: the language makes it harder for you to write big balls of mud. If your design isn't simple to implement in Clojure, it's a pretty good sign it isn't such a good design to begin with.
(I'm also someone who thinks Clojure is the best language right now)
> Looks like Scala is widening its adoption lead over Clojure
I agree that this is a very important and interesting topic, but how did you draw that conclusion from the survey? The question wasn't "Do you use Scala?" or "Do you use Clojure"? The way they phrased it was a bit confusing, actually. I don't think you can draw any conclusions about adoption rates of Clojure or Scala from this data.
It also shows Groovy over Clojure which can't possibly be true. I'm basing my disbelief on what my connections are working in in the dc area, literally no one works on Groovy unless they have to deal with Gradle.
Groovy gets a fair bit of mileage in Enterprise systems where something more flexible than Java for some component was preferred but still felt like Java was desired. I have also seen some startups using Groovy because of Grails.
I use it often personally and it is my goto non-Java JVM language because it's easy to read, write and find people who can maintain whatever mess I create :P
I'd love to see a comparison among the same sample set between Java8 & Scala as the next environment they're likely to use.
Scala has been "the next big thing" for a while now, but I'm just not convinced that the Java ecosystem is looking for a next thing at all.
To be clear: I absolutely agree that we can do better than Java, and though I prefer Clojure, Scala is certainly a step up. I'm just not convinced that the practical realities of its user base are enough to drive that change, which limits my willingness to move my organization in that direction.
Java developers seem really interested in Scala (more so than Java 8). I think the distinction which will come in when comparing technologies that developers want to use and are really interested in vs those that they will actually use given inertia of existing code and corporate adoption.
Those are answers to two very different questions, and the percentages aren't comparable. The Scala one asked what JVM language would you learn next, if you were to learn one, while Java 8 is the answer to the question: what is your top new-tech priority for 2015?
> Those were two different questions. The Scala one asked what JVM language would you learn next, if you were to learn one
Indeed. I wonder if the result is a bit misleading, because many Java developers may not really have considered other languages, and Scala is the most well-publicised. So the question may just translate to "name another JVM language." Kinda reflects with Groovy too, which has been around quite a while now and does well in this question, despite not being very "popular" in the various language league tables.
Can Xtend even be compiled to Java outside of Eclipse? I haven't been following recent improvements, but when I last checked, that wasn't possible. So it was essentially an in-IDE-only language, nice for little scripts, but completely useless for larger applications (or teams)
How on earth does Scala garner nearly 50% developer interest in the survey??
That's quite a surprise given the bashing Scala has taken of late (AKA the Paul Phillips Scala "tribute" tour), and the general thumbs down that Scala receives on HN, Reddit, etc.
Kotlin should pick up some steam once a stable release comes around, they've done a good job cherry picking the best of Scala while avoiding the kitchen sink baggage that Scala hopes to shed somewhere down the road (with Scala 3 backed by Dotty[1]).
Not sure about Clojure, certainly has a following, but is probably not going to appeal to the enterprise crowd, whereas Scala, Kotlin, Ceylon, etc. type safe and familiar-ish syntax languages will.
Java 8 (and 9 to come) is the elephant in the room, hopefully won't crush alternate JVM language adoption, diversity's a good thing.
Until Kotlin or Ceylon get a stable release (or 2) under their belt there aren't a lot of alternatives for JVM developers that want strong typing without the baggage of Java.
As a Scala developer I have a whole list of things I don't like, but Java 7 is a non-starter for me, and while Java 8 looks great, it is still missing a lot of features I want/need.
I'd love to give other JVM languages a try but can't afford to go through the growing pains of early releases. Scala has gotten over that major hump at least.
I wouldn't read too much into enthusiastic Scala downvoting on the programming subreddit. It seems that most people I know who have used Scala love it, but there are those who don't who tend to be very vocal online. What is interesting is how many downvoters have never used Scala but have the Paul Phillips video bookmarked for every discussion where Scala is mentioned.
"Kotlin should pick up some steam once a stable release comes around, they've done a good job cherry picking the best of Scala while avoiding the kitchen sink baggage"
I disagree. They picked mostly the easy features like lambdas or null-safety, while they deliberately left out the game-changing features like implicits or type-classes. So Kotlin is just a better Java, with the amount of "betterness" significantly reduced now by Java 8.
> Java 8 (and 9 to come) is the elephant in the room, hopefully won't crush alternate JVM language adoption, diversity's a good thing.
While I agree, I also think that some of the less hardcore JVM languages (Kotlin, Ceylon etc) were mainly developed because of how stale Java itself became / is; even Java 8 only adds very basic support and use cases for lambdas, mostly to retain backwards compatibility with existing libraries.
I don't think it will crush the alternatives, but it may stop them from becoming one of the top mainstream languages (latest RedMonk analysis had Scala at the top of the chasing pack for example).
I don't get the equation of Scala and Kotlin and Ceylon.
Ceylon and Kotlin grab the low-hanging fruit. They are better Javas. These languages bring nothing new to the table at all. They will actually suffer from Java 8, because Java 8 itself is a better Java like they are. People write Kotlin and Ceylon because they need to write a Java app but they don't want to write Java.
Scala is not meant to be a better Java. It can be used in that way, but it's not meant to be. It has a vastly richer set of features, probably one of the most sophisticated type systems of any language, and a growing number of Scala-specific libraries. In addition to people writing Scala because they don't want to write Java, there exist many people that want to write Scala because of Scala.
The same general argument seems to apply to Clojure. Just because your language runs on the JVM doesn't mean it's just an alternative for Java.
(This is not to say that I don't think Kotlin at least is shaping up to be a beautiful language.)
The question is one of numbers. How many Scala developers use it as a better Java, and how many use it for its "richer set of features". The first group would likely benefit more from Kotlin (as those other features are, IMO, Scala's Achilles heel), and if that group is the larger one (and I suspect it most certainly is), then Kotlin is in direct competition with Scala.
As to "bringing nothing new to the table at all", I'm not sure about that. It depends on your definition of "nothing" and "something". I think they certainly bring convenience, and their[1] switching costs are orders of magnitude lower compared with Scala's. The question is, then, is the "something new" Scala brings worth the price. Again, the answer to that depends on the user. Some will think it most certainly is; others will find the cost way too high.
> their switching costs are orders of magnitude lower compared with Scala's.
How so? Scala may have more ways for features to interact and I guess a larger library ecosystem to become aware of (though it seems perverse to count a large library ecosystem as a downside), but IME most of the cost of switching is in tooling support and finding a developer community to answer questions - both areas where Scala is far ahead of something like Kotlin.
Because if you have a Java project, it's trivial to write a few classes in Kotlin. It feels perfectly natural to have a mixed Java/Kotlin package. Integration is seamless. Scala/Java integration, OTOH, is a pain, especially if you want it to feel natural in both languages, or even only in Scala. Even Clojure/Java integration is easier than Scala/Java integration.
Clojure has beautiful Java interopability for a Lisp, and Java really does break down idiomatic Scala a lot. But that last sentence is way too hyperbolic.
It's maybe even wrong of me to lump Ceylon and Kotlin together. Kotlin definitely is richer (and closer to Scala in features) and can also compile to JavaScript, which puts it in a different boat.
As a straight and immediate Java replacement, I'd definitely recommend Kotlin as well. If you want to switch over existing Spring apps, you will not get the best out of Scala. Scala, in my experience, is most effective when written without Java goggles on. But Scala definitely has large advantages for new projects or broad refactorings.
Ceylon also targets compile-to-javascript. (I thought Kotlin kept the standard Java library - have they compiled a version of that for javascript or what?)
I'm not sure about Kotlin's plans re Javascript standard libraries, but I guess the approach is similar to Clojure, i.e. being a "hosted language" aimed at easy integration with the host environment (plus a very basic "common" standard library).
If anything that makes it less reliable for compile-to-javascript than Ceylon, no? (AIUI Ceylon abandons the Java standard library in favour of its own, partly so that you have the same standard library for either target).
I think that zeroturnaround used to support Scala for free, and maybe they still do, so perhaps developers taking a zeroturnaround survey are not representative?
I was surprised by how well Scala did in the survey. Except for totally enjoying Martin Odersky's Scala course on Coursera, I personally don't use Scala very much. On the other hand I find Clojure, and to a lesser extent JRuby to be go-to tools for some projects.
I think Java 8 really is the elephant in the room. I started using Java 8 several months before the official release and it has brought some joy back to Java development.
Am I wrong in assuming that the responders are JRebel users? I'm asking this question because I wonder how representative is this sample compared to the industry in general (I know, this could be asked about any survey, really).
For instance, use of MySql with 32% seems too high to me, this, compared to what I've seen around. The main persistence solution of 1 out of 3 of my connections is not MySQL.
I wasn't using it, but it had a reputation for being slow and for the replication being considerably more broken than MySQL's -- apparently both of those have come a long way since.
It was hard to install for shared hosting, so most aspiring developers became familiar with MySQL first, with resulting network effects.
The client was a bit harder to use (\x commands are harder to memorize than mysql's "SHOW TABLE" and felt sluggish in a local environment (something that's no longer the case AIUI)).
Replication was a third party addon at the time, and had a reputation for being hairy, though I don't have direct experience.
That's a great point. JRebel's the kind of tool I imagine a lot of middle-sized (not startup sized, not yet enterprise) codebases probably haven't evaluated, so I'd imagine it's tied to MySQL being a frequent choice for new apps and the quick choice for a one-off internal app in the enterprise.
While this is anecdotal, like you I've find the DBs most of the Java apps I encounter aren't MySQL, but a mix of Postgres, MSSQL and Oracle.
Unfortunately this is exactly the kind of anecdotal which just doesn't work. Popularity of tools and technologies varies greatly between geographies, industries and maturity. E.g. English-speaking world and German-speaking world value tools and techs in entirely different ways.
Also, note that MySQL was the only half-way trustworthy free database in the market. The popularity of PostgreSQL has been on the rise only since a few years. So if "free" (as in beer) is what you're after, then MySQL was the only choice for a very long time. Once you build upon MySQL (or any DBMS), you don't switch easily...
Given that RebelLabs is not mainly focused on JRebel users (it's more of a general ZeroTurnaround content marketing platform), the target audience is certainly JRebel-friendly. So yes, the results are biased towards that sort of audience.
Hi, Oliver here (the report's author). Actually, we specifically stayed away from contacting JRebel users simply to avoid any additional bias. Our charity approach (each completed survey donated to a charity that brings video games to kids in hospitals) that we didn't need to promote it as heavily to our own contact. We spread the word successfully through contacting RebelLabs subscribers, VirtualJUG and London Java Community (LJC) members and individuals in the industry. That said, there are certainly some JRebel users in there, although we didn't ask specifically.
Maven is wonderful because it means I can pick up any Java project and there will be no surprises in how it builds; it simply won't allow your project to be a special snowflake with its own weird rules. I wish the community would cherish this and stop writing tools that make it possible to set up more complicated builds.
> In the past, Maven (64%) and Ant + Ivy (16.5%) have been more or less neck and neck. Indeed, we believe that many developers often use both in different ways on complex projects – in 2012, 67% of respondents used Maven and 48% used Ant. [...] Ant with or without Ivy is only one-third as commonplace as it was reported in 2012. The rapid increase of Gradle (11%) is also interesting to witness. Since 2012, Gradle use has more than doubled
The 2014 question was what build tool is used most often, whereas the 2012 figures are for what build tool was used, with some overlap.
So Maven use has stayed high for those using it, whereas Ant users have either given up on it, use Maven more often, or have switched to Gradle (which is still Ant).
I wouldn't trust the download numbers given by the Gradleware CEO, though. The Groovy ecosystem has a long history of fabricating numbers, e.g. look at https://bintray.com/groovy/maven/groovy/view/statistics and see 865,000 downloads of Groovy in the past month, then click on country and see 822,000 of them are from China, and only 17,000 from the US.
I've used Ant, Gradle and Maven - they all suck, but in different ways.
Maven is too restrictive and its XML too verbose, but Gradle can turn to spaghetti code, its DSL is often hard to debug and sometimes under-documented, and could be faster imho.
Maybe one day Gradle will suck less than Maven, but currently I think they're about the same.
"gradle" is nothing but "ant", though not in XML. Gradle is appealing to the crowd that likes ant. Also gradle is super slow compared with ant or maven.
Actually no, Gradle is Ant + dependency management + reusable code (plugins) with a convention-over-configuration philosophy, using Groovy instead of XML. So no, Gradle is not just Ant. But god is it slow, I agree to that.
We don't know anything about the popularity of these tools in the Java community. This is not a random sample of Java developers. It's a self selected group of people who took part in a survey conducted by a Java tools vendor.
The process was reasonably random - the survey was distributed to the global Java User Groups & I'd say over 2000 responses is something worth paying attention to statistically (yeah, I know - out of x Million Java developers it's still a tiny sample set).
I think that's more of a reflection of the RebelLabs blog readership than the Java developer community at large. Their products as well as their blog, are geared mostly to web developers.
It either means Android makes up only a small percentage of the total Java market... or the group used to create these statistics is not representative of the Java developer world as a whole.
I doubt Android is counted in here at all. It's really a different beast compared to regular Java. This 'mobile' figure could be explained by Java Mobile Edition developers alone.
Slide 3 doesn't speak for me except for Java 8. I've looked at Scala, don't like the syntax, give me heartburn like trying to look at Lisp, Smalltalk, Ruby or Haskell. Eclipse so totally rocks, it beats the $1000+ cost of Visual Studio and Intellij isn't even in my rear view mirror. Gradle, syntax does not work in my brain, I get the same feeling as when looking at the languages I mentioned earlier. Give me make, Ant and/or Maven (though you have to be careful to keep Maven on a short leash).
Java versions – Adoption since 2012 of the newest Java versions has been strong, namely growth in Java SE 7 and Java EE 6…the fact that certain older version of Java SE and EE still command decent minorities is a bit odd, but nothing to fear.
IDEs – Eclipse is a very stable market leader, but increasing favor and interest in IntelliJ IDEA may eventually equalize things.
Alternative JVM languages – Scala is the most interesting, enterprise-ready language on the JVM, and Groovy & Clojure play a great counterpart to the non-Java coding movement.
Build tools – Maven’s dominance is now unquestioned with Ant’s decline from previous years, although fast-growing Gradle is extremely interesting to respondents.
Application servers – Open-source players like Tomcat, JBoss, Jetty and GlassFish dominate both production and development environments, which use the same technology for 81% of respondents, although it’s clear that development-only app servers in the highest favor are Jetty, Tomcat & TomEE.
Web frameworks – A mature and fragmented market, over 1/3 of developers use more than 1 web framework, and here Spring MVC is still king in this area, with stable JSF and growing Vaadin following
Object-relational mapping frameworks – When it comes to ORM, Hibernate takes the cake, although other technologies are available and in common use in parallel.
Code analysis tools – Although nearly 1/3 of developers don’t use these tools (big mistake), the market is rich with complementary technologies like FindBugs, CheckStyle and a platform to bring it all together, SonarQube.
Continuous Integration (CI) servers – Jenkins’ dominance here is stronger than ever, yet 1 in 5 developers still don’t use CI as a practice.
Databases: SQL and NoSQL – The mature SQL is dominated by Oracle, but the market has a good mix of free/open-source and proprietary offerings from long-time players. NoSQL is a maturing segment that is mainly driven by MongoDB.
Version Control Systems (VCS) – Git, supported by the headline-worthy GitHub, is finally reigning supreme over Mercurial as a distributed VCS, and is often used in parallel with the legacy Subversion (SVN).
Repositories – A maturing market that still needs a lot of adoption by developers, the legacy market leader Nexus is losing ground to JFrog’s Artifactory.
Testing frameworks – In this area, complementary technologies work better together rather than competing, with unit testing, mocking and browser testing all highly practiced using strong tools like JUnit, Mockito and Selenium respectively.
Priorities for 2015 – Java 8 (obviously), Continous Delivery / Deployment and Non-Java programming using alternative JVM languages are the 3 top priorities for the next year according to respondents.
64 comments
[ 3.7 ms ] story [ 150 ms ] thread(This is speaking as someone who thinks Clojure is the best language on the planet right now...)
None of my day-to-day work is the kind of flashy/bleeding edge stuff that HN tends to cater to, but I'm always on the lookout for new tools that'll make things easier or more reliable.
Oftentimes I'll go to evaluate something new only to find that their examples are the tried and true "get some tweets and do something with them" or "here's how you make yet another blog platform."
Great. If my job consisted of making blogging platforms I might be interested. Show me how your product will free me from having to handle the drudgery of setting up yet another similar-yet-slightly-different form. Show me how your new framework makes it easier to do integration with several developers. Show me something that'll let me ease the technical debt we've accrued. That kind of thing.
When you give most professional developers something like clojure, they ask: Where are my objects? where are my types? Going back to a relatively typeless system and having to go to documentation to figure out what operations have been written for a data structure, instead of just pushing dot and seeing a bunch of them, is quite the cultural shock.
It's really about the strengths of the language being things your average developer is relatively uninterested in. You pay the price of S expressions to make it easier to do metaprogramming. But what if you don't want to spend your time metaprogramming? Then suddenly what seem like strengths to some suddenly turn into weaknesses.
Clojure has its niche, probably as a better alternative to R in scientific environments where metaprogramming can give you tremendous gains, but it doesn't really fit what most of us have to do in a daily basis any more than writing it all in C.
Most developers don't want to learn, they want to ship. Even if this means reusing the same old school OOP+MVC approach and all the potential bugs and balls of muds it almost always creates over time.
Yet this is what I like most about Clojure: the language makes it harder for you to write big balls of mud. If your design isn't simple to implement in Clojure, it's a pretty good sign it isn't such a good design to begin with.
(I'm also someone who thinks Clojure is the best language right now)
I agree that this is a very important and interesting topic, but how did you draw that conclusion from the survey? The question wasn't "Do you use Scala?" or "Do you use Clojure"? The way they phrased it was a bit confusing, actually. I don't think you can draw any conclusions about adoption rates of Clojure or Scala from this data.
I use it often personally and it is my goto non-Java JVM language because it's easy to read, write and find people who can maintain whatever mess I create :P
“If you had to choose just one additional JVM language to learn about, it would probably be..?”
...to which 47% replied Scala, 31% Groovy, and 12% Clojure.
Scala has been "the next big thing" for a while now, but I'm just not convinced that the Java ecosystem is looking for a next thing at all.
To be clear: I absolutely agree that we can do better than Java, and though I prefer Clojure, Scala is certainly a step up. I'm just not convinced that the practical realities of its user base are enough to drive that change, which limits my willingness to move my organization in that direction.
Scala: 47%
Java 8: 35%
http://zeroturnaround.com/wp-content/uploads/2014/05/what-te...
Java developers seem really interested in Scala (more so than Java 8). I think the distinction which will come in when comparing technologies that developers want to use and are really interested in vs those that they will actually use given inertia of existing code and corporate adoption.
Indeed. I wonder if the result is a bit misleading, because many Java developers may not really have considered other languages, and Scala is the most well-publicised. So the question may just translate to "name another JVM language." Kinda reflects with Groovy too, which has been around quite a while now and does well in this question, despite not being very "popular" in the various language league tables.
That's quite a surprise given the bashing Scala has taken of late (AKA the Paul Phillips Scala "tribute" tour), and the general thumbs down that Scala receives on HN, Reddit, etc.
Kotlin should pick up some steam once a stable release comes around, they've done a good job cherry picking the best of Scala while avoiding the kitchen sink baggage that Scala hopes to shed somewhere down the road (with Scala 3 backed by Dotty[1]).
Not sure about Clojure, certainly has a following, but is probably not going to appeal to the enterprise crowd, whereas Scala, Kotlin, Ceylon, etc. type safe and familiar-ish syntax languages will.
Java 8 (and 9 to come) is the elephant in the room, hopefully won't crush alternate JVM language adoption, diversity's a good thing.
[1] https://github.com/lampepfl/dotty
As a Scala developer I have a whole list of things I don't like, but Java 7 is a non-starter for me, and while Java 8 looks great, it is still missing a lot of features I want/need.
I'd love to give other JVM languages a try but can't afford to go through the growing pains of early releases. Scala has gotten over that major hump at least.
It doesn't. The question was: if you were to learn a new JVM language, what language would you learn first?
I disagree. They picked mostly the easy features like lambdas or null-safety, while they deliberately left out the game-changing features like implicits or type-classes. So Kotlin is just a better Java, with the amount of "betterness" significantly reduced now by Java 8.
While I agree, I also think that some of the less hardcore JVM languages (Kotlin, Ceylon etc) were mainly developed because of how stale Java itself became / is; even Java 8 only adds very basic support and use cases for lambdas, mostly to retain backwards compatibility with existing libraries.
Ceylon and Kotlin grab the low-hanging fruit. They are better Javas. These languages bring nothing new to the table at all. They will actually suffer from Java 8, because Java 8 itself is a better Java like they are. People write Kotlin and Ceylon because they need to write a Java app but they don't want to write Java.
Scala is not meant to be a better Java. It can be used in that way, but it's not meant to be. It has a vastly richer set of features, probably one of the most sophisticated type systems of any language, and a growing number of Scala-specific libraries. In addition to people writing Scala because they don't want to write Java, there exist many people that want to write Scala because of Scala.
The same general argument seems to apply to Clojure. Just because your language runs on the JVM doesn't mean it's just an alternative for Java.
(This is not to say that I don't think Kotlin at least is shaping up to be a beautiful language.)
As to "bringing nothing new to the table at all", I'm not sure about that. It depends on your definition of "nothing" and "something". I think they certainly bring convenience, and their[1] switching costs are orders of magnitude lower compared with Scala's. The question is, then, is the "something new" Scala brings worth the price. Again, the answer to that depends on the user. Some will think it most certainly is; others will find the cost way too high.
[1]: Well, Kotlin's; not Ceylon's
How so? Scala may have more ways for features to interact and I guess a larger library ecosystem to become aware of (though it seems perverse to count a large library ecosystem as a downside), but IME most of the cost of switching is in tooling support and finding a developer community to answer questions - both areas where Scala is far ahead of something like Kotlin.
As a straight and immediate Java replacement, I'd definitely recommend Kotlin as well. If you want to switch over existing Spring apps, you will not get the best out of Scala. Scala, in my experience, is most effective when written without Java goggles on. But Scala definitely has large advantages for new projects or broad refactorings.
I was surprised by how well Scala did in the survey. Except for totally enjoying Martin Odersky's Scala course on Coursera, I personally don't use Scala very much. On the other hand I find Clojure, and to a lesser extent JRuby to be go-to tools for some projects.
I think Java 8 really is the elephant in the room. I started using Java 8 several months before the official release and it has brought some joy back to Java development.
Sometimes I have the impression that some people just repeat stuff they heard on the internet without any actual experience of their own...
For instance, use of MySql with 32% seems too high to me, this, compared to what I've seen around. The main persistence solution of 1 out of 3 of my connections is not MySQL.
The client was a bit harder to use (\x commands are harder to memorize than mysql's "SHOW TABLE" and felt sluggish in a local environment (something that's no longer the case AIUI)).
Replication was a third party addon at the time, and had a reputation for being hairy, though I don't have direct experience.
While this is anecdotal, like you I've find the DBs most of the Java apps I encounter aren't MySQL, but a mix of Postgres, MSSQL and Oracle.
http://db-engines.com/en/ranking
Also, note that MySQL was the only half-way trustworthy free database in the market. The popularity of PostgreSQL has been on the rise only since a few years. So if "free" (as in beer) is what you're after, then MySQL was the only choice for a very long time. Once you build upon MySQL (or any DBMS), you don't switch easily...
Given that RebelLabs is not mainly focused on JRebel users (it's more of a general ZeroTurnaround content marketing platform), the target audience is certainly JRebel-friendly. So yes, the results are biased towards that sort of audience.
What do people think about Gradle as a build tool (versus Maven)?
> In the past, Maven (64%) and Ant + Ivy (16.5%) have been more or less neck and neck. Indeed, we believe that many developers often use both in different ways on complex projects – in 2012, 67% of respondents used Maven and 48% used Ant. [...] Ant with or without Ivy is only one-third as commonplace as it was reported in 2012. The rapid increase of Gradle (11%) is also interesting to witness. Since 2012, Gradle use has more than doubled
The 2014 question was what build tool is used most often, whereas the 2012 figures are for what build tool was used, with some overlap.
So Maven use has stayed high for those using it, whereas Ant users have either given up on it, use Maven more often, or have switched to Gradle (which is still Ant).
I wouldn't trust the download numbers given by the Gradleware CEO, though. The Groovy ecosystem has a long history of fabricating numbers, e.g. look at https://bintray.com/groovy/maven/groovy/view/statistics and see 865,000 downloads of Groovy in the past month, then click on country and see 822,000 of them are from China, and only 17,000 from the US.
Maybe one day Gradle will suck less than Maven, but currently I think they're about the same.
Web applications: 71%
Libs and frameworks: 15%
Desktops: 11%
Mobile: 3%
I'm surprised mobile is so low given that Java is what's used to write Android apps.
The TL;DR version for efficient readers
Java versions – Adoption since 2012 of the newest Java versions has been strong, namely growth in Java SE 7 and Java EE 6…the fact that certain older version of Java SE and EE still command decent minorities is a bit odd, but nothing to fear.
IDEs – Eclipse is a very stable market leader, but increasing favor and interest in IntelliJ IDEA may eventually equalize things.
Alternative JVM languages – Scala is the most interesting, enterprise-ready language on the JVM, and Groovy & Clojure play a great counterpart to the non-Java coding movement.
Build tools – Maven’s dominance is now unquestioned with Ant’s decline from previous years, although fast-growing Gradle is extremely interesting to respondents.
Application servers – Open-source players like Tomcat, JBoss, Jetty and GlassFish dominate both production and development environments, which use the same technology for 81% of respondents, although it’s clear that development-only app servers in the highest favor are Jetty, Tomcat & TomEE.
Web frameworks – A mature and fragmented market, over 1/3 of developers use more than 1 web framework, and here Spring MVC is still king in this area, with stable JSF and growing Vaadin following
Object-relational mapping frameworks – When it comes to ORM, Hibernate takes the cake, although other technologies are available and in common use in parallel.
Code analysis tools – Although nearly 1/3 of developers don’t use these tools (big mistake), the market is rich with complementary technologies like FindBugs, CheckStyle and a platform to bring it all together, SonarQube.
Continuous Integration (CI) servers – Jenkins’ dominance here is stronger than ever, yet 1 in 5 developers still don’t use CI as a practice.
Databases: SQL and NoSQL – The mature SQL is dominated by Oracle, but the market has a good mix of free/open-source and proprietary offerings from long-time players. NoSQL is a maturing segment that is mainly driven by MongoDB.
Version Control Systems (VCS) – Git, supported by the headline-worthy GitHub, is finally reigning supreme over Mercurial as a distributed VCS, and is often used in parallel with the legacy Subversion (SVN).
Repositories – A maturing market that still needs a lot of adoption by developers, the legacy market leader Nexus is losing ground to JFrog’s Artifactory.
Testing frameworks – In this area, complementary technologies work better together rather than competing, with unit testing, mocking and browser testing all highly practiced using strong tools like JUnit, Mockito and Selenium respectively.
Priorities for 2015 – Java 8 (obviously), Continous Delivery / Deployment and Non-Java programming using alternative JVM languages are the 3 top priorities for the next year according to respondents.