Real-World Java

Introduction and Book Overview

Barry Burd: Hello and welcome to this edition of the GOTO Book Club. My name is Barry Burd. I'm a professor of mathematics and computer science at Drew University in beautiful Madison, new Jersey in the United States. But you don't want to hear about that. You want to hear about this book today. I'm going to hold it up. Let's see if the camera gets it.

Yes. Real world Java with the subtitle helping you navigate the Java ecosystem. Mike, my guests are Victor Grazi and Jeanne Boyarsky. They're here today to talk about their book. Folks, why did you decide to write this book?

Victor Grazi: I'll take that. When you come out of school, they teach you all about learning. Let's say you're learning about Java, so they teach you all about Java, how to write a loop and how to write an if statement and how to do good. Java composition of code. But they probably don't spend a lot of time teaching you about the vast ecosystem of Java, right?

They don't teach you that. Maybe they'll spend the day on git, or they'll spend a day on logging, if you're lucky. They really don't cover all of the things that you really need to do to get into the enterprise. If you want to get into a job in the world of Java development. There's so much more than just learning how to code.

There's learning how to write tests. There's learning about tools. Very popular tools that might be, that might be used in developing Java. There might be people struggling with concurrency. Even experienced developers struggle with concurrency. How do you tame that beast? So all of these things are things that, if you're lucky, they'll spend a day or two in a computer science course.

So we decided to cover those.I think when I was younger, I always had an idea to write a book called Hello World, where you would be able to write little, you know, snippets of code based on all kinds of frameworks and, and things. And in a way, this is kind of that book. It's a lot of introductions to the things in the Java ecosystem that you're going to need to be very familiar with, very comfortable with, if you're going to get a job in the enterprise.

Barry Burd: So do I understand that this book is for beginners, or is there a wider audience?

Jeanne Boyarsky: It's to a wider audience. So you should know the language of Java, right? If you don't know how to write a loop and you don't know how to write a class, you should pick up a book on that and come back to this one. Yeah, this is meant for people who either just learn Java and they're ready to learn what's out there, or they've been doing Java for a long time, but their employer is stuck on Java 8.

They need to know what things are out there now for people who are changing from other languages and, you know, learning languages. The easy part, right? Learning the ecosystem a lot. So like say you're a Python developer, you know, pi pi. Well what's the equivalent in Java? You can get up to speed very quickly for any of those groups.

Barry Burd: So give us some of the chapters. Tell us what some of the chapters are. For example, what are the topics in the book?

Victor Grazi: Okay. So I could take that. So, I think my favorite chapter to write was the chapter about the IDE. I'll come back to that in a second. But we also have chapters on, you know, a very important part of, of a job in Java, in the Java world is learning how to do Cicd.

Continuous integration, continuous development, how to, get your code to build, test, deploy, how to write tests. So we have a chapter on that, how to do version control. I remember when I was a young guy and I was first starting out in the world of Java. I was building this, this application called Supermarkets to Go.

We were going to start the next big.com company, and I would write some code, and before you know it, you know, something broke. I had to go back and figure out what it was before. I didn't know anything about version control. And somebody taught me about, at the time, it was CVS. What was it called?

CVS. So we learned about version control, learning how to save your state. Go back to it. So now we have a chapter on git, and other version control systems. We have a chapter on logging. Right. Logging is very difficult. People think you just write a log message, but when you're trying to build a new application and integrate dependencies for logging, there's always this, like, it throws exceptions and there's extra dependencies that you don't need.

And so you have to learn how to do exclusions. So we covered a chapter on logging. Spring. Spring is almost as important to the Java ecosystem as Java itself. And so we have a.

Barry Burd: Every talk that I go to has something we do in spring. Yeah.

Jeanne Boyarsky: And advanced stuff too. So spring covers from the basics to advanced. We have a performance. We have Lombok. We have regular expressions. We even have a chapter at the end for things that didn't fit into other chapters. So those things are covered more briefly. But there's an appendix that covers XML and Json. There's a little bit about what you need to know about the terminology of Java EE.

If someone says to you servlet, you know what they're talking about, right? The idea was to get you up to speed so that by the time you're done with this book, you can read any vendor documentation or anything about the Java community and understand what you're looking at.

Recommended talk: JetBrains IDE Developer Productivity & Code Generation Support • Garth Gilmour • GOTO 2024

The IDE Chapter

Barry Burd: So let's talk about the IDE chapter. That's your favorite, right? One of them.

Victor Grazi: That's my favorite because I wrote that one. Right Jeanne.However. I think if you were hiring a carpenter, you would not give them a set of plastic tools and test them on, you know, how they use these tools. I think that we are doing that in the development world.

When we hired developers. There's a tendency in the world to give people hackerrank or something, and they'll put you in front of a hackerrank IDE, which doesn't look anything like the idea that you're going to use in real life. I think that you need to test you as an experienced developer on how you use your tools.

If you're a carpenter, I'm not going to give you a plastic grill to test you on. I'm going to give you the real stuff. So I think that that's a mistake that we made. And I think, you know, when I do an interview, when I'm interviewing new developers, one of the first things I ask them is, which do you use and what's your favorite, what's your favorite?

Refactoring. Right. There's a refactor menu in every IDE. What's your favorite one? you could be surprised how many people don't even know that it's there. And this is something that an experienced developer really needs to know. How do you do an extract method? How do you do or rename or you know, find code snippets, common code snippets.

So these are really important things. And for us personally, I think there's an old adage that says, never discuss religion or politics or your favorite idea in mixed company. I think my preference is definitely an intelligent idea. And so we spend a lot of time discussing that, but we also discuss Visual Studio, which is coming up, very, very strong.

And also Eclipse, which is, you know, I think the legacy development environment. So we discussed that as well.

Jeanne Boyarsky: What I like about this chapter is it's one that we both contributed to all the chapters in the book one person wrote and the other person edited. So we had them put into all the chapters. But for this one, Victor both wrote the majority of the chapter, the intelligent part. And then at the end of the chapter we have.

Here's how you do these same things in Eclipse and VS code. And I wrote those parts. So it's cool as a chapter to talk about here, because it's one that we both actually type some of the parts of the book and not just edited it.

Victor Grazi: Okay, I just want to mention something. If I were writing this book alone, it would probably come out a lot different, maybe a lot more boring. But having Jeanne involved in it and like, we were bouncing things off of each other. So I would write a chapter, and then she would always read the chapter and always make, you know, vast edits and the same thing the other way around.

Jeanne would write something, I'd make changes or suggestions. So, I think as a collaboration, it's it's really important to have this, dual editor, dual authorship. Yes. Yeah.

Jeanne Boyarsky: It also helps with who likes what. One of the things we did early on is we rated each chapter on a scale of 1 to 10 of how much we wanted to write that chapter, and then we use that as data to negotiate who would be the primary on each chapter. There was one chapter. We both voted ten on the one, it was the regular expression, the chapter.

So for that one, what we agreed upon was that I would write that chapter, and I would also write the chapter that we both go to the lowest on, so that it would be fair.

But it was a good way of carving up the material and how those apart, we had different ratings, so it worked out just fine.

Barry Burd: How did you make sure that your writing styles for the chapters were the same? I was fascinated by that. As I read the book, I was trying to figure out who wrote which chapter, and the only way that I could figure that out was if there was an example in it that used one of your,

About, the, the, the writing style from one chapter to another or was that not an issue?

Victor Grazi: I would, I would say that it's what I said, you know, we we both read and edited every chapter that the other one wrote. So in the end, I think the style that you're seeing is really a collaboration style. If I had written the book alone, every chapter would have been vastly different and probably the same with Jeanne.

Jeanne Boyarsky: Yeah, I agree with editing. There's voice. There's a few things we agreed early on that, you know, we're going to say we and not I. And when you're editing and you notice things that aren't like that, you change it. If there's something where it's like, oh, that really feels like it's one person's voice, let's change it a little.

You want it to be a cohesive book, because I've read books that are written by seven people and like, it feels like these people have never talked to each other. You know, this might as well be a series of blog posts. The book should be cohesive. And also you need to know what's in the chapters. You need to know everything that's in each chapter so you can make back references and not have one chapter.

Introduce something in the next chapter. Be. Let me introduce you to the thing like you've never heard of before. Right? That's not for smooth reading.

Barry Burd: Right? No, it was very smooth reading and very interesting reading. It interesting to me because there's some topics in there that I admittedly don't know anything about. I don't like it.

Jeanne Boyarsky: Did I have.

Victor Grazi: To? I thought you knew it all, Barry. I thought you knew it.

Barry Burd: Oh, you thought I knew it all. So how did you balance, existing technologies with new technologies? How did you decide which newer and upcoming technologies to introduce?

Victor Grazi: I think, you know, at the beginning, like Jeanne said, is, we we just evaluated what is the Java ecosystem, what are the things that we use every day in our lives? And what are the things that we think are up and coming? And then we we listed, you know, 50 of those things, not 50, but we listed a number of those, and then we ranked them.

And I guess, we had a we had a limit, you know, we knew we wanted to do, x number of chapters, 13 chapters. And we knew the page, the page count and things like that. So we assigned these, these numbers, right? Metrics. How many, how many pages do you think we're going to need to cover this kind of an agile, process?

And then we picked the top 13, and those are the ones we kept. And then the rest things that were even important but wouldn't fit in the book. Jeanne put in that, in the extra, what else in the ecosystem chapter.

Jeanne Boyarsky: And also recognizing what doesn't matter. Right. Like you don't need to cover Jenkins and GitHub and get love for CI. You need to understand how to use a CI system. One of the nice things about technology is how often it changes. So regardless of what you learn today, the technology stack you're using ten years from now is going be completely different.

But you need to understand the concepts, and any of these tools are perfectly good for understanding those concepts. So we picked the one that you know was well used, but it didn't matter exactly which technology was used for certain things, whereas others it matters greatly. So we covered more in that space because they were different. Like what was logging?

It's like, okay, here's a logging framework. Now here's another logging framework here are the things that are different in it, so that you get exposed to all of those concepts.

Barry Burd: Strategies that I noticed that you had was for a particular topic. You'd cover the the major piece of software that does it and then have notes, notes, then have extra material at the end of the chapter on other kinds, alternative pieces of software that do the same thing.

Jeanne Boyarsky: Yeah. And that's the IDE chapter is a great example of that, because I would say 90% of the chapter is about IntelliJ. And then there's a small amount about eclipse and VS code, because again, if you know how to use one IDE, you're going to know how to do use any IDE. But it takes a minute to get over that initial hump of where's the right?

So having that small amount of content on the other two major Ides lets people move past that point and start using it, and then after that, it's just expecting stuff to exist, right? Like Victor said, I expect to refactor menu to exist in every idea I use, unless it's notepad or VI. So I, you know, if I'm in there and I don't see the refactoring menu, I'm going to go on the internet and find out where the refactoring menu is, because I know it should be there.

Barry Burd: Can we get back to that topic for just a second? The IDE chapter is. I have a lingering question for Victor. You mentioned that a lot of the people that you interview have not used an ID.

Victor Grazi: No, they use the IDE, but they're they're tools within the IDE, like the refactoring menu or, you know, learning how to do shortcuts. Right? I know when I'm I'm writing code, my I don't remember the shortcuts, but my fingers do so automatically just just, you know, know how to do things. And it makes me very fast and very productive.

I can think and I could spill out. So people need to be very familiar with their IDE, and if they're not, that indicates to me, better than testing people on algorithms and things like that that we're never going to use. I think seeing how familiar they are with their IDE, their tools, is an indication of how good they are.

Some developers I know say that if I die and go to heaven and they say, Victor, you've been a good boy in this world, what do you want in heaven? I'd say, you know, give me a laptop and an IDE.

And, I feel. But, yeah, I think it's really important.

Recommended talk: 97 Things Every Java Prog. Should Know • Trisha Gee & Kevlin Henney ft. Emily & Holly • GOTO 2024

Technology Challenges and AI's Role

Barry Burd: Are there any misunderstood or underappreciated components of the Java ecosystem that you wanted to highlight in this book?

Victor Grazi: You know, I think I think the elephant in the room is AI, AI was just starting to emerge while we were writing the book. We don't really cover it in the book, but, but I think we used it in a way, and it was very helpful, and I'll tell you that, sometimes trying to come up with examples for every chapter we have code examples.

We have a GitHub repo where people could go and pull out working code, to see exactly how to, how to do things. And sometimes coming up with all of these examples for all of these chapters and doing it in a concise hello world kind of way, which will give people the ability to just feel this, this particular ecosystem component.

Sometimes that was pretty hard, you know, how do you think of these examples? And so you could go into ChatGPT and say, I need an example of X, and it would give you a small example. Said, no, I didn't quite mean that I want to. I want to add something here or there. So, you know, doing using AI, we were able to I don't know about Jim, but I was able to come up with some examples for the book, that was.

Jeanne Boyarsky: I didn’t use it for examples, but I used it for outlining for each of my chapters. I came up with an outline by hand of what I thought should be in there, and then I asked AI what it would add, and some of the ideas were good and some of the ideas were terrible. But that's why you have a human looking at the output.

And don't just say I write me a book. I'm glad we didn't include the libraries in the book though, because they're changing constantly, right?

Victor Grazi: It's too early and constantly.

Jeanne Boyarsky: We're not talking a decade or a year for AI. We're talking like every month it changes. So a snapshot in time of what I look like on the day we published the book would have been a museum piece to begin with. I do think our book prepares people to use the AI libraries because as I mentioned, after you've read our book, you can read any vendor documentation.

But for something like AI, you've got to be using online resources in order to learn because it just changes too fast for a publishing cycle.

Barry Burd: Everything about AI is changing really fast.

Victor Grazi: It's so fast.

Barry Burd: Yeah, you're dealing with it in academia right now, and we have no idea. I'm going to admit it. On behalf of all of academia.

Jeanne Boyarsky: I also use AI when I'm learning stuff. So not for writing the book, but when I'm reading other people's books, I'll ask AI to give me quiz questions or summarize points or, you know, make sure I got it. And like, if I've read a book about something and I can't answer the questions that I gave me and it's like, okay, I need to look at that part more, I need to do some more test examples on it, because I haven't mastered the thing that I want it to learn.

So it's a nice aid to the book, even if it's not in the book.

Writing Process and Challenges

Barry Burd: How did your writing process change as you went from beginning of the writing process to toward the end? Were there any surprises?

Victor Grazi: Yeah, I would say that, learning from each other, like, as I said, I had a certain style of writing. Jean had a certain style of writing, and then I'd read things that she'd write and write and I would say, you know, that's that's an interesting style. That's something that I want to adopt. So that speaks to I think the point you were making is that there was kind of a consistent style throughout the book.

I think we bounce things off of each other. And so we modified our style as as the book proceeded. It's it's such a long process. It's, you know, when we started writing the book, I figured this thing would be out in a couple of months and we'd be able to, you know, get it out in Amazon's See Our name in Lights.

But it actually took like a year to, to write it. You know, we were very careful, very exacting. Each chapter took us, at least a month. And it was, it was just very, it was a there was just so much collaboration and modification looking at each other and seeing how things were done by each other and modifying our style.

Accordingly.

Barry Burd: It's a long process, and it's a process that goes back and forth. You have to throw things out. You have to change your ideas. You have to go back to earlier parts. It's not just you. Here I am in a months and and boom.

Victor Grazi: And you, Barry, know that as a as a technical proofreader I think you read every chapter in your contribution was also invaluable. Like how many edits did you make and the suggestions and modifications?

Barry Burd: Yeah. It's it's writing a book is hard, but it's it's a labor of love.

Jeanne Boyarsky: And then at the end, you get a book and touch it.

Barry Burd: You get something that you can actually. Yeah. You get a, you get a piece of, a piece of paper that you, that you wrote, what challenges did you encounter? I'm thinking in particular of when I write, trying to make my wording accessible yet accurate. Very difficult challenge for me. Did you find the same sorts of, of, issues?

And if so, how did you deal with them?

Victor Grazi: I mean, my style is sometimes to, to start with an analogy or some something that will thrust the person into the same mindset that you're in when you're writing it. And so, you know, I think that helps. I think just trying to write things, put it away for a day and then read it again tomorrow is that I write that, you know, and modify, making it a little bit more clear.

I don't know, Jeanne. What what do you think?

Jeanne Boyarsky: Yeah. For me, I draft the entire chapter of I outline, then I write it, then I print it. Yeah, some physical pieces of paper, and I read it either outside or on the train. And I catch a lot of stuff that way, because being in a different place and not being on the computer lets me be in a different mindset.

So I see it differently than when I wrote it the first time. And also someone did a study that you find more type of typos when you are reading on paper than online. So I printed, two pages on each sheet. And you know, so for if you have a piece of paper back in front. So because I don't need a giant paper with a lot of whitespace, but I do print every chapter that I read.

Same for vectors. When I was reviewing them, I printed and start scribbling on them. And then transcribing notes is a pain. But you know, it works. And I think everyone has their own style that works for them.

Barry Burd: You have the same phenomenon that I have when I'm writing, it depends on my mood. I'll read a paragraph and I love it. Now read the paragraph the next day in the wrong with no, you don't do that. You're just. It's just right now.

Jeanne Boyarsky: For me, I read it the next day and it's not clear. So it's like, okay, I need to fix this.

Barry Burd: Right. Victor, what about you?

Victor Grazi: Yeah, no, I would, I'm more in your camp, Barry. I think sometimes you write things and you're in a certain mood. And then the next day I read it and I was like, that's not going to. It's not going to go away. 

Barry Burd: I guess another thing that I find is that I read a sentence and I wrote or paragraphs and I wrote and I suddenly realized that if you put the emphasis on the wrong syllable in one place, it means something entirely different or could easily be misinterpreted. Jeanne, that sounds like the kind of thing that you're looking for.

Jeanne Boyarsky: That's what I had on paper. And the other thing that mitigates that, I learned this in my other book with the certification that having one of your two editors be a non-native English speaker helps a lot. So Elena Felder is Russian and she's our editor of the book, and Rodrigo Graziano is Brazilian. And support you guys and read this book as the second editor.

That helps a lot, because there are idioms and things that we take for granted. And you notice more easily if it's not your native language and it doesn't matter what country the person is from originally, the fact that they learned English later helps them catch stuff like that.

Victor Grazi: Yes.

Jeanne Boyarsky: My readers are from all over the world. It's important to not be using English, American idioms that only we are going to understand.

Victor Grazi: That's something that Jeanne really helped me with a lot. Like a lot of times my writing style I use is big words, right? And Gina was like, people in China who are reading this book are not going to understand that you have to change it. And it's such a good word.

Jeanne Boyarsky: I remember the first time it's an English word and it's like, I agree, it's an English word.

Barry Burd: What do you have? I'm going to challenge you on this and maybe you won't be able to answer, but what kinds of words are you concerned about? This is a technical book, right? Aren't you allowed to use big words?

Jeanne Boyarsky: Big words that people know. So big computer words are great, right? Like using the word synchronized. No problem. But there are words that we don't use in everyday life. And somebody who learned English later may not know. And there's often a simpler synonym for that word. So that's the type of thing I'm talking about.

Victor Grazi: I can't think of a specific example, but it did come up many times.

Barry Burd: Wow. Okay. And this is only.

Jeanne Boyarsky: At the beginning. You got the hang of it pretty quickly.

Barry Burd: One of the things that I definitely did not notice is the technical proofreader was where there are chapters or sections or examples that were particularly challenging for you in the writing.

Victor Grazi: So everything is kind of like, you know, when you're writing, when you're writing a book, you have to be an expert on everything that you're writing. And you know, when I first learned Java in 1995 or so, the whole book was 150 pages. Right? It was an API book. And you just had to read that book.

And you were fluent in Java today. There's probably 150 books to read, and each one would be 1000 pages long to be an expert in Java. And so nobody's nobody's an expert anymore. But you have to be an expert when you're writing a book. So I think that was a real challenge, just becoming familiar with things.

If I wasn't so familiar with something or I was, you know, familiar, but not enough to write a chapter, and I would take a course, go on Udemy or Pluralsight or something and take a course on that chapter. So that helped a lot. And I think that's a challenge. Now, the chapters that we covered, I think we were both very familiar with and we were able to divide up the labor, based on our familiarity.

But there's always the edge cases. Right. And concurrency. It's a really difficult topic. So, you know, you have to take courses to just understand things that you hadn't encountered in your life. So, you know, those are some of the challenges of writing a deep technical book. And those are some of the things we had to overcome.

I think we did it. Well.

Jeanne Boyarsky: I agree, and I really like the freedom of this book that we got to choose what we included in it, because that's something that Scott and I always felt was with the certification book. It's like, I really want to cover this. It's really interesting, but I can't. It's not on the test here, we were able to cover what we both thought was important, and that was really nice, having those discussions and figuring out what we think people need to know.

Barry Burd: So, Victor, again, your process is different. And when you find that there's something you don't understand, you take a whole course. My process would be writing. I would find that there's something that I can't quite explain. Then I would admit to myself, that's because I don't really understand it. Then I would dig into that little topic and just, just find my own, take a course and just make sure that I understand that well enough to write a complete sentence about it.

Also, part of your process or you.

Victor Grazi: Well, like for example, the chapter on observability, right? I'm pretty familiar with, with all the tools that, that we would use in, in, observability. But, so let's say Prometheus. Right? I'm very familiar with Prometheus, but maybe there are very subtle edge cases and problem QL, but I don't know how to do certain aggregations or something, so I wouldn't take the whole course on Prometheus because I already know it.

But I jump to those chapters and fill in what would fill in what I needed to know.

Barry Burd: Are there parts of the book that you expect will be thought provoking for readers?

Victor Grazi: I think all the book is thought provoking, and we tried to write it in an interesting kind of way that was thought provoking. But, the thought provoking part of it is to get you interested, make the book interesting, make you want to read more. But in the end, it's a technical book and the knowledge that we're trying to convey, is essential knowledge that you're going to need to, to get employed in, in the job ecosystem.

Barry Burd: How would you recommend that readers apply what they read in your book? What, like you're handing the book to a reader right? You don't say read it from cover to cover and then put it down. What would be the process here?

Jeanne Boyarsky: Try stuff. You know, try doing a project or try doing an example. Start playing with it because then you notice other things that you want to learn.

Barry Burd: Okay. Have you, have you had reactions from readers? Yeah, yeah.

Victor Grazi: The people we've had really happy, happy readers. The reviews on Amazon have been really strong. Individuals come to me at work and say, you know, I read your book because I know you, but it was a really good book, you know, and there so it's good getting that kind of personal feedback.

Jeanne Boyarsky: My favorite moment we shared when we spoke at the New Jersey user group, we gave away a copy of the book and one of the people we took it to when it originally didn't want it because he had one. And afterwards, I think it was three people who brought their own copy of the book for us to sign, and that was nice, because we were in the same place as the book was pretty new at that point.

Recommended talk: Java, How Fast Can You Parse 1 Billion Rows of Weather Data? • Roy van Rijn • GOTO 2024

Where's the Java Ecosystem Going?

Barry Burd: Very nice. So where do you see the job that you want? What will this book look like in its third, fourth, fifth edition? Where's the Java ecosystem going?

Victor Grazi: You know, when we had the, we had the opportunity to speak at the Dev Nexus conference a few months ago in Atlanta. And, I remember at the keynote, one of the at the end of the keynote, the announcer said, by the way, there are a lot of sessions that are going to be on.

I don't just go to those sessions. There's so much more in the world than I, but the way it turned out was everybody was going to the AI sessions. So I think, there's going to be a, the AI is going to coalesce, right? People are going to coalesce around certain tools, AI tools in the Java ecosystem.

There's going to be the next spring in the next, the next, you get and, you know, certain tools will emerge as the tools to go to for AI. So I think that's going to be a big part of it. And there's also going to be specialties, right? There's, specialties in AI, different language models that are going to be appropriate for, for different parts of the ecosystem.

So those are going to start emerging, people are going to start making a lot of money on these things, and people are going to get to derive a lot of value from these. So I think that's really going to be the big direction. But we've covered so much. Right? The world is so mature.

Right now, all of these tools. Right. Kit and even Linux. Right. The, the, all of the tools that are available to us for free is amazing. So we're going to start seeing more and more of these kinds of tools emerging in the next decade.

Barry Burd: Are there any tools in particular that you wish you'd been able to sandwich in, other than I?

Are there any tools that you feel as if the ecosystem needs to pay more attention to?

Victor Grazi: Well, I think logging in a way is, you know, we've tried to solve the problem of logging by introducing, log back and SLA for J. And I'm finding that, this I think we, we over mentioned here those solutions. So, when I, when I'm trying to start a new project, like I mentioned before, there's always, there's always conflicts between the SLA for J and the log for J, and, these kind of conflicts that we were trying to solve for, just merging there are merging their ugly heads, over and over again.

How to integrate CI/CD with deployment. Right. You're building a container. How do you deploy that container in the CI/CD? Everything was done, but the container deployment wasn't. How do you introduce some kind of communication between those things? Those kinds of things.

Jeanne Boyarsky I think for me, these two questions are hard because the answer to them is things that don't exist yet. Right? I think there's going to be chapters on things that don't exist yet, but we don't know what they are. I'm asking you for the tools. It's like there's probably going to be a chapter about working with legacy code that was written and funny. Funny, because I think the ecosystem will just be so different by that point.

Barry Burd Okay. Let me go back to something that you said earlier, because I want to capture that. Regular expressions - we talk about that as being both of you wanted that to be your favorite chapter one.

Jeanne Boyarsky You wanted to write the chapter?

Barry Burd I wanted to write the chapter. What is it about regular expressions? Why?

Jeanne Boyarsky What's interesting is that regular expressions aren't new. They were added in Java 1.4. But so many people are afraid of regular expressions that they'll write this giant mess of code that can be a one line, readable, regular expression, and readable is important. You can write readable regular expressions. It's a topic I've always liked for the same reason I like streams - that you can write expressive, powerful code, and it's something that I enjoy talking about. I've presented about it. When do I present it? More recently. So it's a topic that I really enjoy, and I've never met anybody who enjoys it as much as I do. So it was so cool that, oh, I mean, after.

Victor Grazi:  I did a Pluralsight course on Regular Expressions. I was like, really familiar with that. I love it because I just like, I just like, really esoteric kind of terrorist kind of stuff and regular expressions is all that. So you can express so much with so little code. I love that part of it. So. That's why we're fighting over it.

Barry Burd : Yes.

Jeanne Boyarsky: And we do not cover a lot of language features in the book. We picked that one because people are resistant to using it. So, like, we didn't sit in covered dreams. We do assume that, you know, Java, but also you can get through an intro book and not know regular expressions. You can't get through an intro book and not know how to write a loop or create a thread. So we wanted to take for granted that, you know, the stuff that would be in that intro book, whereas regular expressions you might have missed. And as Victor said, it's a really powerful tool. And that's what a lot of these chapters are about, things that you're going to use and things that you need to understand. And it's okay not to like regular expressions, but the reason shouldn't be because you're afraid of them.

Barry Burd: Regular expressions can be really messy and really difficult, but they don't.

Jeanne Boyarsky Have to be like, I have a blog post on writing readable regular expressions. What I do is I create variables with the name of the thing, right? So word any characters eight digits. And now the actual regular expression line is string regex equal and a pile of readable things that have no code in them. Then it's easy to tell if it's wrong, because the regular expression for a word is something that's very short. And when you do that, when you think about how to make it readable, it's readable. Instead, what we see online is someone who wrote a regular expression that's this long and it isn't readable. It's like, well, you know, we know why that is. But you take the time to write readable code, just like with anything else, even if you're not using regular expressions, if someone hands you code and their variables are named x and k, you're going to have questions about this, right? So it's the same deal with regular expressions. You have to take the time and energy to make it understandable to your future self and everybody else.

Victor Grazi: There's another thing that's, it's not regular expressions, but it's related to that. We did a chapter on that as well, and that's aspect oriented programming. So, you know, a lot of times let's say you have a library that does a certain job in a certain way, and you want most of that functionality, but you want to be able to do something before something after something in between. You want to be able to modify that behavior, but it's not your code. So how do you do that? Or even if it is your code, but you want to introduce logs in a certain place. In every under every circumstance. But you don't want to go and modify your code in every one of those circumstances. So where you could do is right an aspect, an aspect has a point code that looks at a certain where you can express a certain pattern that you want to apply some code. So I think that that was a really important part of the ecosystem that we were struggling with. And again, that's a very esoteric kind of topic that it's not for the faint of heart. Junior Java developers are not going to start dealing with that. So we covered that in the book pretty extensively and showed people how to, you know, enter pretty easily into that, to that, paradigm.

Barry Burd: Something I used to hear a lot about, and I don't care that much about it now, but that doesn't mean that it's not important.

Victor Grazi You know, it's pretty important. Another thing that was controversial was Lombok. Now Lombok is either you love it or you hate it. We don't want to get into the argument. We just kind of taught people about it. I have a love hate relationship with it because it really does make your code much more concise. But it also fools your IDE sometimes. If you're debugging, it's very difficult to get into specific lines of codes that are introduced by Project Lombok. Project Lombok is a library that you could just define your just define your fields and it'll introduce the getters and setters and things like that. For you, instead of having to define your logging framework and log messages, you just put a logging aspect on top of your code, and it introduces all of the logging components that you need. So, you know, that was, that was kind of an interesting topic covering that Lombok. You're going to see it in the enterprise. So we didn't make a judgment whether it's good or not, but we just taught you how to use it, things like that.

What's Next?

Barry Burd: All right. Quick question. That's going to be difficult to answer. What comes next for each of you, don't think about it. Don't overthink it. Another book, another topic, and a holiday gathering. Anything. Right.

Jeanne Boyarsky: For me, it's the Java 25 cert book because Java certs are tied to long term support releases, and the Java 25 release comes out in September, which means sometime after that will be the next cert.

Barry Burd: Victor.

Victor Grazi:  Well, Barry, there's never enough time, right? I'm busy at work. I'm in the financial industry, always working, but I always do want to take up some extracurricular activity. And I think, right now what I'm thinking about is preparing a follow up to my Pluralsight course on Regular expressions, something that the Pluralsight course that I did was basically oriented around Java regular expressions. But what I like to do now is come up with a course that teaches you about regular expressions, and then as a side, teach you how to do it in Java. So a little bit of a change in orientation on that. But that's, that's what's going to come up next. I also like to do a little bit of volunteering. You know, there are a lot of people who need to work there. They were never trained in technology. Older people, people my age. Right on the grandpa and, people my age, just for some reason, type technology person by they weren't there when it was happening. So I like to try to spend some time training these people, teaching me how to use Microsoft Word and Excel and some of the basics that they're going to need, to get jobs going forward. So that's also on my plate.

Barry Burd: Worthy goals, worthy goals from both of you. I want to thank Victor and Jean for asking and and congratulate them on their book, Real World Java and hope to see you again soon. This has been GOTO Book Club with Barry.

Victor Grazi: We'll see you at the next Java sig.

Barry Burd: Very good. Take care then. Bye bye.

Victor Grazi: Bye.