image blog java tools and technologies landscape 2016
July 14, 2016

Landscape Report 2016: Java Development Data

Java Tools

Welcome to the Java Tools and Technologies Landscape Report 2016. This is a comprehensive report that is focused on analyzing Java development data specifically 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:

Looking for the latest info on Java technologies? Download our 2021 Java Developer Productivity Report.

Download Free Java Technology Report

Part 2: Pivoting the Data

We’ll start by looking at the differences in behavior between those who think they’re early adopters of technology (you know the ones without any money because they just bought a new Apple iPhone 8S plus, with 5GB of memory and a 50MP camera, running on iOS 10), versus those who are technology sheep. After that, we’ll analyze trends among those who are using a microservices architecture to see which tools and technologies they’re using. We’ll also see if those who call themselves agile are indeed agile. First, let’s look at when people adopt different technologies.

Early Adopters versus Technology Sheep

illustration of a sheep and a wolf (early adoptor) This is a really interesting comparison as it tells us a lot about the state of a particular technology. For example, if we see a lot of early adopters looking at a technology, we might assume that it’s an up and coming technology that people are beginning to adopt. Or perhaps we can look at how people are adopting versions. If technology sheep are adopting the latest version, we might assume the latest version is well established.

Do early adopters think they’re better?

Put frankly, yes, yes they do. Eight in ten early adopters (79%) think they’re better than the average in their role, whereas seven in ten (70%) technology sheep think they’re better than average in their role. image showing what percentage of early adoptors and sheep think they are better than average in their role Therefore, you’re more likely to think you’re better than the average person in your role if you’re an early adopter of technology. This doesn’t mean they are, of course, but the mindset is quite different. In Figure 2.1, we see the technology sheep and umm, early adopter wolf. Well we had to pick an animal and the wolf seemed the most opposite to a sheep!

Are early adopters more experienced?

One might think that you could consider adopting a technology early if you possess the experience to know which technologies were right to adopt, both in terms of the technology and timing. Another train of thought could be to wait for new technologies to survive the early hype period and only adopting once it is an established technology. This could potentially save a lot of wasted time on a technology that might not make the cut. graph showing percentage of early adopters vs sheep by years of experience Looking at the graph in Figure 2.2, we see fewer early adopters than technology sheep around the 0-14 years bands and more early adopters with 15+ years of experience. In fact, the mean average shows a difference of almost two years, between early adopters and technology sheep, at 12.8 years and 11.0 years experience respectively. The median average also shows a two year difference, with early adopters having a median 12 years of experience and technology sheep having a median 10 years of experience.

Java SE Version Adoption

As one might expect, an early adopter… Well, adopts stuff early, and this should be apparent if we were to look at the versions that early adopters use. Figure 2.3 shows just this, with two in three early adopters (67%) using the current Java 8 version. Almost one in four early adopters (24%) are on Java 7 and 8% of our so-called “early adopters” are using Java 6 or older. When we look at the technology sheep, we see more of them using the older versions of Java, but reassuringly the Java 8 adoption is still very high, at 58%. This is significant because technology sheep adopting a new version would suggest maturity and stability in that version. It might suggest the path has been well walked by others and it’s a proven working, viable version. graph showing percentage of early adopters vs sheep by java version The wily among you will notice that each line only adds up to 99%. Well done! 1% of early adopters already use Java 9 early access builds. That’s pretty impressive! 1% of technology sheep don’t use Java at all.

Java EE Version Adoption

graph showing percentage of early adopters vs sheep by JavaEE version When we look at the results for Java EE adoption we see something quite different. In fact, we see the opposite to that which we just saw in our Java SE adoption. For both early adopters and technology sheep we do still see the latest Java EE version to be the most popular among Java EE users. However, when we compare the two sets of results, we see unusual results. A higher proportion of technology sheep are on the latest version of Java EE compared to early adopters. But that doesn’t make sense. Surely early adopters should be the first to use the latest version. Well, actually when we look at the numbers for those who do not use Java EE, we notice 46% of early adopters don’t use Java EE, compared to 38% of technology sheep. This means that early adopters are migrating away from the Java EE platform, which isn’t the kind of news that the Java EE community want to hear. Amusingly, almost one in ten (8%) “early adopters” still use J2EE.

Web Frameworks

Now let’s check out what percentage of early adopters use particular web frameworks compared to technology sheep. This will allow us to work out which frameworks are gaining adoption, which are established and which are on the way out. The early adopter/technology sheep split across all respondents is 45:55. Figure 2.5 shows this ratio as a gray line so that we can see when results are significant. chart of web frameworks usage by early adopters vs sheep Let’s first focus on those web frameworks that are close to the 45:55 average ratio. Those that are just below this average ratio (have fewer early adopters to technology sheep than average) are Spring MVC, JSF, GWT, Vaadin and Struts 2. Dropwizard sits bang on the 45:55 ratio line. Those web frameworks that are further away from the average ratio, and perhaps statistically more important, include Spring Boot, Play 2 and Grails which all have a higher proportion of early adopters than average. These can be considered upcoming technologies. Certainly this could be argued with Spring Boot which has seen a lot of uptake over the last couple of years. Conversely, Play 1, Struts 1 and Wicket are three technologies which have a higher than average proportion of technology sheep. This suggests that these frameworks are on the decline, which looking at the list, is arguably the case.


Let’s fan the IDE flame war by introducing the early adopter angle! Once again we’ll add the average ratio line of 45:55 in Figure 2.6 to show the overall average proportion of early adopters to technology sheep. In fact, only one IDE has fewer early adopters than the average. chart showing IDE use by adopter type It’s quite significantly lower with only 36% of Eclipse users (just over one in three) being early adopters. We see that both IntelliJ and NetBeans have more than the average number of early adopters with 50% and 49% respectively. Our uber-dev overlords run away with the highest proportion of early adopters — we bow down to your greatness, uber-devs. We’ll take a look at how IDE usage trends have changed over the years and perhaps make sense of this number. If early adopters are moving away from Eclipse, one might wager the technology sheep could later follow.


pie charts showing microservices usage by adopter type Some might say a microservices architecture is a new paradigm or pattern. Others might say it’s just a name for the practices they already follow. Regardless of the hype, we see that almost four in ten (39%) early adopters are using a microservices architecture, depicted by our early adopter wolf, shown in Figure 2.7! Technology sheep on the other hand are slightly less emphatic with their adoption, although with a little over three out of ten technology sheep using microservices, we can assume they’re becoming an established viable alternative. Next, we'll pivot based on whether respondents have adopted a microservices architecture or not. Which application servers, databases and tools are more likely used in a microservices environment? Read on to find out!

Pivoting by Microservices

Next, we’ll dig through our survey responses and pivot on the question that asks if people are currently using a microservices environment. In this section we’ll cover application servers, databases, web frameworks and the virtualization tools that respondents who use microservices are using. We’ll also check out which roles in an organization find a microservices architecture easier and which find it harder. So we’ll start this section with application servers. To adopt a microservices architecture, it’s clear that our applications need to be designed in such a way that they can interact with each other in a modular way. But do those who adopt a microservices architecture favor a particular application server, database, web framework or virtualization tool? Let’s find out!

Application servers

We’d expect the most lightweight servers to be used for environments that use microservices, and the results don’t live up to our expectations. Those using a microservices architecture are twice as likely to use Jetty as those who haven’t adopted microservices. Tomcat is also used more in microservices architectures, but while the absolute percentage increases by 6%, the same as Tomcat, it’s relatively a much smaller increase for an application server that has 40% of the market among the more traditional environments. bar graph showing app server usage by microservices adoption So why does Jetty take such a big slice of the pie when it comes to microservices? Two words: Spring Boot. A framework that’s quickly becoming one of the favorites among users of microservices. Spring Boot will embed a Jetty or Tomcat server into the war file that it creates. WildFly, JBoss EAP, WebLogic, WebSphere and GlassFish they make up 38% of the users who are not using microservices (amusingly still less than Tomcat!). If we look at the usage of the same group of servers that are used by respondents that are using microservices, we see the share slashed down to 23%. WebLogic takes the most significant damage, more than halving in its usage in a microservices architecture, from 9% to 4%.


bar graph showing database usage by microservices adoption Everyone has data! I don’t care whether you’re using monoliths, megaservices, microservices or nanoservices. You’re going to have data. You are also going to need some place to store it! The question is, if you pick a microservices architecture, are you more likely to pick certain databases over others? SPOILER — Yes, yes you are! Check out the results on the next page for the full results.

In fact, PostgreSQL, MongoDB, Redis, Cassandra increase most significantly! PostgreSQL usage increases from 25% up to 36%, and MongoDB sees an even bigger increase from 10% up to 24%. Redis and Cassandra show us something subtly different. We see databases that don’t have a large share among respondents who don’t use microservices excelling in the microservice environment. Redis increases from 5% to 16%, over three times its non-microservices share. Cassandra increases from 2% up to 12%, six times its non-microservices share.

Neo4J and Couchbase also show strong signs of relative increased usage in microservices environments, although their lower market share means the absolute percentage increase is smaller than the other vendors. Oracle, the market leading database offering is one of the few that sees a reduction in usage among microservice users. In fact, the 8% reduction is a significant one, as on 34% it makes Oracle DB to the 3rd most popular database used in the microservices environment. Weirdly, IBM’s DB2 which you would imagine would suffer the same fate, increases its share among microservice users from 6% to 8%.

Web Frameworks

graph showing web frameworks usage based on microservices adoption You only need to glance at Figure 2.10, to spot the two most popular web frameworks that are used by microservices. These are Spring MVC and Spring Boot with 52% and 48% of respondents all jumping for joy stating they use them. So almost one in two microservice-y people are using Spring Boot already, and it’s only been available for a little over two years! Not just that, but Spring Boot is four times more popular than any other non-Spring technology (JSF) for microservices users. Play 2, another technology which is being heavily used by microservice architectures, increases its share to 7% from the 3% share it had from non-microservice users. This shouldn’t be too much as a shock, given the part it plays as part of LightBend’s new microservices offering, Lagom. Some frameworks have shown a reduction in popularity among microservice users, none more so than JSF that saw a reduction in usage from 22% of non-microservice users to just 12% of microservice users. GWT, Vaadin and Struts also show a reduction in usage.

Virtualization tools

One technology that you might expect to grow at a similar rate to (if not faster than) microservices is virtualization, Docker in particular. We can see that one in two (50%) microservices architectures use Docker in their environments, compared to just over one in five (22%) non-microservice users. bar graph showing vitualization tool usage based on microservices adoption I mentioned that the lack of Kubernetes usage surprised me in Part 1, and we can see a Kubernetes usage increase in microservice environments by approximately four times compared to more traditional environments. Just one in three respondents (35%) have adopted a microservices environment but do not use a virtualization tool whatsoever. Compare this to 64% of respondents that have not adopted a microservices architecture who state they do not use a virtualization tool.

Are microservices easier, by role?

The final pivot we will perform is to understand which roles become harder or easier when they work with microservices. To make the data easier to read, we’ve compressed the “much easier” and “easier” options to just one “easier” option, and the same with the “harder” options. We’ve also split the roles up so that you can see the difference between the technical and non-technical roles. bar graph of who finds microservices make job easier by role There’s a clear bias towards people finding microservice architectures easier to work in, however, it’s not that clear cut. For instance, if we assign numbers to the the much easier — much harder scale from 1 to 5 respectively (“About the Same” being 3), the mean average ranges from 2.5 to 2.8, which would round up to “About the Same”. The median across all roles would always be 3, or “About the Same”.

Non-technical roles are less likely than techies to say their job is harder as a result of adopting microservices, but do disagree when it comes down to whether their jobs are easier as a result of microservices. Well, guess what, it’s the Directors, VPs and C levels that ultimately make the decisions! All techies largely follow a similar trend with around one in five finding that microservices has made their job harder and the remainder are evenly split as to whether their job is easier or around the same.


Those of us who have been agile for years and years won’t consider being part of an agile team to be new or amazing. But there are people who do, whether that’s by choice or because the team they work with hate change so much, they even wear the same clothes to work each day. Irrespective of the reasons, we can certainly look deeper into the practices and processes which teams use to understand what people are actually doing, as well as whether they label it agile or not.

Company Type

bar graph of repsondents who consider themselves agile by company type First of all, we can see which companies house the most agile or um… Whatever the opposite of agile is. Unagile? Maybe waterfall-esque? We can see in Figure 2.13 that the lowest proportion of agile teams exists in enterprise companies, with 68% of enterprise respondents claiming they’re agile. This isn’t that bad actually, considering small and midsized companies are nearby, on 72% and 71%, respectively. As you might expect, startups are the most agile, with just over eight in ten claiming they’re agile.

Agile processes

We can now split the question which asked about the processes people follow into two groups. Responses from those who claim to be agile, and those to claim they are not agile. As you can see in Figure 2.14, we have a high percentage of people who claim to be agile having daily standups. Of course, standups aren’t for everyone, so it’s not surprising to see only seven out of ten (71%) respondents doing this. Naturally, you don’t have to be agile to have a standup, so three out of ten (31%) non-agile respondents also have daily standups. bar graph of process usage by agility type The use of Kanban boards is adopted by 57% of respondents stating they’re agile, with just 22% of those not claiming to be agile using Kanban boards. Assigning tasks at the beginning of sprints, or at least development cycles is more popular among agile teams However, one might expect the adoption of this practice to be higher than 45% among agile teams. If we try being more specific the figures start to get interesting.

When we look at well written specifications, a task you wouldn’t traditionally associate with agile development at all (although times have changed now and many agile teams do see this as an acceptable practice), we can see that almost one in five respondents of both agile and non-agile teams create these docs. The data also shows us that 13% of agile respondents only perform standups and don’t use Kanban or assign tasks at the start of sprints. OK, there’s more to agile than just those tasks, but I think there are many groups that do believe they’re agile just because they stand up and chat about kittens each morning. bar braph of formal specification usage by agility type Those who consider themselves to be agile are more likely to write functional, security, performance, UX and monitoring specifications than those who do not consider themselves ato be agile. Traditionally this data would have been considered terrible agile practice. People who documented anything in an agile team used to be sacrificed to the agile gods in a futile act to keep them happy. However, it shows how much times have changed — when we can see that the most likely people that create these formal documents are now themselves claiming to be agile. We’re not just talking about a single type of formal document here: we’re talking about a clean sweep across the board with every doc type.

Do agile teams think they’re better?

pie charts of who thinks they are better than average by agility type The final question in part 2 is, are people in agile teams more likely to think they’re better than people in waterfall-y teams? Simply put, yes they do! The difference isn’t just one or two percent of people, it’s actually almost one in ten people! 76% of respondents claiming to be agile believe they’re better than the average person in their role, compared to 68% of non-agile respondents.

Checkpoint 2

In this post we focused on the second part of our Java Tools and Technologies Landscape Report. We've compared the data of the developers who use microservices and don't, who think of themselves more as early adopters vs. technology sheep, different team agilities, and so on. Luckily, this is not the end, we've done more data analysis on the historic trends of previous years. We've taken data from the 2012 and 2014 Rebellabs Productivity reports to see how the answers you've given us change. Below you can find the links to the other parts of the report.

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:


Download the Report