The latest expert opinions, articles, and guides for the Java professional.
Welcome to the Java Tools and Technologies Landscape Report 2016. This is a comprehensive report that is focused on analyzing the data about the tools and technologies Java developers use.
There are three main parts to this report and they can be found through the links below:
- Part 1: Looking at the raw data — continue reading this blogpost
- Part 2: Pivoting the data: microservices usage, early vs. late adopters, and so on
- Part 3: Looking at trends and the historical data
Alternatively, you can download a single pdf version of the report and enjoy it all at once:
GET THE PDF NOW
Overall, we received 2040 completed survey responses. This gave us plenty of data with which I’ve been able to heavily improve my Excel knowledge. We also managed to raise $1000 for Devoxx4Kids, a wonderful charity, because we reached our 2000 response target. Great job to all those who took part and answered all of our questions!
If you’re interested in the previous editions of our survey reports, you can find them here:
- Developer Productivity Report 2015: Java Performance Survey Results
- Java Tools and Technologies Landscape for 2014
Java Tools and Technologies Landscape report 2016
Java, the language and the platform, owes much of its fame and longevity to the libraries, frameworks and tools which together make up its ecosystem. No other programming language has been able to match the support that a rich ecosystem like the JVM has achieved. It’s extremely important to understand how the ecosystem exists today, as well as its history. This way we can extract trends and patterns to understand the direction in which we are heading. In fact, all ecosystems are living organisms. They’re born, they grow and become established, live their lives and one day will be replaced by a better, more suitable technology that solves the problem better. Of course the problems we deal with are changing too. Some ecosystems survive in care homes, refusing to pass away, like FORTRAN and COBOL.
This report sets out to understand the current landscape in Java, the JVM and its ecosystem, including JVM languages, application servers, build tools, Java and Java EE adoption, microservices architectures, web frameworks, performance tooling, agile processes and much more. Our goal is to show you the raw data as well as profile which respondents are more likely to prefer certain tech over others based on their organization and other preferences. We’ll also look forward, making predictions based on the data for what the landscape might look like in a couple more years.
The survey itself was open between March and April 2016 and profiled application types, processes, tools and more. Overall we received 2044 responses and we had to eliminate 4 based on their responses to the years of experience question. While it would be amazing to speak to someone who states they have over 10,000 years of experience, we feared the entry could well have been bogus!
Please take the findings in this report at face value, and use at your own risk. If we assume that there are around 9M Java developers in the world the sampling error is around 2.2%. But since the sample is not truly random, it can contain some biases. Although you will see that the respondents description seems quite representative of the industry.
The report is split into 3 sections. The first is a representation of the raw answers given to the survey questions. No fluff, no pivoting, just pure data and answers! Part 2 provides a more in-depth analysis, with pivoting on the data points to understand trends. Pivoting? Wasn’t that a thing in my old physics class with a see-saw, some forces and some kind of formula? Well, maybe. But in this instance, we’re asking more detailed questions about our data, based on the answers given to other questions. For instance, do early adopters that believe they’re better than the average person in their role actually use technologies such as J2EE and Java 1.4? Read on to find out, the results may just surprise you! Part 3 looks at the data we collected in this survey and compares it to previous reports we’ve created — to see trends in adoption for tools and frameworks.
But for now, let’s start at the beginning with Part 1.
Part 1: Raw data
Welcome to the real start of the report! And congratulations for getting past the fluff that precedes the actual fun part. Let’s look at the core results. The raw data. In this section,our headings are the questions that were asked during the survey. There’s only one question that’s missing: “What tool, technology or library are you super excited or proud about having used or planning to use in 2016?”. Don’t worry, we didn’t forget it! We thought that question is better suited to Part 3’s future trends section. So, let’s begin.
How many years of experiencedo you have in software engineering?
This was a question we’ve not asked in past surveys. This year, we wanted to understand more about the type of person who responds to the survey as well as their technology preferences. We actually had a pretty good spread of results as you can see from Figure 1.1. Around half of the respondents exist in the 5-15 years of experience bracket. The overall median is 10 years of experience and the average is 12.2 years.
What is your job description?
This is a common question that we ask every year. Our respondent split was similar to previous years, with the majority being made up of Software Developers (54%), followed by Architects (18%) and Team Leads (12%) as you can see in Figure 1.2. The remaining split was fairly equal across consultants, management, C levels, and Dev advocates. The ‘Other’ category included operations and QA, among others. This was sad as it would have been great to get some of the opinions from operations teams on our microservices questions later. Overall, this spread of roles is what we would expect as the communities are heavily made up of developers and it’s those communities which RebelLabs associates heavily with.
Which description best fits the company you work for?
What kind of person would you say you are?
Many people or companies are opposed to trying something new, considering it wasteful to spend time on a technology that might not even exist in five years time. Or perhaps putting off an upgrade or version migration till they are sure all bugs/issues had been ironed out. This question was therefore designed to understand how likely someone was to try out a new tool or technology. We refer to respondents as early adopters or technology sheep based on their adoption preferences. This question will also be key in understanding which technologies or versions are considered established among respondents and which are still considered new and upcoming.
Figure 1.4 shows that the majority of people claimed they are technology sheep at 53%. A very strong proportion were early adopters with 44%. A mere 3% of people say that change is all bad and that they’d prefer to do real work rather than change. Be sure to check out Part 2 of this report to see which tools and technologies the early adopters are looking at!
Would you say you are better than the average person in your role?
Now for my favorite question in this survey! We asked participants whether or not they thought they were better than the average person in their role. Now, all our RebelLabs readers are likely to be better than average in their role as they’re trying to constantly better themselves by reading technical content. However, it’s always amusing to see the results of possible overconfidence, or maybe arrogance, bubble up? Either way, we’ll see just how good the 74% of people are, those who consider themselves to be better than average, when we study their tools, technologies and behaviours in Part 2. Tell me they use J2EE, please tell me they do!
Which type of application describes the main project you work on?
We’re always keen to get a breakdown of the applications that our respondents work with. As we can see from Figure 1.6, two thirds of respondents work on full stack web applications, as you might expect, with a further 18% working on backend code. The remaining votes are split between batch, mobile and libraries, with 6% working on desktop applications. The ‘other’ option contained middleware developers, tools developers, programming languages and more.
Have you adopted a microservices architecture?
Microservices has been a popular buzzword in recent times, so we felt we had to include a specific question about it in this year’s survey to better understand its adoption rate. This question is fairly simple on the face of it. However, I think that if we sat a few respondents next to each other, they may question whether each other has indeed implemented a microservices architecture or just adopted a couple of best practices. As we can see from Figure 1.7, two thirds of people (66%) have not adopted a microservices architecture whereas the remaining third (34%) have adopted a microservices architecture.
Next, we’ll investigate this in more depth by asking two further questions. To those who have not adopted microservices, we’d like to know whether they plan to in the future. To those who have adopted microservices, does the new architecture make their job easier or harder?
Are you planning to move to a microservices architecture?
For those not using microservices, we asked if they were planning to move to that architecture. Looking at the yellow portion of the outer ring in Figure 1.8, we see just 12% of respondents said yes, they were planning to adopt them. Almost three times that number (32%) stated they did not want to move to a microservices architecture with 56% still making their minds up.
Has moving to a microservice architecture made your job easier or harder?
We asked those who stated they have already adopted a microservices architecture whether it made their job easier or harder. On the green portion of the outer ring in Figure 1.8 we see that almost half of those who responded (42%) stated it made little difference to their job, with 40% saying their jobs became easier and 18% claiming their jobs were harder as a result.
Put in another way, we can say that approximately one in five people (18%) say their job is harder whereas four in five people (82%) state that their job is about the same or easier while using microservices. We could also state that three in five people state their roles are either the same or harder as a result of adopting microservices. Aren’t statistics a wonderful thing! Luckily in this report, we show you all the numbers so you can make up your own minds!
Which JVM language do you use most often?
Very often we get a good spread to this question in our survey, but this year shows
Java in an extremely dominant lead over other JVM languages.
Notice that we didn’t ask which JVM languages people have used, rather which JVM language people use most often. It’s clear that while people flirt with other languages in the ecosystem, Java is still monopolizing the JVM with 93% of the total vote. Groovy and Scala, as you’d expect, are next in line — eating the leftovers from Java’s table with 3% and 2% respectively. Kotlin, Ceylon, Clojure, JRuby and many others all contribute to the remaining 2%.
Which Java version do you use to run your main app in production?
One of the most common questions people ask in the Java community concerns Java version adoption. This is mostly fueled by the exciting release of Java 8 back in March 2014 (I wanted to say recent, but it’s already been over 2 years now!), combined with the aggressive removal of public updates on older versions. It’s important to upgrade for a number of reasons, including performance, security and features. From a library or tooling vendor point of view, it’s incredibly frustrating to support older versions of Java as it’s harder to keep backward compatibility and make use of newer language features.
An important item to note at this point is that we’re asking about the respondent’s main application in production — rather than a proof of concept application running a service nobody really cares about. We can see from Figure 1.9 how conclusive the results are, showing the success of the Java 8 release. 62% of respondents state that Java 8 is used to run their main production applications. 28% of respondents are on Java 7 with less than one in ten using Java 6. The 1% sitting in the other category consist of Java 5 users and some brave Java 9 power users! Needless to say, the success of Java 8 is very apparent in this one image of coffee cups. Now, it’s time to grab an espresso and carry on reading! Next up is Java EE.
Which version (if any) of Java EE do you tend to use most?
See, I told you it’s Java EE next! Now that we’ve covered Java SE, let’s take a look at how life looks in the enterprise world. Java EE 7 was released in June 2013 so it’s no surprise it is the version which most have since migrated up to. Four out of ten respondents don’t use Java EE. If we normalize the data, to only look at Java EE users, we can say 58% of them are on the current version, Java EE 7. It makes me very emotional to see almost one in ten people spending their working lives on a J2EE project, a specification that was released 13 years ago. Maybe we should have a minute’s silence and finish the espresso we made in the last question.
Which IDE do you use most often?
Next up is a real doozy of a question! The eternal battle between good and evil is nothing compared to the IDE flame war! This year marks a very special milestone for this question, as all previous surveys have seen Eclipse take the top spot. This year, even after combining the different Eclipse flavors, such as STS and JBoss tool suite etc, IntelliJ is the number one IDE among Java developers for the first time in our survey. Not only is it number one, but with 46% of the share it beats Eclipse by a clear 5% of the vote! In part 3 we’ll see the trend of previous years to determine whether this result was expected or not. SPOILER: It was!
This will please JetBrains, the company behind IntelliJ IDEA, given the recent controversy over the new subscription based model that JetBrains introduced in 2015 (which is a great model by the way!). It will be interesting to see if they can hold the top spot next time we run the survey! NetBeans still has a solid 10% of the votes with 3% existing in the other category which includes hardcore devs, who use vi, vim, Emacs or a magnet, needle and steady hand, as well as JDeveloper, RAD and TextMate users (we’re looking at you, @venkat_s!).
Which build tool do you use most often?
Another source of much frustration in a developer’s job is their choice of build tool. Of course, unlike IDE choice, build tools are decided by the project rather than the individual developer. You wouldn’t see a team of developers working on the same project using different build tools, which you quite often see with IDEs. The big question this year around build tools is whether Gradle has further eaten away at the Maven monopoly or not. Well, looking at the responses, Maven still has a very strong dominance in the build space with almost seven in ten developers (68%) downloading the internet every day using Maven. The Gradle team will be upset to see such a poor uptake of just 16% of the vote, with Ant just behind on 11%. There’s always one using SBT, and that’s covered in the other category along with the hardcore makefile users. #Respect.
Note that the question here wasn’t multiple choice, so as we’ve seen with other surveys, Gradle is used by many more people, but clearly not as the primary build tool. For more information about this, be sure to check out the trends section in Part 3 of this report.
Which Application Server do you use for your main application?
Application servers — the technology we love to hate! Whether we’re waiting for yet another server restart (Wat! You should be using JRebel! OK, cheap shot!), or fighting with a configuration model that could only have been dreamt up by an alien race, they often take the brunt of our bad language and frustrations. We asked a couple of questions about application server usage; one pertaining to production environments, the other about development preferences. While production environments are designed, in principle, by decision makers, a developer could always opt to use a lighter weight application server in their development environment. This of course brings other challenges, like migration issues between development and production, but for now we’ll just look at what people are actually using.
We can see from Figure 1.13 on the following page that Tomcat is once again the standout leader in application server usage with 42% of respondents using the application server in both development and production. So, almost one in two of those who state they use an application server, pick Tomcat. Everyone else takes the scraps that are left. In fact, Tomcat’s biggest competitor among production applications servers is “We don’t use an application server in production”. That pretty much sums it up. However, I would have expected to see Tomcat’s development percentage to be higher than production as I might have predicted that many using the heavyweight app servers in production would switch to Tomcat for ease of use in their local development environments.
Perhaps Jetty has taken the mantle for this as the second most popular development application server at 12%. In fact, there are 50% more respondents using Jetty in development than production. Where does this additional 50% come from? One possibility is Spring Boot users, picking Jetty as their embedded server of choice. Looking down the graph in Figure 1.13, we see WAS and WebLogic lose the same percentage in development. Almost half of those using WebSphere in production switch application servers in development, which should be very concerning for IBM. A quarter of those using WebLogic in production also switch to a different server in development. WildFly and JBoss EAP share similar numbers as you’d expect with a minor percentage exchange where you’d expect those developing for a JBoss EAP production environment are using WildFly in development. Not really much of a migration as they’re essentially the same codebase. It’s nice to see GlassFish at 4% particularly after they received the cold shoulder treatment from Oracle. Perhaps this server has remained significant due to the support of the team at Payara — great job and community support, folks!
Which databases do you use in production?
This multiple choice question (hint — percentage values won’t add up to 100%) is another we’ve used in the past. Databases are like bugs — every application has them! The question is, which is the most popular? Well, Oracle DB takes first place with 39% of respondents using it, but that’s a mere 1% more than MySQL which sits pretty at 38%. MongoDB, the leading NoSQL provider is used by 15% of respondents in production.
Interestingly, while the majority (56%) use just one database in their production environment, over four in ten respondents (42%) state they use 2 or more databases in production. Only 2% of respondents don’t use any database in production. Not even little bobby tables could derail their applications!
How long does it take you to compile, package and redeploy your application once you’ve made a code change, so that you can actually see your change at runtime? (in minutes)
As the company behind JRebel, a tool that eliminates time spent during compile, package and redeploy stages, we’re always interested in understanding how long it takes for developers to go from changing code in their IDE to seeing their code changes in a live runtime. We typically ask a question about how long a redeploy takes. But a more realistic question is to ask how long it takes a developer to go from making a change in their IDE to seeing their change in their runtime. This includes compilation, build, redeploy or server restart, state creation, including logging back into your app and navigating to the page with your changed code.
We can see varying results from Figure 1.15, and this is because different environmental factors will have contributing factors to this overall number, including application size, application state, build process, application server and so on. The majority sit in the 2-5 minute bracket, which is unacceptable for any developer to suffer through. In fact, over 70% of respondents were 2 minutes or over, with the median being 3 minutes and the mean an incredible 8.7 minutes. 18% of developers, that’s almost one in five, have to wait over 10 minutes to see their code changes in a live runtime. For ideas of how you and your team can eliminate this wasted time and stay sane, visit http://jrebel.com.
Which Web Frameworks do you use?
Another topic that developers love to argue over is web frameworks. Which one is best overall? Which is more suitable for their needs? And even, which they need to learn to be best placed for their next job! Now, before you email in, note that this question could be answered with multiple selections, so numbers won’t add up to 100, number-nerds.
We can clearly see how dominant Spring has remained in 2016, with 43% of respondents stating they use Spring MVC. Spring Boot was also extremely strong (29%), particularly as a technology that was only created in 2014. This must be very pleasing for the teams at
Pivotal. The closest competitor to Spring technologies is JSF at 19%, followed by Vaadin with 13%. Other things to note is the drop-off between Play 2 and Play 1 usage being quite significant, as users clearly choosing to migrate up to Play 2.
Typically, applications use just one web framework. In fact, from our responses, the median number of web frameworks used is 1 with a mean of 1.4. This takes into account all responses, also factoring in all those who said they don’t use web frameworks as well as those who do. If we remove the responses for who don’t use web frameworks (17%), we’re left with 41% of respondents who use one web framework and 42% of respondents who use two or more web frameworks. Therefore, if you’re going to take advantage of web frameworks, you’ll likely end up using more than just one in your application.
Which Continuous Integration Server do you use?
As one might expect from a survey that asks which CI servers people use, Jenkins is the runaway winner. The 10-year-old CI server is used by almost two in every three (60%) respondents. The biggest competition by votes is ironically the “We don’t do CI” category, which makes Jenkins’ dominance even more impressive. Bamboo is the next most popular CI server with 9% of the votes, with TeamCity, Hudson and Travis CI taking up the rest of the share. In the ‘other’ category, Circle CI is certainly a server worth mentioning that had a good portion of the remaining votes.
Before we go, we should mention Hudson, the CI server from which Jenkins was forked back in 2011, with overwhelming support from the community. Note that Hudson was transferred from Oracle to the Eclipse foundation in 2012. Since Jenkins owns the market in the CI space and with 20 (twenty) times the number of users (using our sample data) compared to Hudson, it’s a mystery why Hudson is still being developed or supported today. The game has long been won by Jenkins and perhaps it’s time to unplug Hudson altogether.
Which VCS do you use most often?
It’s time for you to cast your eyes upon another technology monopoly! This time, we’re talking about VCS tools. Needless to say, saving our files in a directory using a format like: [filname]_[version] is the most popular solution… Oh no, that’s incorrect! Git is actually the most popular solution, and by a wide margin! Almost 7 in 10 respondents state they use Git most often, seeing the infamous subversion (SVN) fall back quite a distance behind on 23%. Mercurial and CVS deserve having their names mentioned, taking 3% and 2% of the vote respectively, with many more tools being collected in the ‘other’ category.
If anyone was in doubt or asking which VCS system won the fight, you’re a bit late to the party. Git is most definitely the last VCS standing!
Which Java Profilers do you use?
VisualVM tops this category with 38% of the votes, but sadly 35% of respondents claim they don’t use profilers at all. This is unfortunately a typical representation of how performance testing takes a back seat, particularly with developers. Years ago, the same could be said about quality testing during development time.
With the introduction of developer focused profilers like XRebel, with 6% of the votes, we see a glimmer of hope for early application profiling that can be performed as developers write their code.
JProfiler is another popular profiler, shown by the 16% share it got from respondents. It’s very pleasing to see 15% of respondents using Java Mission Control. As a tool that’s provided with the Oracle JDK and is free for use by developers on non-production data, it’s a key tool to have in any performance tester’s utility belt. YourKit and NetBeans profiler also perform well with 12% and 7% of the votes respectively.
Which APMs do you use?
Hang on, APMs? That’s not a development thing — perhaps that’s why almost one in three respondents had no clue which APMs are used to monitor their applications. This is even worse considering 47% of respondents state they don’t use APMs, or perhaps they do but just don’t know that they do! As a result, the most popular APM at just 11% of the votes is New Relic. In fact, it’s more than twice as popular as the next APM, AppDynamics, with DynaTrace following closely behind with 4%.
Which Virtualization Environments and tools do you use?
As you would expect, the Docker hype manifests itself into the highest share in our survey among people who use virtualization environments, taking 32% of the votes. AWS ECS lags behind on 13% and there are few others posing any kind of competition beyond this. Interestingly, only 4% state they use Kubernetes, which is surprising given the amount of great press and conference sessions it gets. Perhaps we’ll see increased adoption over the coming years. Virtualization is still a practice performed by the minority, with 54% of respondents stating they don’t use virtualization environments at all. I expect this will switch in the near future, particularly if Docker’s strong growth continues.
Is your team agile?
The agile party mark a landslide victory, with 71% of respondents stating their teams are agile. This doesn’t mean they are agile, of course. Rather, it means it’s the individual’s belief their team works in an agile way. Next, we’ll look at which practices our respondents follow, and be sure to check out Part 2 when we break it down further to see which practices our agile developers follow! The results are popcorn worthy.
Do you practice the following processes?
With only 4% of respondents working in a certified agile team, this likely says more about the number of teams who care about being certified agile than the practices most teams follow. One might argue that what works for one team is very different to another, so working in a prescribed way could be counter-intuitive for a team. Almost two in three respondents (59%) have daily standups — which is reasonable — with almost half of respondents (47%) using Kanban boards to manage their tasks. One in five of our respondents (20%) don’t care too much for any of these practices, stating they don’t follow any of them whatsoever. 39% of respondents state they assign tasks to their team at the beginning of a sprint which I would have expected to have been higher, given it’s a core part of agility. Only one in five respondents (19%) claim they have well written specifications for their projects, so not much love for documentation there.
Does your project have formal requirements for the following areas?
Almost two in three respondents have formal functional requirements in their project, which used to be an anti-pattern of agile that encouraged people to ignore documentation altogether. I think this is a pretty outdated view of what it means to be agile and this is backed up with almost two thirds of respondents producing formal documentation. We can see everything else takes a lower priority to function, with security, rather surprisingly, next most popular with one in three stating they have formal requirements in place for their project. Performance is next with 29% of people caring enough to enforce formal requirements for their application. The same number (29%) don’t care about any of these formalities, claiming they do not have formal requirements for any of these areas.
Are you (or your company) likely to pay for development tooling?
Good tooling invariably comes at a cost. It’s important for companies to understand that and empower their developers with the right tools they need to do the job. You wouldn’t expect a chef or a builder or in fact any trade to do a job without giving them the right tools to accomplish that task well, but for some reason in software development it’s often accepted. First, let’s spend a minute thinking about the poor one in every ten developers (11%) whose company will plain not pay for any tooling whatsoever. Done that? Good. It’s good to see the remaining nine out of ten respondents at least standing a chance of purchasing the tools they need. In fact, 6% of them will pretty much buy anything, while the vast majority, four out of five, will be able to purchase tools if they are essential or if their value can be proved.
In this blogpost we focused on the first part of our Java Tools and Technologies Landscape Report. And we just described the raw answers we got from the survey. No fluff, no pivoting, just pure data and answers. You can draw your conclusions already, the IntelliJ IDEA has overcome Eclipse in popularity, Maven is still the king, Git has won. People don’t really understand agile and so on.
However, this is not the end! We’ve done more data analysis and it awaits you in the second and third parts of the report.
- Part 2 provides a more in-depth analysis, with pivoting on the data points to understand trends.
- Part 3 looks at the trends and compares it to the findings from previous reports we’ve created — to see trends in adoption for tools and frameworks.
And be sure to grab the pdf version of the report. It’s beautiful, it’s easier to read, we’ve put quite an effort into it! Check it out:
Agreed, I need to check out the pdf version of the report