Trisha Gee and Kevlin Henney of 97 Things Every Java Developer Should Know discuss their book, which is a collection of essays by different developers. Host Felienne spoke with Gee and Henney about Java, including how to use immutability in Java, the value of type inference, and how to use your IDE most effectively when programming in Java. Other topics of discussion include good naming practices, checked exceptions, and co-routines.
This episode sponsored by Elastic and GuardSquare
Show Notes
Related Links
- 97 Things Every Java Developer Should Know
- IntelliJ conference 2021
- Kevlin’s site
- Kevlin on Twitter
- Trisha on Twitter
- Trisha’s site
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
SE Radio 00:00:00 This is software engineering radio, the podcast for professional developers on the [email protected]. Se radio is brought to you by the IEEE Computer Society. I believe software magazine online at computer.org/software Is your mobile app really secure new vulnerabilities, pop up every day. Securing your apps valuable IP and data is critical. Guard. Squares security solutions are built for developers and protect your app at every stage in the development life cycle, multiple layers of protection automatically detect tampering and make your app a difficult target for attackers. Learn [email protected] slash se radio.
Felienne 00:00:55 Hello everyone. This is Felienne for software engineering radio today with me on the show, our two guests, the first guest is Kevlin Henney. He is an independent consultants, trainer, coder and writer, and he’s given keynotes tutorials and workshops at hundreds of conferences around the world. He is the coauthor of a pattern language for distributed computing and own patterns and pattern languages. The second guest today is Tricia Gee. She has developed Java applications for a range of industries in finance manufacturing software for companies of all sizes. Trisha is currently a developer advocate at JetBrains and leader of the severe Java user group and a Java champion. So getter Kevin and Tricia edited the book 97 things. Every Java programmer should know welcome to the show. So I just read your book and it’s really back to it’s super interesting facts and information, even though I am not a Java programmer and have never been a Java programmer, I really learned to loss and many of the tips are also very generic in nature.
Felienne 00:02:00 So my plan today for the show is that I just ask you about a few of the 97 things that everyone should know. And afterwards, we will also ask you about your favorite things to know. So one of the chapters that I specifically liked is chapter five, about encapsulation and the author of this chapter. argues that encapsulation is actually one of the old principles that is used least. So that’s actually the first thing that I want to dive into a bit, what is encapsulation? Because if it’s not used so often, people might also not be so aware of what encapsulation is
Kevlin Henney 00:02:39 And put it is and where it’s and kind of explores it, um, cause the specific title of his peace, his behavior is easy. State is hard and it’s this idea of this kind of relationship that, uh, we want to get out that when many people think about encapsulation, they just think about a kind of a light veneer, just make a few things private, make the fields private, that’s it, it just kind of washes over it. We, I kind of, I’ve kind of scrubbed a little bit of private on, on the data and we’re all good. Whereas actually what’s really going on for encapsulation is this idea of how do I use it? What’s the interface? How do I want to use it? And if there’s something much richer that’s going on there. So often as developers, we tend to think from the inside out, you know, you’re presented on the screen, here are my fields.
Kevlin Henney 00:03:26 I can see everything. I have a privileged view, whereas now, so I don’t get that. And so we tend to think, oh my fields, I’m going to add some getters and setters rather than thinking, what’s this object for? How do you use it? What is the intention behind it? And these are far far harder questions and that is what guides the state of changeable objects. Um, for example, rather than thinking like, you know, nudging flags here and collections there. So often you look at some Java, you look at Java code and in some systems you get a feed and yet there’s collections and there’s strings and there’s integers and there’s flags. You don’t really get a sense of things in a capsule or quite literally encapsulate to put something in a capsule means there’s a boundary and we want to care about how do we look at that boundary the interface and what are we hiding away from people. It’s not just my choice of data representation. It’s the mechanics, if you like. So that’s really what he’s getting at. And you can see that’s a lot deeper than, I guess, many people think of when we think of encapsulation as, oh, it’s just private fields, that’s it, it’s a bigger story. And therefore it’s more complex.
Trisha Gee 00:04:34 I think it was something else that was interesting from that piece was, so you mentioned at the beginning, you mentioned polymorphism and inheritance, and I think one of the anti-patterns is quite common, especially when you’re learning to program Java is, is kind of the opposite of encapsulation using inheritance to just kind of like grab everything and expose everything. So my object is one of everything it’s like the opposite of encapsulated. So I think his point was very interesting about how, and I’ve been in interviews where I’ve been asked about polymorphism and inheritance and not been asked about encapsulation about things like, you know, do one thing and do it properly and only exposed to things which are important to the person using this object. So yeah, it was an interesting piece that
Felienne 00:05:16 Can you give a concrete example of a use case or a business case where the situation that Kevin just describes occurred, where you had code that indeed just painted a little bit of encapsulation on top of code and that you may be changed or refactored into using encapsulation as at some Jenna got argues here.
Trisha Gee 00:05:37 I’m not sure I can think of a specific one. I can think of this happening a bunch of times where, especially again, especially using inheritance where you think you have, let’s say a, I don’t know, like a book order object, but with, because it’s using inheritance, it also has like a bunch of other order type characteristics. And you see there’s sometimes it’s bled over from a relational database where your relational database has like flags for is not one of these is one of these isn’t one of those does have one of those. And sometimes you get it because you have this enormous inheritance hierarchy whereby you. Yeah, you’re basically like, I think the example in design patents was about hierarchies for ducks. And so when you have like a rubber duck that doesn’t fly and it doesn’t quite it squeaks, but it probably has a does fly or does quack type method on it. So you can use the use. I have to figure out like, what is this object? Which is the opposite of, of just wanting to programming whereby you should just get a rubber duck and not care about all of the other types of ducks, which may or may not be blowing into its type.
Kevlin Henney 00:06:41 Yeah. I think that that’s one of those areas where you can kind of, again, specific examples. In most cases, it’s not just uniquely because something was unencapsulated normally there’s a bunch of other things going on and it, it starts with the question when somebody says it’s a hundred fields, too many for a class. And at that point, you know, that you just, from the question, you already know something is amiss. And in other words, that you’ve ended up with something that has just aggregated data and a stretcher says, you know, sometimes it’s just like, yep, I’ve taken the database. You know, it’s just like straight, straight in. I’ve just taken the schema. And rather than saying, you know what, some of these are behavioral, a flag is normally an indication of a behavior it’s kind of thing, but there’s no subtyping of the database. So we don’t end up with that rich model in the code.
Kevlin Henney 00:07:28 We end up with a very flat model. It’s just basically sort of data transfer objects with a couple of other methods. And there’s a lot of data. There’s these buckets of data. And then that kind of style permeates through the rest of the code. And then someone comes to maintain it. They add a thing, they add a thing. Maybe somebody else has got the kind of like, yep, I’ve got the inheritance hammer. It’s my turn to hit everything with it. Or I’ve seen this, the idea of like, well, I’ve reduced the number of fields here by pushing them up into super classes. And it’s like, actually that might make the problem worse because they’re all still there, but I can’t see them directly. And now I’ve got protected data, which is so in other words, it’s normally symptomatic of something else. It’s very rarely just the one thing. So I think that’s the thing is normally what you do is you find one spot, you kind of pull and you go, oh, okay, this is connected to, this is connected to this. Yeah.
Felienne 00:08:16 So I said that many of the things that people should know are not so Java specific, but this chapter actually has some Java specific advice related to encapsulation because the chapter says that you should not auto generate setters. So why is this good advice? Why does this help the code to be more encapsulated
Trisha Gee 00:08:36 Behavior? It’s easy. State is hard because once you start having setters, once you start having mutability, then you can’t make any reasoning about what the behavior should be. Because sometimes the behavior is based on if I’ve got one of these or I don’t have one of these and this isn’t no, or that is now you’re mutating kind of the, when your mutation, the state of an object, it’s becomes very difficult to reason about what you’ve got and how it should behave. And in fact, some of this is kind of Java is, is changing to become more immutable first, if you, it’s not many as far as immutable, but like final first or no setters first like records for example, are, which is a new feature in Java 16 we’ll you can create a new record instance with new fields, but, um, you can’t set those. This is like basically an immutable object where you don’t change these because they’re having mutability there to begin with by default was one of those things which led to some of these anti-patterns that we’re talking about. Some of these bugs, which are difficult to debug. Like, I don’t know, now this object has been through these various workflows. I don’t know what it is or how it should behave.
Kevlin Henney 00:09:42 Yeah. And I think that is really, that is that issue is that culturally we have this kind of much more imperative mindset. That immutability is a thing that you ask for mutability is a thing that you get for free. And we kind of moved into a very different time here where people sort of started thinking, you know what? There’s a lot of reasons that’s not true, but that challenge the setters, the auto setters, even if you have something auto generating setters and that’s the problem is we’ve ended up with saying, well, I always have setters or I often have set as it’s become such a ritual that people auto-generate it through their fingers. If, if nothing else is going on, they’ll do it through their fingers. You don’t need a tool to do that. They don’t even know that they’re doing it so often. What you’ll end up with is that kind of a kind of addition that kind of like, yep, I’m putting this here.
Kevlin Henney 00:10:27 And perhaps if you were writing this in a, if you’re focused on the tests, you would see that and go, wait a minute. Why am I doing this? I never actually, I’ve got to set it, but I’ve never tested for it. And it’s that simple idea that asking a question is easy, but changing the world is a lot harder. The way that you can change an object is often subtle and you can put things into invalid states and therefore you end up propagating code elsewhere. That should probably be either not there at all, or should be contained, encapsulated within the object, the encapsulate, the encapsulation boundaries. I’m looking after the state. I’m going to make sure either it doesn’t change or it changes in very well-defined ways. I shouldn’t have other people in the workflow going, Hey, can I just check in on you at this point?
Kevlin Henney 00:11:08 Um, what state are you in? You know, the nightmare scenario is a piece of code that I saw a few years ago, that it suffered all of these things. As I say, there’s normally it’s a system of issues. It’s never one issue. It’s only a system things, big classes, long methods, lots of hands in the code. Um, lots of very quick changes. So there was no kind of sense of architectural consistency or style everything’s kind of in panic mode, but that also led to the feeling when you were reading through the code, that if you asked me, what does this code do? I would probably say, I wouldn’t say, oh, it quotes for mortgages, which is what the system was supposed to do. I’d say mostly this code checks for null and it logs because it was forever. Wait a minute. I wonder if this is, if there’s still no, there wasn’t another a thousand lines ago, but maybe that’s changed in the last thousand lines.
Kevlin Henney 00:11:57 There was a complete sense of we’d lost the model as it were. There was no sense of reasoning. And as Trisha pointed out this kind of idea that you should be able to reason about your code. So you kind of lose that and then it becomes, it just becomes, well, I guess in these times, because they viral, it just spreads, you know, and that becomes a symptom in the code. And that’s the idea, again, encapsulation, it’s a boundary it’s, it’s, it’s trying to keep things contained. And if your rule is nothing changes, then that’s where the containment comes. If you’re all things, is things only change in specific well-defined ways in the way that other objects can use it, rather than how do I change an in-town or change a Boolean that becomes that’s quite different. Um, in that sense, people often tackling it at the kind of like the flag level, rather than what makes sense for this object. And those setters often don’t have the right validation. So you can quite happily put an object into an inconsistent state, which kind of that shouldn’t be that’s, that’s kind of not an object. Really.
Felienne 00:12:52 I think to summarize the advice is that you shouldn’t oh, to generate setters because Saturday is something you should really consider. You should really think what is it that I want here? What, what should, and shouldn’t happen with this objects, if you just generate them, as you said, as a ritual, you just make them either automatically, or you just write them by habits, then you aren’t thinking about you are mobiling or you’re just adding some plumbing,
Kevlin Henney 00:13:16 State change is a privilege, not a right.
Felienne 00:13:19 Nice. That’s a great quote. So I want to move on to chapter six, chapter six is about breaking up problems into chunks. So firstly, I would like to hear, like, what is your summary of this? Because clearly breaking up a problem into shepherd pieces. Yeah. Like that’s a good thing, but what is the core of this chapter?
Trisha Gee 00:13:39 I really liked this chapter from Jean because it was, it’s a common thing that you hear, like when you’re doing small pieces of toy engineering, obviously you’ve got small pieces of what you can do. You can break stuff into chunks when you do real engineering, it becomes much more difficult to break a user story down into discrete tasks. I think there’s sometimes confusion between breaking down something into small pieces of business value, which can be difficult to do and breaking something into small tasks, which can be implemented in, checked in without breaking the code or without making any major changes. And so this is something that she’s, she’s kind of talking about in this piece that we, as developers can often end up working on a piece of code for like two weeks on a business piece of value for about two weeks. And at the end of it, maybe we’ve changed now today, maybe only three files, maybe a hundred files, but like we still haven’t been able to make the smallest possible commit to source control.
Trisha Gee 00:14:35 Or we still haven’t been able to hand over to someone else. And that’s because in our minds we’re like, well, this is a special piece of work. It’s got all these dependencies and it’s not ready until I’ve done everything. But in this piece she takes a couple of examples and shows how you can be like, look, you can break it down into, you know, I’m just going to write, I’m going to output something to the command line. I’m going to read something from a file. I’m going to iterate over it. I’m going to make this filter. I’m going to do this change just because it doesn’t change the functionality in the application as a whole doesn’t mean it’s not a small committable piece of work. So you can still commit the piece of code, which reads from a file. Even if you don’t do anything with that file yet you can still commit.
Trisha Gee 00:15:21 Um, I’m a big fan, big fan of committing like skeleton code, like sketching out code, like perhaps you’ve got unit tests for maybe even larger sort of functional level tests, but they’re not hooked into your main application yet. So you can kind of sketch up pieces of functionality that users never going to see yet because you haven’t plumbed them in, but you can break that down into smaller tasks and commit them. It’s definitely, it’s a skill, it’s a difficult thing to do to break your work down into small tasks. But just because it’s difficult doesn’t mean it can’t or shouldn’t be done.
Felienne 00:15:53 So then how do I know what is a committable piece of work? So, so I am programming and I’m indeed, I’m adding a bit here and there and oh, I’m adding a new feature. So this class needs to change. How do I stop myself from committing this whole globe of change?
Trisha Gee 00:16:09 When I went to at Elmax, which I worked out in London, a couple of like 10 years ago now, a couple years ago, 10 years ago. And I worked with people like Dave Farley, who wrote the continuous delivery book and Martin Thompson. Who’s now fairly famous for talking about mechanical sympathy. And I worked with all these great people who were very well steeped in extreme programming and agile stuff. They kind of taught me some of this stuff. Like one of the ways that you know, that it’s ready to commit is you can have a unit test. So you’ve only added a couple of lines of code. Like I said, it’s not plumbed into the, perhaps the user interface, but I’ve written a method which exposes some functionality. And I have a unit test it, compiles the test, passes the build passes. I can commit that. And you can do that with just like two lines of code or a Java, probably like six cause methods are quite long, but you know, you just do it on a, on a small few lines of code basis. And the thing is that if you have unit tests and we also had end-to-end acceptance tests, if you have unit tests and they pass an end to end acceptance test pass, then you can commit, it’s safe to commit. You know, you can do that.
Kevlin Henney 00:17:09 I think that idea of the couple of points of Patricia mentioned, which are really key in terms of that workflow. The first is that idea of, can we break this down? It is a skill you can break this one down by learning to do it. Often when we approach things, we have one big idea in our head and it’s, it becomes an act of almost performance. I must do it all at once. It’s all in my head and it was now, I’m now going to be glued to my keyboard and it’s going to flow from my head through my fingertips with the assistance of pizza and coffee and all the rest of it. It’s a performance act rather than thinking, okay, what’s the next bit, what’s the next small bit. What’s the bit that moves it towards that. And the way that I work with clients and this, I will say, well, what’s half of what you’re thinking.
Kevlin Henney 00:17:49 You know, you’re thinking something about what’s half of what you’re thinking, but it’s still reasonable. Okay. And what’s half of that. And then the other point about the really simple point of does it work? Not does everything work as I am planning for it to work at some point in the future, but at this point, is it a meaningful step? And honestly the bottom line is, so Trisha is talking about all the really good stuff. Let’s just start with a really simple stuff. Does it compile, okay. Honestly, I have seen, I’ve seen things in version control systems. You people wouldn’t believe and they wouldn’t compile. So yeah, the bottom line is, does it actually compile that really has to be the simplest thing. And then moving up through various versions of it works, you know, the very simple idea of I’ve added something. And is it meaningful?
Kevlin Henney 00:18:34 Is what could I describe what I’ve just done? Well, yes, I’ve just added a method here or I’ve added a special case. We’re not exploiting it elsewhere, but here’s a, here’s a piece of code in the test that demonstrates the existence of that special case handling. And that’s fine. That’s a stepping stone, which I think is the other thing is there’s an older term for it. I picked this one up off Grady Booch years ago in one of his books, about 30 years ago, stable, intermediate forms of just for the, just for the listeners, by the way, I’m only in my thirties, of course I was just very precocious as a job, but I was reading this stuff and there’s this lovely phrase, stable, intermediate forms that he got from Herbert, Simon, economist and general polymath, and this idea of stable intermediate forms that although you’ve got a big goal in mind, rather than having some big bang moment where everything comes together, miraculously or not, what are the intermediate forms that also work?
Kevlin Henney 00:19:25 It’s like walking versus running when you walk, um, you always have at least one point of contact with the ground. Therefore you are stable. You can pause and it’s safe. If you run the definition of running is that you go 0 1, 0 1, and there’s something very binary about that. And developers do love that. They love the running. I must do it all at once, but if you trip the whole thing falls apart, if you’re distracted, the whole thing falls apart. If it is not all complete, then you don’t have a thing. Whereas with walking, it’s like, okay, I can pause now. Yep. I can check that in. I can do whatever it’s on route and it’s stable. It’s good as it is rather than all, please don’t use that. It’s all kind of hanging. It’s all hanging by pieces of string and good hope. So that is that idea. That, and, and I think Jean’s piece is really good at kind of highlighting this and just starting, you know, it’s also quite good in terms of her storytelling, which I think is a, it really brings the piece to life.
Felienne 00:20:19 Moving on to the next chapter. One chapter that’s also caught my attention is chapter 21, because that chapter is about thinking in SQL or thinking like you would in SQL. So it was a big surprise. I was like, wow, this book is about Java. Now you’re saying, as you think, like, I should use SQL thinking. So what is that? What is SQL thinking?
Kevlin Henney 00:20:41 Well, checkup, isn’t it. So that’s Dean OnePlus piece. And what I like about is the, a lot of what he’s talking about, he’s leading with SQL always really in one sense, talking about his declarative thinking if you want to open it up. And it’s just, it’s just that CQL is our natural hook. It’s the, it is the logic programming language that most people know that they don’t know that they know as a logic programming language. So it’s just that opening idea of like, you know, how would I ask a question? I’ve got a whole load of data. How would I ask a question? Well, you know what, let’s set up a four loop. No, that’s not how we ask the question is you stop framing it. I want to select things. Tell me the criteria that matter. Okay. So it’s kind of flipping away the, uh, I mean, we might say one level, it’s inverting the control flow, but actually what we’re trying to do is discard the control flow.
Kevlin Henney 00:21:30 And so, you know what you’ve written loops all your life. You have written all the loops as a developer, you have written all the loops you will ever need to write. You’ve written the loop where you do something for everything in a collection you’ve written the loop where you search for something. There’s only a handful of loops and you have written them all many times. And there’s this idea of like, well, what’s your intention. And it’s that idea that he’s trying to get us drawn into is like, what is the intention of this piece? I am trying to select these from where we’re okay. Under what conditions, what’s the thing that matters in this and really to look at our collections and our data sets from that point of view, which naturally leads you to kind of, yeah, there’s a broad declarative space, but it naturally leads you to thinking in terms of streams, it naturally leads you into having a slightly more, a better relationship with your collections, I guess, rather than poking and prodding them with four loops. And F’s, it’s kind of like, what’s our goal here. Let’s figure out the flow, but not the control flow. Somebody else has already done that. And that kind of thinking is quite powerful. So that’s the thing is you say, you know, Hey, what’s the CQL thinking in the middle of a job. It’s like, what he’s trying to do is make you recognize you already know this stuff, but perhaps haven’t had the opportunity to bring it home. Um, you know, you do it in one language,
Felienne 00:22:43 Brittany and home bringing it to Java because as a former C sharp developer, I of course think about link about actual language features that enabled this SQL, like thinking, is there something like this in Java harder language features or concepts that support this form of thinking, yes,
Trisha Gee 00:23:02 It’s fairly recent in Jarvis history. So Java eight got the streams API, which Kevin referred to. So finally we could, instead of iterating over and pulling stuff out of our collections, we could say for every one, well, actually the worst one is for everyone do their thing, but better. It would be like filter this collection for something which looks like this order by this, you know, as the streams came in Java eight. And that’s one of the things that really helped me get my head around the streams when that came in, was thinking about SQL the fact that you would be like, you know, instead of you don’t tell the database how to get his data, you tell it what you want and kind of turning the thinking on its head was what was required to understand how streams worked.
Kevlin Henney 00:23:44 And there is a difference in the sense from C-sharp because the link stuff, if you like, it’s the way that streams are represents. So the two things happened in Java, right? It was one was the streams. And the other was Lambdas that gives you that richness. And those were in C-sharp sooner, but link added an additional layer of sugaring over the top. If you like what you’re getting jobs, there’s no extra language support, but what, it’s the link unlinked. In other words, if you de-link, it, you start looking at what’s there, the dot where, and all the rest of it. That’s what you’re getting in Java is as if you’re writing the raw version rather than the syntax rugged version. That’s the distinction there.
Felienne 00:24:21 The next chapter that I want to talk about is chapter 43, about type inference. So as I said, I’m not much of a Java expert. So I actually learned from this chapter, that’s in Java 11, whereas local variable type inference in Java, what is, what is local variable type inference?
Trisha Gee 00:24:39 It’s just a long way of saying that you can type VAR instead of your type name on the left-hand side. So there’s always been a lot of criticism about Java being full of boiler plate. And one of the things is, for example, like in the, in the very old days, you used to have to say, lift string, my list equals new array list string, and everyone’s going, why do I need to say all of those things? So many times Java seven introduced the diamond operator. So you didn’t need to say this, the string inside the Chevron’s inside the generics, like on two sides and Java, technically Java 10, which starts in Java 11, introduced local variable type inference so that you can now just say, VAR, my list equals new array list string. And so, and it does what it says on the 10 it’s type inference.
Trisha Gee 00:25:25 It’s not one of the misleading things is some people think it’s a bit like Groovies Def where you kind of have a kind of fluffy type of dynamic typing. But, um, but it’s not. It’s like if I can tell from the right hand side, what the type should be, I will use the right hand type instead of you having to literally type it two times on each side, but it’s local variables. So it’s inside methods only. You can’t use it fields. You can’t use it for parameters. You can only use it for methods, for variables inside your methods.
Kevlin Henney 00:25:50 And I think that’s quite nice from that point of view that it’s a kind of agreement between, it’s a kind of like a three-way agreement. It’s it’s you the code based on the compiler. It’s like, you’re looking at it again. I know what the type is, the compiler’s going. Yeah, I know what the type is. And it’s just like, well, why do we have to tell the source code? The type cause you and me have already agreed on this? I can tell, look at the thing on the right hand side, you know, we all know what it is. Why do we have to spell it out again? So there’s that, but it’s got a little bit of restraint and that’s the point? The Trish settlement is just like, you know what, if I put this everywhere, if it’s local, then I can see everything that I need to, the minute I start hitting the field level, it becomes a little more brittle, both from the reader’s point of view, but also some of the changes that you could accidentally make in a field initializer that suddenly changed, actually changed the representation of your class, which is probably not what you planned.
Kevlin Henney 00:26:36 So there’s reasons to put a little bit of restraint. And so, you know what, in the privacy of your own method, we’re all good. We can see stuff we can, everybody knows. And there’s very few surprises or opportunities for surprises. It’s kind of like a, an agreement with that. And so it does ease the, I mean sometimes when people describe the languages strongly typed, it’s just like, yeah, and I’m typing and I’m typing and I’m typing, you know, there’s a lot of letters there. That’s why we have also completion because there’s a remarkable amount of typing otherwise. And really that’s still heavy on the eyes. So it just eases that. And we see this in a number of other languages. You mentioned C-sharp for that, that had that. We find that in functional languages with Henry Milner type systems C plus plus got an equivalent thing, everybody’s kind of going, I think we’ve gone through the idea that we all know what we’re talking about. Let’s let the source code acknowledge that too. So it picks up on a valuable trend there.
Felienne 00:27:26 I think what you’re saying is that it doesn’t only save you time in typing and actually typing the characters, but it also makes your code more readable because you don’t have this double irrelevant information that you still have to process.
Kevlin Henney 00:27:40 Yeah. You have to do a lot of, one of the things that if you like, that has happened since there’s a few features that allow the code to find its way a little bit further left towards the reading line, you know, it says there’s a lot of Java code that kind of wanders off the right-hand side of the screen. It’s just like, oh, come on, hold yourself back in. You know, we’re still human. We still have a limited ability to read really long things. And it just shores lines makes things accessible and readable. The most interesting thing is normally the variable name. What role is, I’m going to see this variable name again many times. So it’s introducing yourself. Hi, I’m this variable. Guess what? This is what I’m initialized to. And you know, I take my time from that rather than here’s a whole load of ceremony, like giving somebody a whole load of honorific titles upfront and we still don’t know what they’re called. It’s just like, I am senior principal, dah, dah, dah, dah, dah. Yes, but what’s your name? What do I call you? It’s now. Okay. You know, hi, I’m Fred and here’s all the other stuff. Should you care? It’s not hidden away. It’s all there. It’s just that we avoid having to repeat it. And we put it in the right place.
Felienne 00:28:42 Yeah, that totally makes sense.
SE Radio 00:28:46 Elastic enables the world’s leading organizations to put their data, to work using the power of search, whether it’s connecting people in teams with content that matters keeping applications and infrastructure online or protecting entire digital ecosystems elastic search platform is able to surface relevant results with speed and add scale, learn how you can get started with elastic search platform for free at elastic.co/se radio.
Felienne 00:29:15 Moving on to chapter 54. This is your, your own chapter Tricia, because many of the chapters are with them by your coauthors. But this is your own personal chapter in which you argue that your IDE and then a specifically JetBrains can do a lot for you. So I’m really curious. What are some of your favorites tips? What are things the IDE can do for me that I don’t know yet? So I have so many tips for using the IDE. Most
Trisha Gee 00:29:41 Of my conference presentations are about how to use the IDE. We had a whole intelligent day conference last year, last week, which was two seven hour days of content on how to use the IDE, which should be available on YouTube if anyone’s interested, but like, um, try and restrict us to a small number of features. We were talking earlier about things like type inference, where it makes the code easier to read sometimes, but sometimes losing that typed out type information makes it more difficult to read the idea. You can help you read your code with things like type hints, both for, um, local verbal type inference. And also for things like parameter names, parameters, the path into methods. So for reading code navigating code, the idea is really, really helpful generating code. We talked a bit about why not degenerate code, why not degenerate setters, but, um, in Java, there are times when you are going to want to generate getters setters, hashcode equals constructors to string, and there is really no need to write that stuff out.
Trisha Gee 00:30:41 The idea you will do it for you. So by all means just use the co-generation features. Another part of cogeneration that I really like inside the IDE. And again, it comes back to that. It’s the fact that I like writing unit tests. I like to run my unit tests. First. I like to code. I like to write the test to code against the API the way I would like it to be. So instead of using your classic IDE features, which is code suggestions and code completion, do the opposite type out all the code, the way that you expect it to be. And if the idea says this method doesn’t exist in the shape that you made it, then it will create that code for you. So that allows you to think outside in it allows you to define the API the way it makes sense from the calling point of view, instead of writing the internals of the class and then trying to expose it in a sensible way.
Trisha Gee 00:31:29 So I liked that kind of outside in cogeneration favorite features as well. See, I told you I could go on about this for ages. We factoring particularly insight, intelligent idea, but all of these features are available inside your favorite IDE. It doesn’t have to be intelligent idea, but the refactoring tools renaming, you should not be doing a search and replace. You should be using the refactoring tools to rename your methods, your variables, your classes in all the places they need renaming and know the idea will do it correctly. So everything’s still compiles. These automatic refactoring tools mean that everything compiles you don’t have to recompile and fix things up afterwards. And that’s what you can rely on your IDE to do your idea uses the compiler. It uses its own internal logic to figure out like, what is the right way to do this? How do I keep the code green and make everything still semantically the same as it was before?
Trisha Gee 00:32:19 So refactoring is like one of my favorite things. And then just one last thing in intelligent ideas, specifically the inspections. So inspections cover a whole broad range of things like, oh, have you thought about doing this for loop as an enhanced four loop instead of an index for loop, it does things like now you’re using Java eight or beyond. You could use the streams API. And in particular, I liked the fact that the inspections in intelligent idea will help you migrate to modern versions of Java. So it will tell you things like you can use the strings API on Java eight. Isn’t so modern anymore, but streams API, you can use local variable type inference. So you can use VAR if you want to new features, which will be coming in Java 16 include records. We already have records and pattern matching for instance of, and we now have things like text blocks and switch expressions. These are all things which kind of help get rid of some old fashioned looking Java code and turn it into something more readable, more succinct, and just generally prettier. And the idea would just say, did you know, you can use the new features in Java, so you don’t need to go and find that stuff out. So that ID will do that for you. So that is a not so quick summary of some of my favorite features inside the ITE
Felienne 00:33:34 Gatlin. It’s only fair if you also got to talk about your chapter. Of course. So your chapter is 85 and your chapter is about checked exceptions, which is a really drive a specific thing. So firstly, for the people in the audience that are in Java programmers, what are checked exceptions,
Kevlin Henney 00:33:52 Right? It’s checked exceptions are exceptions that the compiler will check, um, as opposed to the runtime. In other words, there’s a, basically anything that derives from anything that subclasses from exception or actually throw a ball, but it’s not also a runtime exception and is not an error. In other words, these are kind of like platform level errors and runtime exceptions are kind of like the ordinary small change, uh, exceptions that you might expect. Oops, I index past the end of an array type exception. Oh dear. I seem to have dereference to Knoll type of exception. In other words, small change ones, the ones that I like to happen everywhere, because they’re going to be really noisy. They get an exemption from this. There was this idea with checked exceptions of why don’t we make the exception modes of a method. Why don’t we make that part of the type signature?
Kevlin Henney 00:34:41 And this is one of those kinds of ideas that sounds initially quite good. It’s quite well-intentioned. In other words, the regular signature of a method gives you the happy day behavior. I passed these arguments and I get this result back. We’re all good. But what happens when it goes wrong? Well, let’s acknowledge exceptions as first class in that sense and, and have a throws clause that shows you the exceptions that are thrown. This is great. In theory, first language that I know of was that did, this was Barbara Liskov PLU language. So 1970s, that language hugely influenced languages after it with the exceptions, but there’s this idea of you making it part of the type system. And then you start trying to build things. You start trying to build larger code bases. You start trying to build things that have interfaces that evolve and that you give out to other people.
Kevlin Henney 00:35:31 And it turns out that having the Czech exception there becomes an annoyance because the compiler will not let you not handle a et cetera. If it sees you’re calling a method with a checked exception, it will say, well, either you need to catch that in this method or you need to publish re-publish that exception in your own signature, which unfortunately has led to a lot of code where people just simply catch and kill. It’s just, oh, this is so annoying. I’m going to turn a good part off. Or they just cash exception, wrap it in a runtime session, which as it were, is still flowed and bubble it up anyway. And the point here is that in large code bases, it has turned out and this is an important thing. This is a feature of the Java language. It has nothing to do with the JVM.
Kevlin Henney 00:36:12 The JVM is utterly oblivious to this kind of stuff. Other JVM languages don’t use it. The experiment was an interesting one and actually I’d cite a C-sharp rationale. C-sharp doesn’t happen because of the Java experience. It’s kind of like, yeah, we saw what happened there. It didn’t work out. You know, we understand that it’s not like the type signature. I think the way that I tend to put it, uh, is, um, Tolstoy’s Anna Karenina, all happy families are the same, but each unhappy families unhappy in its own way. It turns out that the ways in which you might want to classify failure are quite variable and change over time. Even though the happy day scenario might remain stable and you might, and we suddenly discovered there’s also a loss of encapsulation to refer back to our opening consideration is like, you start perhaps unintentionally, but in a larger code base with lots of developers, it evolves that way.
Kevlin Henney 00:37:02 You start publishing details that are actually quite private. So, oh, you’re throwing back kind of exception idea. Okay. So it becomes a real grind and it starts adding to the boiler plate that Trisha was talking about. You end up with a lot of stuff, oh, you’re killing these exceptional. You have to republish them. And every time something changes your interface suddenly become unstable. Even though its intention has remained stable. So it’s one of those things great in theory, but not great in practice. And that became it’s that idea. Also, when you start doing plugin architectures, there’s a lot of issues there and having code execute through things again, do I need, whose exceptions do I need to publish? You know, it starts becoming an unnecessary set of negotiations for code that would otherwise work. And, and Landers also kind of came along well a bit later, but nonetheless, it’s that case of like, well, the land is in Texas intentionally light.
Kevlin Henney 00:37:51 It takes a very different philosophy. And so there’s this idea that in many projects anyway, there is this idea of like yet we don’t use checked exceptions anymore because they’re a bit of a burden. We only use the ones that exist in the platforms that we’re using, but don’t make your own is basically advice. But the reason that advice is there is because still we find people are taken with this attractive idea, this idea that in theory, this is a good idea and advocating it’s just like, okay. Um, so my piece is called uncheck your exceptions. It’s just like, yeah, it is a nice idea in theory, uh, nobody’s doing anything because they, they mean to cause problems for API evolution, but actually in practice, we’ve learned that and you know, every language has been around for more than a few minutes has picked up something that it’s probably regrets. It’s like families, you know, it’s just as this, there’s something there there’s a, there’s a sense of regret. Like, yeah. Okay. That was a nice idea. It didn’t work out, but we’ve got other ideas that did.
Felienne 00:38:46 So your advice in short is just don’t use checks, exceptions, if you can avoid it.
Kevlin Henney 00:38:51 Yeah. You’re creating your own. Don’t go down the path of creating hierarchies of checked exceptions because we ended up trivializing. And what you end up with is people create code. They say, oh, well, you know, it’s such a burden, tell you what we’re going to have my library exception. And all of those things will basically inherit from that. And then you end up losing the original intention, which was to be specific. You just say, yeah, we’re just going to throw the root exception. And we’re going to put that in the signature. It’s like, well, we’ve actually lost that utility of it throws an overflow. It throws an underflow and that’s it. It’s now it throws something from a library and it’s tended towards the top. And in the worst cases, you’ll just see people go throws exception. There we go. That should cover all since
Felienne 00:39:31 There’s one more chapter that I found specifically interesting, and that is chapter 80. One about go routines, go routines are described as a lightweight alternatives to stretch in Java, but I think many people might not be aware of what code routines are. So let’s start with that. What are code routines and what is an example of a situation in which your code routine could be useful?
Trisha Gee 00:39:52 One of the things I liked about this chapter is it actually explained code routines to me for the first time. And I was like, oh, now I get COVID routines. So I definitely want to recommend people actually read that chapter in the book because, and specifically coroutines in Kotlin. And so it’s a JVM language, something Kevin and I wanted to put in the book was not just Java, the language, things that Java developers needed to know, but things from other JVM languages, especially because some of those features may find their way into Java, the language in the future. But I think a lot of Java programmers like me are like, I don’t really know what coatings are or why they’re useful.
Kevlin Henney 00:40:27 Yeah. I think, I think the thing about the coaches is really nice together. Cause we were hoping for this language diversity, but then to get something very specifically on code routines is nice because coaching is kind of making a bit of a comeback. And it’s one of those things of, I think a number of languages in the last decade have kind of added them in Kotlin being, um, kind of a poster child for this price and formally acknowledged that it had them. It had them all along in one sense generators and things like that, but properly, formally acknowledged that have them. And we’re seeing these kind of features creeping in two languages. And what I love about this is that coatings are really old and they were just fading when I entered the workforce. And I say this as a young man in his early thirties, of course, but how was entering the workforce?
Kevlin Henney 00:41:07 They were just kind of going out and we will at the point where process creation was becoming cheaper, people were talking about processes, we’re also moving to event driven architectures and then we’re on the cusp of threading and then threading became a big deal. And you know, there was that, and that kind of was the question about how do I express the idea that I wish to have concurrent activation of things, not necessarily, you know, we’re talking pre multi-core not necessarily actual true parallelism, but at least concurrent activation. I don’t want to have to keep starting up and shutting down state machines to remember a thing that I already had encouraging is used to be part of that answer. And they’re a very old mechanism, Melvin Conway, who is, uh, St Conway’s in Conway’s law, uh, Tommy’s law was identified in 1968. Melvin Conway invented the co routine in 1958.
Kevlin Henney 00:41:56 So not a new idea at all, but they used to be the only way to really express this kind of idea. And they used to be part of the object paradigm. So similar 67, 1 of its big deals was what objects exist in the world concurrently with one another. You don’t leave an object and it loses its memory and its state. You, you can go back to it. So similar hand, co-wrote it. So it was there all along, but we’ve had so many other mechanisms that have come into languages that we kind of displaced this, but what’s nice about coatings is they are simple. You don’t get race conditions, you don’t have all of that. I need to remember to synchronize this. I need to remember to lock this and unlock that. And you can’t have a race condition with a code routine. It just simply says, I guess you’re offering example.
Kevlin Henney 00:42:36 A very simple example is just simply the idea of, okay, you’re Alexa, you’re Alexa, I’m a pauser. You break down some tokens and I’ll figure out where they fit. And it turns out that just give me the next word is a classic example. Just give me the next token. Give me the next token. I don’t know what state you’re keeping about that. You don’t need to be a full blown object. You’re just running a loop. But the fact is that loops shouldn’t have to be spread across multiple methods. It’s a loop I’m going to return you something. We don’t want to lose the loop state. So people choreograph all kinds of difficult code around this. And in fact, I think most of the kind of SACS code that was written in the late nineties could be eliminated with, with code routines simply because it’s a case of like, I just want the next thing, that’s it.
Kevlin Henney 00:43:15 You’ve got state about how to manage it and I’m going to continue this. And I’m asking you one question at a time. There’s no simultaneity. There’s no parallelism here, but we’re both like we are partners. That one is not subbed to the other sub routine. We are co with one another, we’re both active and we’re just exchanging. We’re just having a conversation taking turns. And that seems an incredibly reasonable thing to have in a programming language, but culture and history kind of dodged it out of the way, but we’re kind of realizing that many of our concurrency problems are actually a lot. Well, we’re creating them rather than solving them. And just coatings are a very simple way of doing that. And when we lock them into the, those other tasks that people say, well, this is why I was threading. It’s not only something like asynchronous IO or timers and things like that. And once we recognize it’s actually many of these things come down to a really simple class of problems as well, right? Why don’t we just want to code routine for that or hide that away. And then suddenly life becomes a lot more single threaded, which is a lot easier for us mere mortals to reason about,
Felienne 00:44:15 Okay, those were all the chapters that I wanted to cover. But I was also really curious about the process of writing the book, because we’ve alluded to this already a little bit, there are many chapters written by other people, and then you wrote a few chapters also, and then you edited the book with the two of you. So how did you deal with different chapters giving conflicting advice? What are chapters that were like mutually exclusive like, oh, we have to pick either this one or that one. How did you manage different opinions? And because the book does feel like a whole that is somewhat consistent. I’m really curious how you did that.
Trisha Gee 00:44:52 I actually wanted conflicting opinions in various places where we didn’t disagree with their opinions. I think so. For example, like Kevin just talked about checks, exceptions. We were kind of interested in maybe a piece, which was like the, you know, stating why checked obsessions is, would be a good thing when there’d be a good use case with certifications. My colleague Malheur wrote a piece about why certifications are very valuable. And I went out and sought a counter piece to that because I know a number of my friends and ex colleagues are much more anti certifications. Interestingly, by having those different points of view, you can actually come to, they don’t necessarily contradict each other. So for example, the certification one was like, you know, that the computer science answer for everything is, it depends. So the certifications one was, if you need to do this, so it’s vacations might be a way to forge that path. On the other hand, if you’re looking for a particular type of person and certification is not going to take these types of boxes. So it’s quite good to get what looks like on the surface conflicting advice, because actually helps you wake up, you know, sometimes it’s this and sometimes it’s that.
Kevlin Henney 00:46:02 Yeah. And that was something that we were both very keen on this idea that although we have our own particular perspectives, as Trisha said, when there’s something that is genuinely wrong. Yeah. We’re not going to do that. It’s a case of like, should I sell my grandmother? Well, no, no. We’re not gonna have a counter piece to you. Shouldn’t you should, that doesn’t make sense. And if you’re going to have an argument with the compiler, you’re going to lose, you know, in other words, anything that’s syntactically wrong. So there is a kind of a right and wrong here, but there are so many things that are, it depends. And in those cases, just giving people, giving the reader, this is not a book by one person. This is a book by many people. And so therefore we’re trying to show you sample the landscape and sample the views.
Kevlin Henney 00:46:41 They’re out there in 97 things, you know, it’s not a perfect sample, but we’d like to give you that representation. And that’s quite important because otherwise it makes it sound like there is a, a foregone conclusion that there is a right answer in a case where actually maybe there’s a bit more discussion to be had. And regardless of our own opinions on some things we recognize, well, that’s my kind of opinion here, but you know what? There are decent people who don’t believe that we’ll have some points to make against that. So we want their voices as well. So if this were a single book with a single storyline that had to be coherent, that would be a very different kind of thing. But we actually have an opportunity here to say, Hey, look, here’s the range of thinking you, the reader, get to figure it out for yourself. And that I think is quite important because in those cases where there isn’t a fixed answer, you’ve got to show that the landscape’s a bit bigger. A stretcher was pointing out that these things are often complimentary. They sometimes appear initially contradictory and you can see a few things where they don’t agree, but then you suddenly see that actually there’s more to this than meets the eye. And that’s that, you know, it’s that multiple points of view that becomes valuable.
Felienne 00:47:44 Yeah. And it is often of course this, it depends what might be very good advice for one situation just doesn’t really fit. It’s a totally different company or a different type of programming language.
Kevlin Henney 00:47:54 And again, that kind of informs why we were really keen on getting some representation of other JVM languages. Otherwise it does look like that. You know, it’s only job. Well, no, it isn’t, there’s a lot of other things going on there. So I think that’s quite important. And that’s something that you can do more easily with more people, which is the structure of the book
Trisha Gee 00:48:12 As an editor. It’s kind of challenging when you found pieces that you disagreed with, because you were like, okay, I don’t necessarily agree with this, but is it that I don’t agree that cause it’s wrong or is it, I don’t agree with it because it’s against my opinion. And it was as an editor, it was really eye to have those sort of internal conversations of like, oh, I’m going to have to open my eyes to other points of view here. Yeah.
Kevlin Henney 00:48:33 That’s and so it was kind of interesting when we were going through because we received all of these pieces, some of which people contacted us with some of which we went out and sought and we had, there’s a whole load of articles up on medium that were kind of published through that. Initially it was kind of like a trial space, but also people were able to submit through a form and Google docs. So we’re getting all these things from different sources, different people. And obviously we get more than 97 things. So we have to, there has to be a decision process. So we had to, you know, kind of from the beginning based on my previous experience, because I edited 97 things, every program should know. One of the things that I found was useful is make sure that we limit the number of contributions from an individual, because otherwise there can be too much, no matter how brilliant their pieces are.
Kevlin Henney 00:49:19 That’s the problem. Sometimes that’s the most frustrating thing is like somebody gives you all of these wonderful ones and we have that more than once people giving us loads of great stuff. But actually the whole thing is to give voice so limit the three, that was our kind of like, that was our cutoff, but I’d also boost the number of people that ultimately get represented in the book. That’s what you end up with when you, um, sort of cap it, but it does mean that you’re kind of looking sometimes you’ve got two pieces of advice that do say the same thing and you kind of, you’re looking for a reason to decide between one and the other. So Trisha and I had a number of conversations, some of the different categories. Yep. This one’s easy, this one’s in, this one is easy. We’re not going to include this one.
Kevlin Henney 00:49:59 And then we had this kind of gray territory, this in between kind of like, oh, I like it. But, or we’ve already got too many pieces from this person and so on. And those were the ones that attracted discussion. So which I wouldn’t, I would never sacrifice that because I think that’s part of the joy of this and you end up learning more about it. And where did you make the case on the whole? We were pretty much on the same page. I don’t really think we had any kind of like anything that was contradictory. We just sometimes would want to cast a vote for one rather than another, but we ended up fairly, you know, fairly much in the same space. And honestly, I’m going to say it was actually easier choosing these 97 with Tricia than when I was the sole editor of 97 things. Every program I should know. I honestly, I probably disagreed myself a lot more. So it was kind of interesting just that process, but you’re getting somebody else’s point of view and w it creates a balanced whole and Trisha and I come from very different points of view when it comes to this. So that I think helps the roundedness of the book and the kind of what gets included and what gets represented and who is in there.
Felienne 00:50:56 Yeah, that makes sense. Because as I said, from the reader’s perspective, it does feel like a consistent group of tapes or things. And even though sometimes within a chapter, different viewpoints are being presented as a whole. It feels really as consistent story. Are there any of your favorite chapters that I might’ve missed? So we have go for the ones that I thought were most interesting, but maybe you also want to say, well, if you are reading the book, then you definitely shouldn’t miss chapter.
Kevlin Henney 00:51:25 It’s a car that I play for years, which is I don’t pick favorites. And I wait for people to specifically raise what a, you know, that’s first of all, mine, because otherwise I know that what normally happens is either it’s the thing that most recently occurred to me. It’s like that thing when somebody asks you, you know, what’s your favorite film or what’s your favorite? Sometimes you think you have a favorite, but sometimes it’s just the thing that you thought about most recently. And so you, you end up with a recency bias, which I’m not going to play favorites like electrician do their shots, but I’m not going to play favorites with this one. Yeah, no, I am going to make a recommendation. You see there’s 97 things, one through 97, honestly, read them all
Felienne 00:52:00 That is cheating. What about you, Tricia? Do you have any favorites? Well, apart from, I guess your own chapter,
Trisha Gee 00:52:06 So mine are obviously my favorites. I actually, I’m a bit more general than that. One of the things I really liked. So I joined halfway through the project. I didn’t start off the project I joined to edit a bit later on. And one of the things I quite liked with what we had when I joined and the pieces, which came a bit later on as well, is that we had a lot of stuff on automated testing and that the value of automated testing, good ways of doing automated testing. And I’m a big fan of that because I kind of discovered automated testing a little bit later on in my career, early in my career, I saw J unit testing and I was like, I don’t really get it because I tested it always failing. So once I worked for somewhere where automated testing was like, it really works. And it really gave you the confidence to do your refactoring. It gave you the confidence to do these small commit that I was talking about later. Then I’m just passionate about anyone who can talk about why automated testing is
Felienne 00:52:57 Great. Then that concludes the episode for today. Where can we read more about this book? Of course we have some links. I think that we can put in the show notes, the link to the book, other places where we can read something about
Kevlin Henney 00:53:11 There is a Twitter stream at 97 under school things. Um, if I remember the youth, the joy of underscore, I see seven things. For some reason, it originally disappeared and yes, it is 97 underscore things. So if there’s any kind of announcements where there are other books in the 97 things serious, but we kind of, uh, it has a slight bias to the Java stuff. The moment the stream, there’s also the medium blogs, no seven dash things you can dig around that and find kind of early drafts of many of the things that became chapters. And I think honestly, if you just Google, could I, some things to such a distinct number or such a distinct phrase, you’ll find some of the other books in the series, but if you put nice everything’s Java that narrows it down really quite quickly
Felienne 00:53:55 Also make sure that we put a link of course, through the Twitter or to the medium blog and to the book directly in the show notes. So it’s easy for people to check it out.
Kevlin Henney 00:54:02 Yeah. And you can find every now and then it’s got a little discussions that pop up Trish. And I did a co-branch thing last year where it was kind of the book of the week and focused on that people ask questions we responded and so on. So, so yeah, there’s a, there’s a few things around and about and some very, uh, very nice reviews that are not Amazon or a Riley based around. So yeah, there’s the good stuff’s out there.
Felienne 00:54:25 Oh, great. Thanks both of you so much for being on the show today. Thank you. Thanks very much. This is Felina for software engineering radio.
SE Radio 00:54:34 Thanks for listening to se radio an educational program brought to you by either police software magazine or more about the podcast, including other episodes, visit our [email protected]. You provide feedback. You can comment on each episode on the website or reach us on LinkedIn, Facebook, Twitter, or through our slack [email protected]. You can also email [email protected], this and all other episodes of se radio is licensed under creative commons license 2.5. Thanks for listening.
[End of Audio]
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
Nice Interaction with Book Authors. This will help in understanding book contents directly from the authors.