In the decades since its release, Java has expanded and adapted to deal with every challenge that has been thrown at it to help make our lives easier.

Java has had a good two decades. For those of us who remember the release of the programming language, it’s hard to believe that it’s been almost twenty five years since it was released, and made our lives a whole lot easier. In the decades since, Java has expanded and adapted to deal with every challenge that has been thrown at it.

Or almost every challenge, that is. The very features that have made Java so effective at adapting to new environments and tasks – the fact that new libraries and services can be added in a modular fashion – means that many are questioning whether it will remain the best language to use.

This is because, and as we’ve also pointed out in our report on the future of Java, containerization is now taking off in a very real way. And, unfortunately, there are real disadvantages to using Java in containers.

Quarkus is one of a set of tools that are attempting to get around that problem. But can it restore Java to its rightful place, even in the era of containerization? In this article, we’ll find out.

The move to containerization

First, it’s worth reminding yourself what, in actuality, containerization means today. Nowadays, discussion about Docker, Kubernetes, microservices, or CI/CD, is so common that few of us stop to think about how these approaches work at a more fundamental level.

Essentially, containerization is an approach to programming where an application within a software container is written in a non-native language (in this case, Java). This means that these containers are platform-independent (or “platform agnostic”, in the jargon), and can be run on a huge variety of different hardware and software platforms.

As IT expert Barbara Ericson of Cloud Defense explains in-depth, containers “make distributed development easy and intuitive for larger teams and can automate work after deployment like you’d never believe. It does this by isolating different applications into different digital ‘containers’ for better security and portability.”

Sound familiar?

It should, because here’s the strange thing about containerization and Java – both are trying to achieve the same outcome. Java was always designed to be a “write once, run anywhere” language, in the terminology of the original releases. This platform independence is one of the major reasons why it has become so popular and, strangely, also one of the reasons why Java doesn’t work so well in containers.

The problem with Java

Java has traditionally been used for helping securing and processing data in remote servers. For instance, Java provides secure socket layer (SSL) extensions to help further enable secure connections and data transmission between servers and clients that operate over a network connection. Today, roughly 25% of all domains today come SSL encrypted, many of which utilize Java secure socket extensions.

But don’t get me wrong: there is nothing wrong with using containerized Java in a serverless environment occasionally. Particularly during the development process, wrapping Java in containers can provide the kind of granular scalability that is invaluable when trying out new ideas. Taking this approach, alongside borrowing some efficient code samples for Java programming, can give developers the freedom to try different languages.

There are, however, some major disadvantages to taking this approach as well.
The most fundamental of these is caused by the fact that Java and containers are – as I’ve just pointed out – trying to achieve the same thing.

Containers, when implemented correctly, contain everything that is needed to run a particular app on (almost) any hardware you want. As a result, they generally contain multiple, redundant libraries, and exotic code that is only executed in the event that you (try to) run your containerized code on some equally exotic piece of hardware.

Java, because it is also designed to be platform-independent, also contains these elements. This means that, in many cases, containerizing Java is complete overkill. You are doing something twice (making your code widely compatible) that you only need to do once.

This creates two problems.

One is the obvious one – that containerized Java can come with a significant performance deficit in comparison to either straight Java or other languages used within the same container. Your hardware will spend a long time working out which libraries it needs to use – once for the container, and then again once for Java itself – and this can really slow it down.

The second issue should be equally obvious, but often isn’t. Any time you introduce added complexity to your code – say by adding extra redundant libraries for obscure hardware architectures – you make it more difficult to secure. One of the major research foci of recent years has been how to fight Java security vulnerabilities through locking down little-used libraries and functions that can contain malware or decades-old security vulnerabilities.

As someone who has spent many years trying to make Java more secure, let me plead with you – please don’t add another level of complexity on top of what is already a complex language.

Quarkus optimization

Or rather, don’t do so without using a tool like Quarkus. Quarkus is one of a group of tools that seeks to overcome some of the problems I’ve mentioned above. The tool optimizes Java to run in serverless, cloud and Kubernetes environments by removing huge amounts of code that are not necessary to run Java in this way.

It’s possible, of course, to fine-tune your own Java to avoid some of these problems. You can manually trim your code to suit the kind of containerization you are using, or even use pre-packaged versions of Java that are specifically designed for particular containerization environments. Services like this have become a large part of the transformation of Java in the cloud-native era, because they offer performance and security advantages over using raw Java or packaging other languages in containers.

The problem with that approach, however, is that while it might save computing time, it definitely doesn’t save you time. Quarkus takes a lot of the hard work out of optimizing Java by applying a standardized set of assessments to your pre-existing containerized Java, and stripping out much of its complexity.

The future

Looked at in the broadest sense, tools like Quarkus are merely a continuation of a process that has been running since the advent of Java more than two decades ago. The language is now so well known, and is taught to so many undergraduates as part of their first college courses, that questions about whether Java is still the best choice for developers remain largely academic.

In other words, while some of us might occasionally raise questions about whether Java is still the best tool to use alongside emerging technologies like containers, developers such as those at Red Hat are already one step ahead of us. The joy, efficiency, and efficacy of using Java means that some of us will always find new and better ways to do so, whatever the future brings.

Community

Quarkus Optimizes Java For Supersonic Development Speed In A Serverless, Containerized Cloud Environment

The move to containerization

The problem with Java

Quarkus optimization

The future

Read previous post:

Read next post:

Lee Li

You may also like

Comments

Lee Li

Related Products

MaxCompute