Attention Web Developers: Java is Still Going Strong

Java, together with its associated framework ecosystem, has been experiencing a steady loss of its “cool factor” in the web development community of late. By contrast, the dynamically-typed languages, such as Python and Ruby, are trending upward in popularity. In this article, I’ll examine if this loss of interest in Java is justified by breaking down the technical and business perspectives of the language with comparison to Python and Ruby.

To get to the bottom of this, we’ll analyze how Java is architecturally inclined towards scalability and how it outperforms both Python and Ruby in benchmarks. We’ll also explore what made Twitter decide to switch from Ruby to Java and look into a market segment where it has a strong presence. Then we’ll look at the factors that can cause differences in time-to-market when using Java versus dynamic languages. The final aspects we’ll assess are hiring, from a remote-working perspective, and financial considerations.

The Technical Perspective (Speed & Multithreading)

Architectural Differences in Python Versus Java

Python is an interpreted, dynamic language and Java is a compiled, static language. Throughout this article, we’ll be referring to the default (reference) implementation of both Python and Java. While Java’s JVM takes a bit longer to get going due to its warm-up phase, the Python runtime is faster at starting up. But this is where Python’s advantages in terms of pure execution performance stop.

Python interprets all code at runtime, and, even though it does translate code to bytecode, the fact that it does so at runtime means that there’s not much optimization going on. This is in contrast with Java, where code is translated to bytecode at compilation time and then executed inside a JVM. Yes, there are Python implementations that can compile bytecode before runtime, but this negates the whole point of the reference implementation of Python: using this means that you start going towards Java and introduce a slower startup time, which essentially negates one of the advantages of using Python in the first place.

At an abstract level, there are multiple ways to achieve parallelism, and multithreading is one of the most popular choices. Python lacks true multithreading support because of its Global Interpreter Lock: this prevents multiple threads from executing in the same interpreter. Java, on the other hand, offers out-of-the-box support for multithreading via its standard API, which can be further enhanced by its many existing frameworks.

The fact that Java translates code into bytecode when it is compiled rather than when it is run helps make it faster than Python. This is combined with Java’s multithreading-oriented design, which is in contrast with Python’s single execution thread model. Of course, whether multithreading is the best solution for your parallelism requirements depends on the context. Sometimes, a multi-process setup might be better, or even a single-threaded model. However, if you do need to make use of multithreading (which is often the case), Java is the clear winner.

Java Versus Python Benchmarking

It’s difficult to say what benchmark mechanism is most appropriate to use without having the context in which a given web application will operate. Given the broader focus of this article, the best we can do is to analyze as many benchmarks as possible and to ensure that the comparison is fair by always comparing the results of the same benchmark for each language. Fortunately, such analysis has already been carried out and we have extensive data as part of The Computer Language Benchmark Game. In general, the main reason for benchmarking is execution time, and Java is a clear winner on this category in each of the benchmarks provided.

Case Study: Twitter’s move from Ruby to Java

In 2012, Twitter was able to withstand the record traffic generated by the US Presidential election thanks to its move from Ruby to Java, a process which was started in 2008. Twitter quoted Ruby’s inability to deal with long-running and memory-intensive processes as primary reasons for the shift. However, the fact that Twitter moved to Java doesn’t mean that Ruby on Rails doesn’t have its place. On the contrary, when starting out, like most startups, they needed something that would give them the best return in terms of speed to market for each hour of development time. And Ruby, much like other dynamic languages used for web development, was great for that. But things changed, and as the platform grew, being able to handle operations at scale became more important. Their move to Java + Scala happened in order to resolve this, and very few of Twitter’s services still run on Ruby.

Market Study: Java still rules the enterprise financial world

An analysis carried out by eFinancialCareers on the number of job ads published by American and British banks shows that Java is still the most heavily used language in the enterprise financial world. This includes banking institutions, insurers, stock markets, and other types of financial firms.

Interestingly, Python is the language that showed the greatest jump in demand year-on-year within this study. This is partially due to it being more accessible than Java to people who aren’t primarily software developers. In particular, Python’s rich machine learning ecosystem of libraries means that it’s increasingly used in the enterprise financial world by people who are involved with financial analysis and modeling but who aren’t technical. This also drives up Python’s overall usage because there are clear advantages if both technical and non-technical staff are able to use the same language. Although Python is increasing its financial enterprise market share, Java is still the clear leader.

The time-to-market perspective

The claim that we are going to assess in this section is that the time-to-market is reduced when using a dynamic language for a web app compared to using Java. This consideration is especially relevant to startups who are often cash and time-constrained, relative to established enterprises. The supporters often cite Java’s verbose boilerplate code and a dauntingly large framework ecosystem as their justification for this claim. In the upcoming two subsections, we’ll first create a few API endpoints using Spring MVC, and then show how Ruby saves you the trouble of doing so.

Let’s Create Two Sample Endpoints Using Java’s Spring MVC

Using the Spring Initalizr at https://start.spring.io/, generating a skeleton project takes just a couple of seconds, and then you’ll just need to import it into your IDE. You will have your web app server running in just a couple of minutes.

The following code snippet defines a REST controller that creates your first web server endpoint.

@RestController
public class MyFirstController {

    @RequestMapping("/greeting")
    public String helloWorld() {
        return "Hello";
    }
}
Java

The following code snippet defines a web controller and serves the ‘greeting’ view, after rendering it using the Thymeleaf engine on the server side.

@Controller
public class MySecondController {

    @GetMapping("/hi")
    public String greeting(@RequestParam(name="name", required=true, defaultValue="you") String name, Model model) {
        model.addAttribute("name", name);
        return "greeting";
    }
}
Java

Let’s See How Ruby Does it Automatically

This is where Ruby shines. While the above Java sample project is light and easy to understand, the point is that Ruby will allow you to get much more done with pretty much the same effort. And this is what comparing time-to-market results is all about. Even though Rails might not be as easy to set up as Spring, once you do so and use its scaffolding mechanism, you’ll start seeing some real results. Running the following command will automatically generate simple models, views, and controllers, for a single table (entity), in a CRUD fashion:

rails g scaffold helloApp greetingMessage:string
Ruby

A Rich Java framework/Library Ecosystem Can Sometimes be a Disadvantage

One advantage that comes with choosing Java is the abundance of libraries and frameworks. The following two Wikipedia tables summarize this very well relating to web development:

The same is true for the object-relational mapping space for:

While having options is great, there’s an argument to be made that having too many options is a factor that can contribute to a slower time-to-market, depending on the context of the firm or team. Spending too much time on achieving consensus on what to use for what parts of the system, or attempting to bulletproof for the future by optimizing such choices are two common anti-patterns that can drive time-to-market up. Additionally, when there are fewer options in an ecosystem, it is more likely that all developers in that ecosystem will know and use the same tools, which means faster onboarding for new team members who don’t need to learn new things for each different project. Despite this, many organizations may consider “too many options” to be a good problem to have.

The Hiring Perspective

Remote Work

If you’re looking to build a team on a fully-remote basis, the decision to use Java, Python or another language can be influenced by the fundamental supply and demand laws of the remote talent marketplace. For this section of the discussion, I’ll share data related to the actual programming language, rather than the specific framework used to carry out web development within that language.

A Java developer with knowledge of Spring will probably find it easy to build a web app using DropWizard instead. Same for Django vs. Flask in the Python context. There’s also the fact that each language is not only used for web development, which is less true for Ruby than it is for others. Applying both of these rules consistently to each language keeps our comparison as fair as possible, though.

We’ll start by looking at remote job posts on Indeed.com in the United States:

Now let’s take a look at postings on Stack Overflow:

The job posting data shows that there are plenty of companies looking to hire both Java and Python developers, as well as Ruby, including remote positions.

 

When looking at things from a supply side, Scalable Path’s developer profile data shows an abundance of Java and Python developers, followed by an expectedly smaller presence for Ruby. This helps us debunk the myth that the availability of Java developers is low (due to its enterprise reputation), making them a struggle to hire remotely. Together with the job posting data, it appears there is a supply and demand equilibrium, suggesting that this consideration shouldn’t play a strong role in your technology choice.

The Financial Perspective

The geographical area chosen for this analysis is the United States, due to the large availability of data. Python and Ruby command higher salaries in each of the sources, but not by a large margin. This means that the purely financial perspective shouldn’t influence which language chosen for building a new web app, especially when considering the averages. The data is also explained by the findings in the ‘Remote Work’ section above; when there are more companies looking for Python developers rather than Java developers, it can result in some higher salaries for certain markets:

 

*In contrast with the ‘Remote Work’ section, we’re looking at Ruby on Rails developers, rather than generic Ruby developers. This is because the financial side of things is more sensitive to this subtle distinction than the overall job availability one.

 

Popularity of Languages

In the 2019 Stack Overflow Developer Survey, the popularity ranking metrics put Python and Java next to each other, with Python just surpassing Java this year for the first time. Ruby is quite some distance below. Python is the fastest-growing programming language today. At the time of writing this article, the PYPL ranking places Python on its first position and Java second, at a considerable 10% distance, while Ruby is much further down. Comparatively, the TIOBE index places Java first, but with a year-on-year decline, and Python third, but with a year-on-year increase. Ruby is very far below. It’s likely that it’s only a matter of time until Python surpasses Java in the TIOBE index, too. A couple of conclusions can be drawn from this:

The first is that Java is still popular, but Python has surpassed it in two out of three indexes, and will probably do so in the third one too. The pool of Python developers is, therefore, growing steadily. However, it looks unlikely that a shortage of Java developers will materialize any time soon.

Secondly, in the Stack Overflow Developer Survey’s ‘Most Loved, Dreaded, and Wanted Languages’, Python is more ‘loved’ than Java is. It’s also more ‘wanted’ than Java, and actually the most ‘wanted’ language in the survey. It’s thus not surprising that Python surpassed Java for the first team this year in the popularity section of this survey.

The enterprise cultural perspective

Given the analysis carried out in the ‘Technical Perspective’ section above, it is clear how Java is a strong choice from a technical point of view for large enterprises. Think about the Twitter case study: the large enterprises are where Twitter is today. They use systems that must be able to scale their performance as needed in order to serve large business needs. There’s also the fact that such systems typically involve a very large codebase, and Java is better at encapsulation, which makes it easier for large teams of developers to collaborate on such big systems.

This doesn’t mean that large enterprises shouldn’t use dynamic languages for some of their needs, such as prototyping new business ideas, or perhaps for smaller internal applications. There are a couple of things which prevent this though, and they’re not technical:

For one, a large architectural shift, such as the one going from static to dynamic languages, (traditionally) involves going through multiple levels of approvals within an organization’s leadership. In many cases, going through this process takes a long time and negates the speed improvement provided by going to a dynamic language, rather than sticking with Java. The following guide for a widely used change management system published by Stanford University IT is a good example of understanding how complex an approval process can get.

Secondly, there is considerably less financial pressure, compared to startups. A startup needs to hit the market as soon as possible in order to start generating revenue. A large enterprise has financial buffers, and budgets can sometimes be allocated for more than a year ahead. Therefore, there is less incentive for teams to want to do things very differently. Also, it’s easier to stay within your comfort zone, and employee resistance is one of the main reasons why 70% of organizational change programs fail. This is why it’s important to carefully consider technical options at the start of a project.

Final Thoughts

Through our analysis, we can see that Java remains relevant in the modern world of web development. From a technical point of view, Java outperforms Python and Ruby in benchmarks and is architecturally more inclined towards parallelism, multithreading in particular.

If your goal is to build web applications that are naturally reliable and scalable, then you should strongly consider using Java. Java has been shown to be just as active as Python for remote work, exhibiting an equivalent talent supply and demand. Finally, from a financial perspective, Java salaries are in line with all of its dynamic language competitors.

Ultimately, Java isn’t going anywhere anytime soon. In some sectors such as enterprise finance, Java remains the most predominantly used language. We’ve also seen that tech companies such as Twitter have moved away from dynamic languages to Java in order to take advantage of its natural ability to scale and to support resource-intensive applications. Bearing this in mind, Java’s continued relevance is clear, maintaining its position as a strong choice for web development.

Are you looking for help with your next software project?
You’ve come to the right place, every Scalable Path developer has been carefully handpicked by our technical recruitment team. Contact us and we’ll have your team up and running in no time.