Perforce, provider of Java tools JRebel and XRebel, recently announced the results of its 9th annual global Java developer productivity report, based on a survey of over 850 Java developers. Topics covered include the nature of Java teams, challenges they experience, preferred tools, and success of said tools and technologies. The key finding shows that despite increasing use of microservices, developers are still facing long redeploy times and interservice functionality issues.
SEE ALSO: Java is immortal and feels good: 2020 results and 2021 trends
About the Respondents
The survey found 49% of respondents were Java developers, with the rest split across team lead, architects, and consultants. 6% were director, vice-president or C-Level. It was good to hear that everyone who responded is in work, with just over a third (36%) in an enterprise (larger) organisation, 42% in small or medium-sized companies, and 15% in start-ups. The majority work in small teams, which is indicative of both a growing desire for more agile development and adoption of microservices, where developers work with smaller segments of code. 40% of teams are between 3-9 people, 24% 10-20, and 17% 20-50 people.
Java and microservices trends
As expected, 69% of respondents are still using Java 8, followed by JavaScript at 40%, and Java 11 at 36% (note that they were allowed to select more than one programming language of choice). Only 16% say they are using Java 12 or newer, and 15% are currently sticking with Java 7 or older.
Adoption of microservices stays steady, with 66% of respondents either actively transitioning to or currently using microservices. Only 13% of respondents are not planning to transition at all. Developers were also asked how many microservices they had in their primary applications, on a scale of 1 to 20. The answers were 36% using 5-10 and 34% using 1-5, followed by 16% with 20 or more and 14% with 10-20. Of course, organisations can have more than one application architecture, for instance: monolith is still used by 42%, SOA by 29%, mobile by 23%, and desktop by 18%.
Most Popular Tools
The report surveyed respondents on their most used technologies and tools in each category:
- Application servers – Tomcat still dominates at 66%. Then there is a relatively even spread between JBoss/WildFly (19%), WebLogic (18%), Jetty (15%) and WebSphere (14%).
- Application framework – Spring Boot takes the top slot at 62%, a decrease from last year’s 83%. Users of DropWizard sit at 8% (an increase from 2020’s 1%); likewise Quarkus adoption grew from 1% to 6%.
- Framework configuration – Annotations is the outright leader at 75%, while 22% configure with code added to methods that run during initialisation.
- IDEs – IntelliJ IDEA comes in at number one with 65%, followed by Eclipse (48%), VSCode (27%), and NetBeans (13%).
- JRE/JDK distribution – Use of Oracle JDK went up — 59% compared to 50% last year — despite reports of people moving away from it due to licensing costs. This could be attributable to the amount of larger enterprises who responded to the survey, as they often find transition harder than smaller organisations. In second place is AdoptOpenJDK at 22% and a further 10% report using Amazon Corretto.
- Databases – The most favoured is MySQL at 43%, then Oracle DB and PostreSQL sharing second place at 36% each. Next up was MongoDB, with 29% of respondents.
- Build tools – Maven is the top tool of choice at 67%, whereas last year, Maven and Gradle were pretty much neck-and-neck.
- Virtualisation tools – 88% say they use these tools, with far and away the most common one being Docker at 57%, down from 74% last year. Kubernetes is the runner-up at 42%, a step up from 35% 12 months ago. VMWare sneaks in at third place with 27% (again, an increase compared to 2020).
- CI/CD – Jenkins stood out with 61% of respondents using it, with others (Bamboo, TravisCI, TeamCity and others) at 12% or less.
- PaaS – Most respondents are now using a PaaS provider, with only 24% saying that they don’t. For those who use a PaaS provider, AWS was the top choice at 39%. Microsoft Azure follows with 24% and Google Cloud with 18%.
SEE ALSO: What is Garbage collection log, Thread dump, Heap dump?
Developer Pain Points and Challenges
The biggest application performance issue cited was long application response times at 54% (which is on a par with last year’s 55%). This continuing trend aligns with growing microservices adoption. The next highest performance issues reported were high CPU usage (39%), and memory leaks (35%), with excessive open connections and IO queries coming in at 26% and 19%, respectively.
Deployment times are a common area of grievance. 59% of developers experience redeploy times over four minutes, and 20% experience redeploy times longer than 10 minutes. There are two potential reasons behind this. One is that when microservices grow in size, it takes longer to develop and create applications. The second reason is due to microservices running on remote virtualization machines.
Specific to microservices, troubleshooting inter-service functionality was the biggest reported challenge at 30%, followed by problems with setting up the development environment locally (24%). This can be attributed to the difficulties of creating a complex microservice application. In joint third place at 14% each are the challenges of troubleshooting inter-service performance issues and scaling and monitoring in production.
Finally, developers were asked how they would spend extra time during the workday should their challenges be mitigated. A quarter of respondents said they would focus on improving test coverage, followed by improving application performance (21%). 19% say they would add new features and 15% would spend those extra minutes improving the development process. 12% would speed up their release cadence, 12% would bring forward launch dates, and 8% would start a new project. Let’s hope that by this time next year, they have the luxury of at least a bit more time to achieve those goals.
The post The state of Java software development in 2021 appeared first on JAXenter.
Source : JAXenter