The Future of Java: Will You Have to Pay For It?

Listen to this episode on:

Apple Podcasts | Google Podcasts | Spotify | Overcast | Pocket Casts

---

We're kicking off 2021 with a new interview series: GOTO Unscripted, with our first round of interviews recorded back when we could still meet in person. GOTO Unscripted takes our conference speakers off the big stage and brings them behind the scenes for an intimate conversation on topics they know best.

Java is currently one of the most used languages in the world with over 16% of developers world-wide using it on a current basis. Jørn Larsen sits down with Trisha Gee and Daniel Bryant to explore how the language is evolving, how it fits with the cloud ecosystem, and what are the important skills for being a good (Java) developer nowadays.

---

Jørn Larsen: I have Trisha Gee and Daniel Bryant, and we're going to talk about something exciting: Java in the cloud and Java in general, and then some. So, first of all, I'd like to hear a little bit about your background.

Trisha Gee: Hello. Yes. So, I am a Developer Advocate for JetBrains. I was a Java developer for 15-20 years, something scary like that. I also have a traditional background in computer science, and then, being a developer in enterprises and startups, and then, became a developer advocate because it's kind of fun to go to conferences and talk to people and meet people and tell people all the cool stuff that you've learned.

Daniel Bryant: Hi, everyone. My name's Daniel Bryant. I work with a company called Datawire now with Kubernetes tooling and am the Ambassador API Gateway, it's a nice t-shirt here. My background is kind of similar to Trish — I was a Java developer for many years, I started actually as an academic as well. So, I've done a bunch of roles over the years, but these days, kind of more focused on startup kinds of things, entrepreneurial ideas, and helping developers to do the best work possible with all these crazy new things like the cloud and containers and bits and pieces.

Why Java?

Jørn Larsen: So, why Java? Java is still the biggest language in the world and I think 16% of all developers use Java, so it's huge and it's by far no. 1.

Trisha Gee: I mean, we don't have that long story why Java, but I guess one of the reasons why Java is that it is used by a lot of people, so it ends up having that momentum. It's used in a lot of places, a lot of enterprises, there are a lot of Java developers, so people do Java applications because there are plenty of Java developers, and then, because there are plenty of Java applications. People train up to learn Java because there'll always be work in that area. But having said that, other large languages have declined in the past and they've become not fit for purpose. So, Java as well continues to evolve to be fit for purpose in terms of certainly enterprise development and more and more around startups and lean-type enterprises I think.

Daniel Bryant: I agree completely on that one, Trisha, I think the interesting thing with a lot of technologies we've got these days: we've got such a broad choice. Like when I was growing up in the '80s it was super basic hardware like BASIC or Assembly were my choices of learning languages. These days, you've got so many options, and I still think,, even though Java is evolving, I even look back at say Java 8 or Java 5 even and like most of the stuff, I actually want as a developer is a kind of there in the platform, it's just that there is other languages coming up through like Go, say, and even kind of the resurgence of Python and so forth. They often have good kinds of different sorts of fits if you like. Python is really good with its library support around machine learning, AI and so forth, but I think Java is a really solid language for general purpose programming. It's quite easy to read; you certainly can create hard-to-read Java, but I've seen Scala, for example, is even worse, I've done Prolog in the past and Haskell, that's really hard to understand, sometimes. So, I think Java is a really nice sort of glue kind of programming language, fit for the enterprise, fit for general purpose, mashing together other technologies I think as well.

Trisha Gee: I also wanted to mention, of course, it's not just Java, of course, it's the JVM. So, the JVM platform allows us to use things like Scala and Kotlin, of course, mutual friends, and that's the nice thing about the JVM, is that you don't just have to restrict yourself to Java, the language. If you decide Java, the language is a little bit old-fashioned or doesn't have what you want, you can pick up like Clojure, or Scala, or Kotlin, and of course, with a lot of the interoperability of the JVM, you get the language support and, even though you're using different languages, you get languages and libraries that you can glue together with your different JVM languages. So, it's very multipurpose I think.

How up to date is Java with the latest innovations and ideas in software engineering?

Jørn Larsen: I want to add that actually, Java was more or less in the beginning there to fix the problems with issues with C++ and C and they are actually, together, they are actually even a bigger language if you combine C and C++. So, Java, and C, and C++ is actually dominating all the development world. Java is turning 25 or around that. So, how up to date is Java with the latest innovations and ideas in software engineering?

Trisha Gee: Java is always going to be a little bit behind, it's not going to be the most bleeding-edge because of the stability, because it is used. And one of the great things about Java is the fact that it's used in a lot of places and the stewards of Java want to make sure that they retain backward compatibility. They don't want to break everything by moving too fast. They don't want to introduce major changes. So, some of the things that developers moan about that Java doesn't support are kind of like that for now until they can find a way to fix them in a way that won't break everything else. 

Java is always going to be a little bit behind I believe, and I believe that's one of the strengths of the language. But it's moving increasingly fast with the six-monthly release cadence. It means that instead of having a big-bang release every two, three years, we get a small, steady drip of features every six months if we want to move to that sort of cadence. So, it is moving probably at the same speed, it's just that we get more frequent releases, so that's useful, we get stuff, we don't have to wait for three years to get the next release. 

The other thing I mentioned about the other JVM languages is that Java can borrow from some other JVM languages if something seems to work in Kotlin, or Scala, or Clojure, or whatever, and that can get folded back into the language. It's a nice way to sort of prototype, that's not really fair in the other languages, but it's a nice way to try out new stuff and you can still try out those new features in a different JVM language if you want. So, yeah, it's not the most bleeding-edge of languages, but I think it strikes a decent balance.

Daniel Bryant: It's quite funny, though. So, I'm quite a hipster when it comes to tech in terms of containers and all that kind of thing and cloud tech. But I'm actually quite pragmatic when it comes to Java. I think Java is a really good language, and in some ways, you don't need to change everything if that makes sense, and I think bingo, is that what you said Trish, like Kotlin, for example, has got some amazing semantics for writing certain things. And for us, as a Java developer, learning Kotlin is not super challenging. So, if I really want to do this kind of different programming model, I think learning Kotlin rather than complaining about the Java framework... not, well, Java, but platforms, right, not supporting something, probably a better use of my time to learn Kotlin.

I think in some ways, Java's got to the point where it really can do pretty much everything we want it to. Yes, there are always cool things we can borrow from Go, or from Python, or whatever, but I guess I'm a little bit old and jaded these days. Like I think why? As in, if I really want to use Go, let's use Go. And we're all building modular systems these days, like modular in the JVM, but we're also building modular systems in terms of microservices, these kinds of things. So, there's nothing stopping you from spinning up a Go service that chats to a Java service in my opinion. So, I like Java and I like to see it change, I'm totally cool with that, but it's not a deal breaker if it doesn't change for me personally.

Thoughts on the new Oracle license model

Jørn Larsen: So over the past year, something that has caused some waves and turbulence in the community is the new Oracle license model, and maybe you can just comment briefly on that.

Trisha Gee: I can try and comment briefly on that, and as of Java 11, Oracle has changed its licensing for Java, and what that means is if you are using Oracle JDK, which a lot of us are, we need to be aware that we shouldn't just by default be using the Oracle JDK for Java 11 and onwards and putting it into production. Because if you're using the Oracle commercial JDK and put it into production, you will have to pay for that. But that doesn't mean that Java is automatically paid for, it means that there are multiple JDKs to choose from now and you need to understand the different licensing from the different vendors, the different release cadence, it's complicated. So, I don't really want to give like TL;DR. I will talk about it in my talk in GOTO Amsterdam, tomorrow.

If you are going to use Java 11 onwards, it is important to understand that licensing has changed and you do need to do your research around that.

Daniel Bryant: Yes. I don't think I can add too much more on that one, Trish. I think the key things are, in some ways, I totally get why Oracle did it because everyone's got to make money and this is the way the commercial world works, but at the same time, it has made it more confusing for us as engineers I think. So the choice is not always a good thing. 

I'm a massive fan of Azul Zing and there's obviously, of course, AdoptOpenJDK, building binaries, there's a lot of choices out there, but I do think — we've been chatting a little bit off camera earlier on — I think the key thing is to make sure someone in your team takes responsibility for understanding these options and the legal ramifications. It may even be worth talking to the lawyers in your company, dare I say it, but not everyone I think should burden themselves too much. Java the language is still free. The way you run it, the JRE in particular, in production, there's a few nuances around that now. So, I definitely would recommend either an architect or a team leader or CTO in the company, probably, ultimately, the CTO taking responsibility, doing a bit of homework, studying up, and making the correct choice for everyone in the company.

Trisha Gee: I did want to add something though, because, since Java 11, Oracle has made OpenJDK the same as the Oracle JDK. So, it's the OpenJDK which is still free, but it only gets updated every six months. It's complicated, right? But in the past, we always looked to Oracle's JDK. Now, we should be looking, probably, if we want a free one, we should be looking at an OpenJDK build probably.

How do Java and containers go together?

Jørn Larsen: We are not lawyers, but I actually think that if we are as a community and we have some ideas on how to simplify things, I am also sure that Oracle can change a few things because, I mean, it's also the first version of the new license model, and of course, if it causes some confusion, I'm sure they will listen, and if there are like millions of people coming against them, I'm sure they will listen more. So, maybe let's try and see where the confusion is over the next period of time. Let's jump to something else. So, it's up to date, it's a fairly modern language still, Java and containers, any comment on that and how that goes together?

Daniel Bryant: Fundamentally, Java runs well in containers. Again, everyone's moving to the cloud, VMs, containers, Kubernetes. Java I still believe is a good fit there. It's well worth doing some research, again, it's probably, so one of our common themes here is to do your homework. As the platform you're deploying onto changes, you need to make sure you have mechanical sympathy as Martin Thompson calls it. You need to understand to a certain level the platform you're deploying on to. Shameless plug, I have covered this in my book, Continuous Delivery With Java — got to mention that one, but it's because the reason I've covered it is because I got burned with it. Pre-Java, I think it's 8 Update 161, something like that, the JVM was not fully respective, fully in-tune with the way containers restrict memory and CPU allowance, for example. It's all been fixed now, from like Java 9 onwards, and then, your Java has even been backported to Java 8 around one of the updates, worth a quick google. Now, the JVM, when it spins up, it realizes it's in a container and it configures itself correctly. The heritage of the JVM, of Java is fantastic, 25 years. Back when we were starting up the JVM 25 years ago, the JVM assumed it had the whole machine it was deploying onto. Now, we're kind of putting things in containers and we're putting multiple things on a single host, the JVM needs to understand that it's running in that kind of environment. So, definitely a bit of stuff to learn. Many people, other than me, have talked about this at GOTO I think, other presentations — Sander Mak talks about this kind of stuff. There's plenty of stuff out there, but I think the key message for me is if you are going to move to serverless cloud containers, just have a quick google around, check what version of Java you're running and if any tweaks need to be made.

Trisha Gee: I do want to add a little bit. As a beginner around the Java container side, I was just trying to learn Docker this week, shameful, really. How many years has Docker been out? "No, it's because I'm an expert in Java, I don't need to know that." And it's a little bit complicated and confusing really, getting started, but I think it's an area that is maturing, and so tutorials and documentation are getting much better around that area. But I think the important thing for me, when I was like googling Docker and containers: if you're looking at general documentation, that's not as useful as if you're looking for Java, Docker and containers because the way they all play together, as you say, it's important to understand how containers apply to your platform and your language.

What skills are important to be a good developer?

Jørn Larsen: My final question to you is more open-ended. We talk a lot about the language, the skills and the versions, but what other skills are very important in your opinion to be a good developer and make great software?

Daniel Bryant: It's a great question, and I think these days, there's an expectation for developers to be sort of full stack and to learn many, many things. And I don't think it's a bad thing, but at the same time, I think we do need to realize our individual limits. Not everyone can learn everything. It's just physically impossible, and we've also got certain strengths in certain areas. So, I think one of the key things for me is kind of when you're young in your career or early in your career is to find your niche. Find where you're good, find where you're comfortable, find where you can make a big impact. I've worked with some amazing engineers at Datawire who are really good at working really close to the metal, properly, you know, building platforms and tools. I've also worked with some people that are really good at talking about visions and leading teams, and we've really worked hard to make sure people are in the position where they can make the most impact. Some developers just want to code, they just want to solve business problems, and there's definitely a place for that person. But if they're working closer to the business, I think we probably need stronger communication skills. Less and less now I think it's about raw coding at the kind of application level, it's more about gluing things together.

Hey, I've got Spring Framework, it does a bunch of cool stuff for me, I put my business logic in it, but I need to make sure that business logic is really going to add value to my customers. So, I'm very much a generalist I guess these days, as much as I do close metal stuff with Datawire, but that's my niche. It works for me, but I really enjoy working with very deep specialists as well. So there's a place for everyone I think, Trish.

Trisha Gee: I get a bit irritated with the vision inside the industry and outside the industry that to be a developer, you have to be really good at one thing or really deep or possibly deep and broad in, you know, and really good at everything. That kind of irritates me because I think it puts a lot of people off because I think like generalists like you and I are like, well, it's nice to get, to dip into those things and learn them a bit, but it's nice to go over here and look at this and I've got communication skills as well, I don't necessarily want to be sat in front of the computer the whole time. I think the industry has definitely changed in terms of things like full stack, not just doing back-end stuff. It's important, probably, a lot of developers have to know some JavaScript front-end stuff and some HTML and CSS, and I'm talking from a Java developer point of view. 

Front-end developers are starting to learn more back-end stuff as well. There's more full-stack stuff, there's more DevOps stuff. Understanding, like a lot of developers, when they first get into DevOps, operations is an entirely different thing. Having to understand how the command line works, having to understand what physical machines are there, what are the limitations, how do you... maintenance, getting woken up in the middle of the night, you know. These are things that I didn't have to worry about when I was an enterprise developer, when I started. But it's not just having that wide range of technical skills, it's also as you say that the business skills, the communication skills. "What does my customer want?"

When the business says to me, "I need a button that does this," you should be asking them, what is that trying to achieve? What do the end-users want? What is the problem you're trying to solve? Because a junior is going to apply, just do the button, they're going to do what they're told, but a more senior developer is the sort of person who says, "What do you want to do and why do you want to do it? Perhaps, we can do it this way," which is not just listening, it's also communicating why something might be a better vision, it's understanding the business, the users.

So, I think those skills are becoming more important for developers and I think developers who have this broad range of technical, communication, business skills are in my opinion more likely to succeed, or there are more jobs for them, let's put it that way. Because there are more companies who want that broad range of skills. And so, I think that we should stop, as an industry, we should stop talking about developer skills and language skills and start talking more about how we are all people who have our niches and how different companies want different skill sets and different types of developers. And if you get rejected from an interview because you don't have a particular set of technical skills, there's a company out there that really wants you because you're you, and that's really important to understand I think. Don't get put off just because some company or some conference or someone doesn't want you because you are needed in this industry.

Jørn Larsen: Thank you so much. Brilliant answers. Thank you so much for coming to this interview and to GOTO Amsterdam.

Recommended talks