97 Things Every Java Programmer Should Know with Kevlin Henney

Kevin Montalbo 

Joining us from Sydney, Australia is Toro Cloud CEO and founder, David Brown. Good day, David!

David Brown 

Good day, Kevin!

Kevin Montalbo 

And our guest for this episode is an independent consultant, trainer, reviewer, speaker and author. His work focuses on patterns and architecture, programming techniques, and languages, and development process and practice.

He has been a columnist for various magazines, such as The Register, Better Software, Java Report, and has given keynote addresses in several conferences around the world. He’s also a co-author, contributor, and editor for a number of books. One of them is titled 97 Things Every Java Programmer Should Know – and we’ll be talking about that one today.

Ladies and gentlemen, joining us today is Kevlin Henney. Hi, Kevlin! Welcome to Coding Over Cocktails!

Kevlin Henney

Hi Kevin, thank you very much!

Kevin Montalbo 

All right, so let's jump right in. In 2020, you came out with a new book, 97 Things Every Java Programmer Should Know. This is your second 97 Things book, the first one being the Programmer edition, which was published in 2010. So, what transpired within those ten years that motivated you to come up with this book?

Kevlin Henney 

A few things. One of the things that I noticed in putting together the book in 2010, 97 Things Every Programmer Should Know, is that it was intended to be a general book, you know?

A few years after that, there was the idea. "Perhaps what would be nice is to go into more depth." In other words, to go into a particular language, to choose a language or technology. We, kind of, kicked this idea around. I kicked it around with the editors at O'Reilly for a while, as it was [to] zoom in, [to] allow us to get much more specific.

And one of the things that happened with the 97 Things Every Java Programmer Should Know book, what kind of came about is a sort of mutual interest of one of the languages I have an interest in, but it was kind of the most likely candidate. It’s been the most broadly based. It's been around for a long time. It cuts across many, many different technology stacks and many communities, but it is still also concrete. And unsurprisingly, we got a lot more code examples for that one.

David Brown 

A huge community, obviously. Java's still one of the most popular programming languages.

Kevlin Henney

 Indeed, yeah, definitely.

David Brown

 This is a collection of articles from different writers, as I understand it. There's not 97 different writers there, but I noticed that so much of it was written in multiple pieces. But how do you go about collating all of those developers and writers to write about this sort of content?

Kevlin Henney 

It's kind of a mixed process. So, this turns out to be a coincidence. There are 73 contributors. And the reason I say it's coincidence is because for the previous book that I did, there were 73 contributors. So, it was not by design. I co-edited this book with Trisha Gee. So, we went through it and said, "Okay, who have we got as contributors?" And I looked at the spreadsheet, that's 73. That's exactly the same number as last time.

But there's a few tricks and tips. Some of them are direct invites. So, I was editing this book with Trisha Gee from JetBrains. We have an overlap in the people that we know, but we also know very different people.

And Trisha and I really struggled with some of the decisions, you know, from people who had submitted four or five or six pieces—all of which were good. And it's just like, well, we can't take them all. We have a principal here. So, there was a balance. So, basically what we were looking for was a mix of things. It's 97 things. The important thing that I've kind of alluded to is the "voices" aspect. You can get an individual developer and say, "Could you come up with 97 things?" And yeah, they probably could, [but] this is not "97 Things One Developer Thinks You Should Know." This is supposed to be a, kind of, sampling across the set of programs of which there are millions.

You're never going to get all of that, but that's the idea. Let's get some different voices, different points of view. Sometimes it's a different piece of information, but sometimes it's the way that somebody presents it as well. They come from a different angle, it's a novel or exciting perspective, or their code example is fresh. Or they've got a nice anecdote to go with it that nobody else has.

David Brown 

Did you have to target a specific version of Java for the book?

Kevlin Henney 

No, we made it fairly broad-based. The book is pulled in a few different directions because one, of course, Java is version-sensitive and that is a distinction with the book, the 97 Things Every Programmer Should Know book because that is not version-sensitive because it is, if you like in one sense, a little more timeless.

But we were assuming people would be targeting something that was relatively current. And when we said Java, although the natural default is to assume language, we were really talking about it also as a platform. It's not just a language. So, we are dealing with other languages, although most of the submissions were Java language, where they focused on language, but that means that you're dealing with different technologies, different versions. For some people, you know, there are folks out there that are still on, kind of, 1.5, but there are also people who are chasing every release twice a year you know? Keeping right up to date.

And we had to make sure that when people submitted things, we changed the tone or the voice as appropriate. In fact, we had a couple of pieces that we ended up not accepting because in the time from acceptance to editing, that actually went out of date, like blog pieces. And that's a different thing, it’s that a number of people have experienced writing blogs and the point of a blog is it's now for certain things. If I'm going to tell you about the new features that are coming up in the next Java release, then that has a very different target audience and sense of freshness and timeliness to a book that, you know, somebody might pick up in two years time and it's still got to be relevant.

So, from an editing point of view, we try to sort of change the tense or make sure that people weren't saying, "And here's a new feature. As in super new," but realize where the cutoff points were.

So, for example, Java 8 is a really good kind of seismic cutoff and people will still be talking about that in years to come because it's so radically different. And if somebody is referring to the latest and they use a number, then it's just like, "Let's pull back a little bit from there." So, it's not intended. The book was never intended to be, "Here's the latest in Java, but it should be relevant." Most Java programs are not working on the latest version of Java. And that is always going to be true. That's the nature of a language at the scale. Once you hit a particular size, you have a much longer legacy tail.

So, this has to appeal equally to people who are still learning Java from books that are 10 or so years old or code bases that are 15 years old, as well as somebody who has just been getting into it and still wants to learn. There's more to it than just new features

David Brown 

Is that the target market? People just starting out?

Kevlin Henney 

It's a broader target market. It's kind of a market for people who are either starting out. This is the book that you don't get. In other words, maybe you've learned the syntax. Maybe you come out of college and you will have a particular perspective, but maybe coming into Java from another language. Maybe you're returning to work. Maybe you're a senior developer just trying to round out things because everybody at one level or another is self-taught, or maybe you're helping mentor somebody else.

So, in other words, I want to refer you to something and say, "This one covers it quite well. This is a good starting point." So, it really is quite broad in that sense. It's not just for newbies, it's not a "how-to" book. It is intended for somebody who has a little bit of Java under their belt, or a lot of Java and has been around Java for a long time.

In fact, that’s another classic target audience. Any language that has been around for a long time has people who've come into it, gone out of it, and then come back again. What has happened in the intervening period? So, it pretty much lives up to its title. It is kind of what every Java programmer should know, regardless of their experience. Things that are overlooked. I learned things, Trisha learned things. So, you know, in that sense, I'd say that it's not a specific, small target audience, but I could identify different groups within that very broad audience.

David Brown

I was just about to ask you that. Were there some contributions made which blindsided you, like, were really surprising?

Kevlin Henney

Well, not necessarily surprising, but sometimes it was a little detail that they would highlight, just a sort of a technical detail, either kind of a language spec or something on the GC or just a perspective or some aspects I just simply didn't know about. Sometimes community, sometimes environment.

So, there was nothing that really kind of completely threw me as saying, "I did not know that, and that has changed my worldview." But that might be more of a reflection of somebody who's on the lookout for this, or potentially somebody who's jaded. I'm quite happy to accept that accusation as well.

David Brown 

Are there any challenges in terms of, like, differences of opinions and you know, deciding on which angle you're going to take on a particular feature or technology?

Kevlin Henney 

Oh, that, now that one's an interesting one. So, Trisha and I were fairly clear from the outset that what we wanted was not "97 Things That Tricia and Kevlin Think Are The Most Important." We didn't necessarily agree with everything, but that again goes back to the voices because there isn't one true answer here. You know, this is not a programming community of 50 people. And it isn’t a very closed clique or anything like that. It's quite broad. There's a lot of different points of view there.

And so sometimes, trying to get to represent that view, that's quite an important one. So, having pieces that, in essence, might contradict one another is not a problem. Although, sometimes I got that with the previous book, that was an intention of mine that sometimes you're getting a book from a single author, you expect a coherent narrative. You know, there's a single story in a single point of view to be told.

And here, that was not the objective. It is a representation of what is out there. And mostly, things don't conflict or contradict in a big way. This is much more of a patchwork with a little bit of overlap, but there are some things where we do end up with potential contradictions and we actually sought out some of the contradictions.

So, for example, we have a piece on why certification is good. We also have a piece that is incredibly skeptical of certification. And, you know, once we had one, we wanted the other, because we know that this has potential, this speaks differently to different people. And different people have very different takes on that. So, we actually sought out something to counterbalance that.

I wrote a piece on checked exceptions, as in please, don’t. So, I wrote a piece on that. We actually looked for somebody to try and write a good piece on "Oh no, you should use them and you should use your throws and your signatures," but we couldn't find any good ones. So that one didn't get included, but it's a case of like, we actually actively sought out things that might contradict a particular point of view just to show that, "Yeah, maybe it's not all settled that we're, hearing a number of voices and it's left to the reader." You know, you read it, find where your position is.

David Brown 

Well, unfortunately we don't have time to cover all of 97 pieces of advice. I guess that's what the book is for anyway. But could you just run through a few of the recommendations made in the book that maybe even the more experienced Java programmers might not know?

Kevlin Henney 

That's a really good question because I normally try to take a point of view. You don't play favorites as the editor. So, there were a couple of ones that I'll pick up. I’ll kind of pick a couple of which I think are quite interesting.

So, for example the Java world has kind of grown up with unit testing. Compared to other programming language cultures, it's a fairly central idea. You know, JUnit has been around since the 90s and that also defines many people's experience of unit testing. But there's this other question of, "Okay, what other approaches are there?" So, approval testing is something that I think is quite interesting. And there's already a nice piece by Emily Bache on that, to kind of like "Hey, here's a different point of view that you may find helpful." It may be helpful, particularly in legacy contexts but it fits right in.

There are a couple of nice pieces that I guess [helps] expand your brain. There's a James Elliott piece here on, "Okay. You got Javadoc, but what about also extending it into an AsciiDoc?" And that was kind of an interesting piece. There's a different perspective there. Okay, so he's showing you something else, what can you do and the subtleties.

And then also the reminders. One by Michael Hunger on benchmarking. Benchmarking is Hard is his piece. You know, JMH Helps. But the point here is he talks a little about the subtleties and difficulties—all of that, and really just going in there because there are a lot of myths when it comes to performance.

And I think that's true of any language in any platform, but platforms potentially as complex as the Java stack, there's a lot of different things going on at different levels. It's very easy to pick up myths, you know? Half-formed ideas that probably have their basis in some kind of truth or something that was true 20 years ago and is no longer true. And it's just this kind of, like, constant reminder.

But then we also have stuff on some fairly careful thinking. So, a nice piece by Chris O'Dell, Frequent Releases Reduce Risk. She talks about the idea. We have a kind of an assumption these days about CIC/D pipelines and so on, but what she does is she takes a different perspective on it. It's about risk reduction and risk management, which is a very different way. Sometimes people start from the technology, say, what is available. Sometimes people look at the point of view, "Oh, frequent releases are necessarily a good thing." And probably they've been in a particular environment, but they've never really understood the motivation. And she starts from a kind of a risk based perspective. So, there's a whole load of things here.

David Brown 

A lot of diverse content there as well.

Kevlin Henney

Yeah, absolutely. And then some counterpointing pieces. There's a nice one by Thomas Ronzon, How to Crash Your JVM. Not something you want to do, you know? But there's a point in there and the point that Thomas makes is it's very easy to look inside your IDE. "This is my code," and you expect everything that is defined there to be the truth.

But the point there is that the world of a software system goes beyond that. It goes beyond what you can immediately see, and it goes beyond the pure, idealized view of the language. So what are the ways? Stepping outside the view of your window, what are the ways that you can crash your machine? And so, there's these kinds of points of view. So, there's quite a lot there.

And I also liked the fact we have a couple of points and counterpoints. There's a piece by—and this was going back to your previous question about balance and contradicting point of views—there's a nice piece in here by Gail Ollis, Don’t Hide Your Tools, which is on IDEs. Don't trust everything about your IDE, understand the full environment. Whereas, Trisha, who works for an IDE company, clearly has a different take on it.

So, we were looking for that kind of balance and if you look at both pieces, you sort of say, "Yeah, there's truth in both." And it helps you understand what it is that I, as a developer, would need to know to get the most out of my tools. That becomes the bigger message there. So, I think that that's the thing I like. It’s not just the individual pieces but sometimes the interplay between them. It's that idea of, you're invited to think for yourself, but the point is people are putting forward different cases for different points of view.

David Brown 

Java is an interesting language, isn't it? I mean it celebrated its 25th birthday last year. It's been around for a while. It's not one of the oldest, we've got some old languages that are having a resurgence as well, but Java dominates a lot of things. Like, it dominates enterprise applications and it ended up as one of the most popular languages used today.

But, I guess when you've got a tall poppy like that, there's also been a lot of people wanting to sort of predict its demise. There were some predictions, more recently with Oracle's changing commercial licensing for Java as well. How has Java remained so relevant and resilient over the decades? You mentioned Java 8, for example. Is it keeping pace with technology and the requirements of the market? What is it?

Kevlin Henney 

If you're trying to predict the death of a language, you will lose.

Ah, I think that's an interesting question because I think it touches on a number of things. The first thing I would say is that it's a popular pastime amongst pundits to predict the death of a language. So, to all your listeners out there, honestly, it's not a game you want to get involved in, because if you're trying to predict the death of a language, you will lose.

I actually recorded a small piece for a discussion recently on the fact that languages very rarely die. The only cases where languages die is if they are incredibly, tightly tied to a vendor and were already and have always been like that, and therefore occupied a particular niche that once you remove that, then the whole thing kind of disappears or that they weren't nice languages to begin with, a very small community, perhaps a research-based language.

Very few languages actually die. What they might do is, they might slow their growth. They might become more moribund. They become at the point of death but never actually die. If you look at the top 10 languages or top 20 languages this year, you don't find languages that are younger than five years old. You know, when people talk about a new language, they mean something that's about 10 years old. These days we hear, for example, Microsoft is talking about moving stuff from C++ to Rust. Now I'm not saying Rust is old, but you know, it's closer to a decade than it is to half a decade. That's young, it's still considered young.

So, the interesting thing is if you compare it to other technologies, it's more like languages sometimes outlive operating systems. So, languages have a really long lifetime. Once they get there, they're not going to move and partly, they don't move. Yeah, they might adjust up and down, but they don't die. That's just not a thing that programming languages do. Fortran is still there. I haven't saved people in predicting the death of Fortran since the 1960s. And they've been consistently wrong.

So, the point is Java is kind of like that. It's everywhere. It offers you a stack. It's a VM, there's lots of libraries. There's lots of open source commitment. And once you get that kind of level of connection, if it were just a thin vertical slice that you can kind of pull the rug from underneath, then perhaps it could disappear with a small shift in technology, but it's much more pervasive.

It's like a city. Cities vary. They reach a particular size and they tend not to die, or it takes a very long time for them to die. It's connected across different platforms. You know, we find Kotlin on Android for example, which is quite a long distance from standard enterprise programming. We find Java in education. It's got a presence everywhere. So, I think that rumors of its death will continue to be exaggerated.

Java will celebrate its 50th anniversary without much trouble. Not to say that it would be as popular as it was when it turned 25, but it's kind of reached that point where it's fairly consolidated. It's still growing. I don't know whether the evolution of the language contributes to people coming into it, although that certainly for some people, they've got some of the frustration that they may feel sometimes with.

The classic Java is very verbose. The language is now very different. If you look at the language from a linguistics point of view, it almost contradicts all of its original design aims in terms of its syntax. It was originally supposed to be incredibly explicit about everything: minimal conversions, minimal surprise, minimal extra stuff put in by the compiler. These days, honestly, everything's deduced, which is the polar opposite. And you can see codes collide in these two eras.

So, it's got kind of a slightly postmodern feel. It's a bit of a mishmash in places, but for some people that's enough. They can feel more comfortable as, "Oh, I don't have to go to another language to get collection pipeline-style programming."

I've got streams in Java. I've got lambdas in Java and that satisfies an itch within me now that makes that a little bit easier. I'm okay with not having an even lighter syntax or if I do, I can switch to one of the other JVM languages and there's that kind of comfort that you can write a whole load of code and then say, "I'll switch to another JVM language. I'll do a bit of Groovy here." And it's still all of that stuff you've written or somebody else wrote for you a day, a decade back, that’s still there. So, I think that, you know, there's a little bit of fashion in there, but I think a lot of it is that kind of consolidation and entrenchment.

Java will celebrate its 50th anniversary without much trouble.

David Brown 

You mentioned it started out as verbose language. And of course, the trend towards technology generally is to abstract layer upon layer, whether it be Docker containers on VMs, on kernels, on bare metal, or you know, low code on the JVM, running on multiple Linux or Microsoft or Macintosh type operating systems or whatever it may be.

The trend is to abstract. So, of course, in the modern programming world, the latest flavor of the month is low code platforms and targeting citizen developers, no-code platforms. Now, low code has touted benefits for the enterprise, where Java dominates, such as productivity benefits. You end up producing more stuff, the greater output in less time. But one of the unexpected benefits, in some ways, is if you're producing less code then that code is easier to manage and maintain on an ongoing basis as well, regardless of who wrote it down the track.

So, how do you see low code platforms fitting into Java's dominance in the enterprise space? Is there room for both? Is low code going to be running on the JVM? How's it gonna fit together?

Kevlin Henney

The accounting department in your company has been doing functional programming for longer than you have.

Yeah, I think that's an interesting one because I've had a number of discussions recently about the low-code, no-code phenomenon and you know, there's a number of different takes on it. One of which is, "Yeah, we've seen this before and it was not successful the last time around or the time before that, or the time before that," you know. That's going back to languages that die. Most of those actually fall into the kind of classic waves where people were trying to do this. We also saw a lot of model-driven architecture type stuff in the 2000s.

Again, the rationale for that was the same, but at the same time, we should also look at where the success stories are. And actually there were some long standing success stories. Let's talk about spreadsheets because spreadsheets are a programming platform.

Perhaps it's one of those things that might annoy a few developers who think that they're being very cool about getting into functional programming to discover that the accounting department in your company has been doing functional programming for longer than you have. Because a spreadsheet is kind of like a pure, declarative model.

If I'm doing Excel and I'm not using VBA, then actually I've got a very pure programming model there. So here, we have something that has a universal adoption. And we don't think of it as a coding platform, but it has little coding extras. And when we look at how that's been used, then we start getting a feel for how it's going to cope, how this kind of stuff co-exists with other development. And I think perhaps the productivity thing is a bit of a red herring. I don't think that's really the issue.

The citizen developer. That's the issue. That's not a productivity question. You know, spreadsheets did not necessarily boost productivity of an individual or a particular role in a company that was previously a programmer role. It's going to allow certain people to do certain things. They wouldn't have even thought of using a programmer or, you know, saying, "Hey, let's talk to software development and get them to do something for us." They would have probably just mashed together a bunch of spreadsheets or a bunch of emails and said, "I've copied a link here and done this and that."

And so what it's done is it's just given a kind of name to that. You know, I think sometimes when people are looking at the low-code option, particularly the no-code option, when they're looking at it, what does it mean for developers?

I think they're looking at it from the wrong point of view. Spreadsheets never stopped people from developing. It just opened up the number of people who were using certain applications. You know, cameras and phones didn't stop professional photographers from having a business. It just opened up a different set of possibilities. And I think that that’s certainly the no-code aspect. And then nudging into low code that's much more where some people will be coming in from the program side, but others are gonna be coming in from other numerous disciplines.

I think this is kind of a liminal area. When you actually find out where people come from, when they end up in software development, you got a few people who went through a kind of computer science or software engineering background. But then you've got a lot of people who came through sort of middle territory.

They came through the sciences or they came through business with a bit of IT, and they ended up picking up programming and then moved into software development as a whole. But for a while, they were kind of a little bit in between. And, if you start looking at that as a group of people and a set of opportunities, rather than thinking of its productivity—think of it in terms of people, who does this benefit? What does it do that is different? Because that's the bit, that's why it might stick around.

And this is the thing that spreadsheets teach us. It’s that most people use spreadsheets to put numbers and shapes, they use it for pretty formatics and most people do not use the advisory. There's a few people who really get into formulas. And then there's a few people that are super power users who get into, "Yeah, I'm going to use VBA," and stuff like that. Again, it's that power law type thing. And that, I think, again, tells you something else about the shape of the adoption and why certain things might stick where certain things might not stick.

So, I think that when we look at Java and the JVM from that point of view, the Java stuff may come about for low code stuff that takes advantage of particular business workflows. And here's a typical business workflow. You get to customize the frontend. You're never actually going to see the Java code, but it's all Java libraries. Somebody has provided that and it's running on the JVM.

So, you've got this multiple targeting. You can shove this in the cloud really easily without having any deep discussion about native platforms and so on. And so, therefore, you've got something that, as long as you've got access to those libraries, that's incredibly powerful. So, it will continue to be there, but somebody needs to provide that. They need to provide the workflows.

David Brown 

You almost described our low-code platform.

Kevlin Henney 

There you go. You know, although people are pushing the kind of productivity it has, I don't think that's the issue. I don't think that's going to make a big difference. I think it’s to do with communities and possibilities out there. I've never really seen any of the productivity benefits of anything that was pushed just for productivity reasons, really take hold for that reason. Normally these things, if they've stuck, they've stuck for other reasons. I think that's what could be a differentiator here.

David Brown 

Kevlin, author of 97 Things Every Programmer Should Know, thank you for joining us today! How can our listeners follow you and stay in touch with the things you are talking and doing?

Kevlin Henney 

I am easily stalked pretty much everywhere because my parents were generous enough to give me an internet-unique name. So, "Kevlin Henney" is easy to find on the web. I'm on Twitter. My handle is my name. Ditto for Instagram. You can find me on LinkedIn, "/in/kevlin", I think that's my LinkedIn URL. So, yeah, I'm very easy to find. You know, I'm definitely not dark on the internet.