Java developer skills you should learn

Mark Little, the technical direction, research, and development for Red Hat JBoss Middleware talks about skills Java developers need, how Java stands the test of time, and how to optimize Java development for Kubernetes. Little also covers if there are any gaps in what Java can deliver given the pace of business with containers and microservices, and some tools developers can benefit from like the Java Virtual Machine and GraalVM. Even more, Mark shares his predictions for the future of Java and what's next for Java, and tons more.

ADM: Java has been around for a long time, but it is still as relevant, if not more relevant, today than it was in the past. What about Java makes it stand the test of time, especially now?

Little: Java is still extremely relevant today if only for the fact that so much enterprise software has been written in it over the last 2+ decades and with millions of developers around the world using it. It’s also used within schools and Universities as a teaching tool to understand object-oriented programming, modularity, and distributed systems. Of course, there are more competitors to Java today than we’ve probably ever seen in the past but if anything, that’s helped to spur the evolution of the language.

Java developer skills you should learn

And on the point of the language, I think it’s also important to mention that whenever we talk about Java, we often muddle up the language with the frameworks, stacks, IDEs, and other productivity tools that have grown up over the years. Even if a better language turns up (subjective term) there are millions of developer days invested in these things, which make Java developers so incredibly productive and are impossible to duplicate overnight.

ADM: What inherent skills do Java developers bring to the table?

Little: This is an interesting question because it has multiple facets to it and is still going to be subjective. But if I look at my own experiences, those of my teams, and even that of my youngest son who learned how to program in Java by hacking Minecraft, I’ve got to say that Java developers all bring an appreciation for modularity, multi-threaded concepts (and the pain therein), and code sharing, whether by virtue of someone else using your code as a 3rd party component or duplicating it directly within their own.

If you then add in the enterprise Java experiences, it’s got to include large-scale distributed system concepts and problems, like ACID transactions, high-performance messaging, fault tolerance, and reliability characteristics needed to build the systems behind financial, medical, and government systems.

ADM: Given the pace of business and the current cloud-native focus on containers and microservices, are there gaps in terms of what Java can currently deliver?

Little: There are definitely gaps, but I’m happy to say that the community is closing them down pretty quickly. For example, the original Java memory model was pretty much “give me all your memory for the duration of the application,” which not only isn’t useful in a cloud environment from the perspective of trying to increase the density of applications running on the same CPU but also costs more. That problem and how it impacted Linux containers, was identified a few years back and has been pretty much resolved since.

Then there’s the fact that Java has always been a very dynamic language, despite being statically typed: what I mean by this is that Java gives you a rich set of capabilities to delay decisions about what implementation of a specific interface your application will use until the very last minute, which could be hours or days after the application began running. So Java has a very mutable approach to applications, and naturally, developers have grown up taking advantage of this in their applications or frameworks.

However, in a Kubernetes native environment, or even just a serverless environment, those approaches pose problems with memory utilization and start-up time, at the very least. Furthermore, Kubernetes is architected around immutable architectural assumptions, so if you change the application at runtime you really should do so by creating a new Linux container image. Now those things are still useful outside of Kube so we don’t want to change the language by removing them. But new approaches, such as Quarkus, Micronaut, and GraalVM, where these decisions are made at build time not run time, or Java is compiled down to a native executable, are making inroads to enable Java developers to bring their skills to Kube, microservices, etc. in a more efficient way.

ADM: For organizations looking to optimize Java development for Kubernetes, what criteria should they use to assess tools and platforms? Can you provide some examples of these tools?

Little: I think you first need to decide if your applications are going to be long-running or not. By that I mean they’re likely to run for at least a few minutes. The Java Virtual Machine has had so much time and effort put into it that it can optimize your running code so well and fine-tune memory management these days, that as long as you give it time to do so, it’ll pretty much outperform anything else. Now of course that doesn’t change the fact that Kubernetes is still based around an immutable architecture so you need to be aware that changing your running application is going to be transient and you really need to change your build pipeline instead. So rather than, say, send your Application Server a new implementation of a Messaging Service, which it then swaps in place while it’s still running, create a new base Linux container image with your Application Server using that same implementation and ask Kube to use that for subsequent invocations.

Now if your applications are transient and only run for a few seconds, such as in a serverless environment, you may need to look at Ahead of Time Compilation and efforts like GraalVM, which Quarkus uses as well. Then you’re locking in most or all of these dynamic decisions at build time and generating a smaller native executable image. There’s a trade-off of course because this native image will only run on a specific operating system, rather than any OS, but you get an image that uses less memory and starts up much quicker than the traditional JVM.

ADM: How do tools like the Kubernetes-native Java framework Quarkus and the Kogito Java toolkit support Java developers? 

Little: Well like I said earlier, their overall emphasis is on providing Java developers with a way of building on their existing skills and at the same time optimizing the resultant applications or frameworks to be far more efficient when running in a Kubernetes environment. It’s too easy to complicate things for developers and I think what we’re seeing with Quarkus, Kogito, Camel-K, etc. is a realization that we need to hide as much of the complexity as possible by being much more prescriptive than Java developers have typically been in the past. That doesn’t mean users can’t use dynamic aspects of the Java language, for example, but with Quarkus and GraalVM, for instance, there’s a concerted effort to make it less necessary and, where possible, ensure the developer has a better understanding of the trade-offs being made.

ADM: Can you think of any areas that current tools and frameworks are not addressing when it comes to Java development in an increasingly cloud-native world? What work still needs to be done?

Little: I think the areas where we need to see more emphasis are in the integration of Java (the language and frameworks) with Kubernetes and Services, Managed by the Cloud provider or the end-user. For example, more and more Kube clouds now have Knative or Istio built-in and we’re starting to see good progress on ensuring those are tied into frameworks like Quarkus.

Then there is the growing importance of Managed Services within the clouds provided by vendors, including OpenShift. These Services include things like Kafka, API Management, Security, etc., and whilst they are developed in an end-user agnostic manner so you can use them from a number of different languages (typically they’re exposed via REST), we need to ensure that Java developers have quick and convenient access to these tools.

ADM: Do you expect Java to continue to have the kind of staying power it has demonstrated so far? What’s next for Java?

Little: I don’t see any reason why it can’t continue to be a strong player in the developer arsenal, especially if the wider community of language, framework, and product developers keep working together to evolve things so quickly. In terms of what comes next, I think we’ll see more Java applications and Services appearing in the clouds as core capabilities; when all we had was the JVM, it was often hard to persuade Kube developers, for instance, that embedding a mature Java-based Service within their favorite Kube distribution was the right way to go because the JVM has an overhead. Now we’ve got compiled applications that can run as fast, if not faster, than Node.js or Golang, that distinction is vanishing. We’re seeing more companies developing Operators using Java and Quarkus, for example.

Mark Little, Vice President of Middleware Engineering at Red Hat

Mark Little leads the technical direction, research, and development for Red Hat JBoss Middleware. Prior to taking over this role in 2009, Mark served as the SOA technical development manager and director of standards. Additionally, Mark was a chief architect, and co-founder at Arjuna Technologies, a spin-off from HP, where he was a Distinguished Engineer. He has worked in the area of reliable distributed systems since the mid-80s with a Ph.D. in fault-tolerant distributed systems, replication, and transactions. Mark is also a professor at Newcastle University and Lyon University.