Tobias
I got around halfway through this book before realizing that learning a new programming language through a thick textbook might be the single worst way to do it. Ordinarily this wouldn't be news to me, but in this case I wanted to try it anyway.
See, learning Java in 2025 is different from learning Rust, or Zig, or Gleam in 2025.
With its first release in May of 1995 it has now enjoyed almost 30 years of development. That's quite impressive, but it also means that over the years, the language has gained many more features to accomplish the same things in new and different ways.
Reading blogs, or articles, or even the documentation it is quite hard to understand what modern Java actually looks like and how it differs from old Java. Stackoverflow is often especially bad for this, since it disallows duplicate questions and accepted answers are often 10+ years old. Sometimes those answers get updated, but often times they don't.
So I thought it would be a good idea to buy the most recent edition of one of the most well regarded textbooks to circumvent this issue.
And to be fair to the book, it is very comprehensive, specifically mentions the modern ways to do things right from the get go and overall just very well written.
So my issues with this book aren't at all about *this* specific book, they are about the format. As so many others do as well, so does this book try to incorporate a set of exercises after each section. And they cover the content from those chapters fairly well. However, you can really only implement a bunch of completely meaningless classes so many times before you want to punch through your monitor.
Java Books in particular for some reason seem to gravitate towards exercises where the reader has to implement classes to closely replicate an org chart. `Person`, `Employee`, `Manager` being the de-facto standard way to explain classes and inheritance, when that is an objectively (pun intended!) terrible way to explain the concept. I understand that authors want to make this concept relatable, but pick literally any technical concept where object-oriented programming actually provides benefits to explain it. Otherwise people learn from minute one to focus excessively about arbitrary abstractions instead of actually solving technical problems.
The one saving grace of this book is that it summarizes the important takeaways of every chapter at the *beginning* of each chapter in about 10 or so bullet points. That is amazing, I wish every textbook would adopt this. It is *much* more helpful to have this at the beginning, because it guides the reader towards paying particular attention to the important bits during the rest of the chapter. For the chapters that I did work through I read these bullet points at the beginning (as is intended) and then again after reading the chapter to make sure that I didn't miss anything important during it. Sometimes this made me go back to a section because I noticed a gap in my understanding, but most of the time having this section at the top primed me well enough to grok it in one go. It's hard to believe how rare this approach seems to be, considering how simple the idea is. Just put the learnings at the top people, it helps!
Now that I have this book I'll probably come back to it to figure out some of the modern best practices, but only after building at least a few medium-sized real-world projects with the language. I certainly wouldn't recommend buying the book for that purpose, but if you have access to it through a library then it might not be the worst choice for that.
In conclusion: If you want to learn a programming language, build things with it. Don't read a book. Just build. And *maybe* come back for the technicalities later.
Originally posted at www.jennerjahn.xyz.
I got around halfway through this book before realizing that learning a new programming language through a thick textbook might be the single worst way to do it. Ordinarily this wouldn't be news to me, but in this case I wanted to try it anyway.
See, learning Java in 2025 is different from learning Rust, or Zig, or Gleam in 2025.
With its first release in May of 1995 it has now enjoyed almost 30 years of development. That's quite impressive, but it also means that over the years, the language has gained many more features to accomplish the same things in new and different ways.
Reading blogs, or articles, or even the documentation it is quite hard to understand what modern Java actually looks like and how it differs from old Java. Stackoverflow is often especially bad for this, since it disallows duplicate questions and accepted answers are often 10+ years old. Sometimes those answers get updated, but often times they don't.
So I thought it would be a good idea to buy the most recent edition of one of the most well regarded textbooks to circumvent this issue.
And to be fair to the book, it is very comprehensive, specifically mentions the modern ways to do things right from the get go and overall just very well written.
So my issues with this book aren't at all about *this* specific book, they are about the format. As so many others do as well, so does this book try to incorporate a set of exercises after each section. And they cover the content from those chapters fairly well. However, you can really only implement a bunch of completely meaningless classes so many times before you want to punch through your monitor.
Java Books in particular for some reason seem to gravitate towards exercises where the reader has to implement classes to closely replicate an org chart. `Person`, `Employee`, `Manager` being the de-facto standard way to explain classes and inheritance, when that is an objectively (pun intended!) terrible way to explain the concept. I understand that authors want to make this concept relatable, but pick literally any technical concept where object-oriented programming actually provides benefits to explain it. Otherwise people learn from minute one to focus excessively about arbitrary abstractions instead of actually solving technical problems.
The one saving grace of this book is that it summarizes the important takeaways of every chapter at the *beginning* of each chapter in about 10 or so bullet points. That is amazing, I wish every textbook would adopt this. It is *much* more helpful to have this at the beginning, because it guides the reader towards paying particular attention to the important bits during the rest of the chapter. For the chapters that I did work through I read these bullet points at the beginning (as is intended) and then again after reading the chapter to make sure that I didn't miss anything important during it. Sometimes this made me go back to a section because I noticed a gap in my understanding, but most of the time having this section at the top primed me well enough to grok it in one go. It's hard to believe how rare this approach seems to be, considering how simple the idea is. Just put the learnings at the top people, it helps!
Now that I have this book I'll probably come back to it to figure out some of the modern best practices, but only after building at least a few medium-sized real-world projects with the language. I certainly wouldn't recommend buying the book for that purpose, but if you have access to it through a library then it might not be the worst choice for that.
In conclusion: If you want to learn a programming language, build things with it. Don't read a book. Just build. And *maybe* come back for the technicalities later.
Originally posted at www.jennerjahn.xyz.