What do you think?
Rate this book
WIE Data Structures and Algorithms in Java
The third edition of this conceptually elegant and pedagogically innovative text continues to incorporate the object-oriented design paradigm, using Java as the implementation language, while also providing intuition and analysis of fundamental data structures and algorithms. All of this is done in a clear, friendly writing style that uses visuals to introduce and simplify important analytic and mathematical concepts.
* Entirely new chapter on recursion
* Additional exercises on the analysis of simple algorithms
* New case study on parenthesis matching and HTML validation
* Entirely new chapter on recursion
* Additional exercises on the analysis of simple algorithms
* New case study on parenthesis matching and HTML validation
704 pages, Hardcover
First published January 1, 1998
71 people are currently reading
569 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 19 of 19 reviews
February 16, 2014
"I don't know. It's just a trick, you know? It's like when I was... I wrote this story on Paris, and I'd never been there. You don't have to— It's just a trick."
—Rain to Gabe, Husbands and Wives, written and directed by Woody Allen
Gabe, a writing professor played by Allen, has just peppered Rain, his precociously talented student played by Juliette Lewis, with some extremely flattering inquiries into her writing methods and background. Rain's embarrassed humble-brag of a response only serves to further her mystique. She's not the creepily ambitious kind of precocious, she's the effortlessly good kind.
And that's what we wonder about our computers, isn't it? What gallons of dystopian, man vs. the machines ink have been spilled over? Are the smartComputerPhoneMachines doing these remarkable things to our economy and cultural and political apparatuses because they are just that good, or, embedded in all the assumptions of what makes good software and a good tech company are there some pretty creepy ambitions too?
I got through this book in a week, and I think I understand most of it. (It's just a trick, you know?) The book did have its difficult moments. Because it uses very few practical examples, it was difficult to extrapolate the significance of the variations between some of the data structures, but many of the concepts were very elegant, even beautiful, to me once I was able to extrapolate the significance on my own. I took copious notes, and there were a few times when I wrote "nifty" or "cool" in the margins of my notes.
There's one problem called the "Minimum Spanning Tree" which aims to find the shortest existing network of connections between a group of points. Here's the script I wrote in JavaScript based on Kruskal's Algorithm (a little clunky because if JavaScript can do sets I'm not yet aware of how) to find the Minimum Spanning Tree for a given set of eight islands with multiple ways to connect:
I first tried to figure out the problem by hand hoping that would lead me to the right JavaScript methodology faster than translating the book's pseudocode solution. I drew the first four islands and their potential bridges in my notes, but my meatspace CPU failed to distinguish a usable pattern even at that small scale.
So, I turned to my HTML editor and went back and forth between Kruskal's and another solution Bruvka's Algorithm (which had at first seemed the easier to implement of the two) before finally translating Kruskal's with some success. And now I can apply Kruskal's to my hand-drawn four-island graph easily in my head.
Because now I know the trick.
So this stuff is all just logic (a great thing), probability (a very good thing), and efficiency (a powerful thing). It's breaking problems down into subproblems and piecing them back together so that over the long-term and at great scale the problems can be solved with magnitudes greater efficiency. This is such a key concept in computer science that it even has a name, "Dynamic Programming."
How can any of this be wrong, let alone bad for us or creepy?
Life is a problem: it's made up of mostly suffering and then we die. Certain subproblems of life can be optimized methodically, and tricks are welcome in such cases: the articulation and complication of dark truths about human imagination; instantaneous graphical, text, and quantitative data on potential new commutes.
But even the post-modernists knew that tricks alone were not enough: they also gave us an appreciation for process over product. Engineers know this, at least those who truly understand Lean Startup do. Minimum Viable Product is as French New Wave of a philosophy as you get. (Is "Minimum Viable Product" the least beautiful rewrite of "the journey is the destination" possible, or what?)
And process is the definition of inefficient. If a process were truly efficient it wouldn't exist. You would have an idea and then there would be a product in O(1) time. No engineer would release something created on that schedule. So why hurry everyone else along?
Christopher Isherwood wrote A Single Man at a rate of eight pages a month, and not because he used a typewriter (I know that this is not provable, but I just know it's true). He wrote at a rate of approximately 950 characters per day, or less than seven Tweets!
Of course, I read it at a much faster rate than that, and it was sent from Amazon's servers to my Paperwhite at a much, much, much faster rate than that, thanks to several of the algorithms and data structures in this book and the hard-working engineers who figured out how to implement them for this very purpose for millions of people. Around the world. Simultaneously. (Cool! Nifty!)
However, clearly the actual writing of the book had an expensive O(something very large) runtime. It was, in fact, supported by a teaching position at a state-funded institution and the post-war housing boom in California (also subsidized by the American government).
As many know, bipolar disorder is a chronic psychological illness characterized by alternating episodes of mania and depression. During manic episodes, bipolars experience an increase in energy and a decreased need for sleep, with some forgoing sleep altogether. Attention span is low, and judgment impaired. Behavior may become aggressive, intolerant, or intrusive. He or she may feel out of control or unstoppable, or as if he or she has been "chosen" and is "on a special mission," or have other grandiose or delusional ideas.
I'm not trying to make any person or persons seem crazy so much as trying to show that some really extreme efficiencies, such as those created by manic episodes, don't come free. There is no such thing, I believe, as chronic mania. Absent of pharmaceutical stimulation, mania occurs only in conjunction with alternating episodes of major depression.
One thing that I was surprised to learn from this book is how imperfect some of the math is. There are some algorithms and data structures that depend on patterns of probability, even randomization, to increase efficiency in a real world with unpredictable inputs. That is, their worst-case run-times are actually quite high, but their average runtimes over time fall within desirable ranges. They work like an insurance system: the super fast searches, insertions, and deletions make up for the unexpectedly slow ones over time. Goodrich and Tamassia call this "amortization," but it sounds an awful lot like redistribution of resources to me.
Algorithms are Socialist Democrats!
Some of them, anyway.
"I wrote this story on Paris, and I'd never been there. You don't have to— It's just a trick."
Americans love freaks like Rain. We love natural talent, effortless success. But, paradoxically, we also don't trust it. We ask it what its parents do for a living, where it grew up (Gabe asks Rain both of these things), we try to reduce the improbable input to if-then logic. But this bipolar love-hate relationship with outliers does not make for a robust system. If redistribution is good enough for our algorithms, it's good enough for us.
—Rain to Gabe, Husbands and Wives, written and directed by Woody Allen
Gabe, a writing professor played by Allen, has just peppered Rain, his precociously talented student played by Juliette Lewis, with some extremely flattering inquiries into her writing methods and background. Rain's embarrassed humble-brag of a response only serves to further her mystique. She's not the creepily ambitious kind of precocious, she's the effortlessly good kind.
And that's what we wonder about our computers, isn't it? What gallons of dystopian, man vs. the machines ink have been spilled over? Are the smartComputerPhoneMachines doing these remarkable things to our economy and cultural and political apparatuses because they are just that good, or, embedded in all the assumptions of what makes good software and a good tech company are there some pretty creepy ambitions too?
I got through this book in a week, and I think I understand most of it. (It's just a trick, you know?) The book did have its difficult moments. Because it uses very few practical examples, it was difficult to extrapolate the significance of the variations between some of the data structures, but many of the concepts were very elegant, even beautiful, to me once I was able to extrapolate the significance on my own. I took copious notes, and there were a few times when I wrote "nifty" or "cool" in the margins of my notes.
There's one problem called the "Minimum Spanning Tree" which aims to find the shortest existing network of connections between a group of points. Here's the script I wrote in JavaScript based on Kruskal's Algorithm (a little clunky because if JavaScript can do sets I'm not yet aware of how) to find the Minimum Spanning Tree for a given set of eight islands with multiple ways to connect:
var vertices = 8;
var C = [];
function falseSet(number) {
var array = [];
for (count = 0; count < number; count++) {
array[count] = false;
}
return array;
}
for (n = 1; n <= vertices; n++) {
C[n] = falseSet(vertices);
C[n][n-1] = true;
}
var Q = [ Set of several bridge lengths between 8 vertices in format [length of bridge,[id number of vertex A,id number of vertex B]] ];
Q.sort();
var T = [];
for (m = 0; m < Q.length; m++) {
var v = Q[m][1][0];
var u = Q[m][1][1];
if (C[v] !== C[u]) {
T.push(Q[m]);
var thisCluster = falseSet(vertices);
for (i = 0; i < vertices; i++) {
if (C[v][i] || C[u][i]) {
thisCluster[i] = true;
}
}
for (i = 0; i < vertices; i++) {
if (thisCluster[i]) {
C[i+1] = thisCluster;
}
}
}
}
I first tried to figure out the problem by hand hoping that would lead me to the right JavaScript methodology faster than translating the book's pseudocode solution. I drew the first four islands and their potential bridges in my notes, but my meatspace CPU failed to distinguish a usable pattern even at that small scale.
So, I turned to my HTML editor and went back and forth between Kruskal's and another solution Bruvka's Algorithm (which had at first seemed the easier to implement of the two) before finally translating Kruskal's with some success. And now I can apply Kruskal's to my hand-drawn four-island graph easily in my head.
Because now I know the trick.
So this stuff is all just logic (a great thing), probability (a very good thing), and efficiency (a powerful thing). It's breaking problems down into subproblems and piecing them back together so that over the long-term and at great scale the problems can be solved with magnitudes greater efficiency. This is such a key concept in computer science that it even has a name, "Dynamic Programming."
How can any of this be wrong, let alone bad for us or creepy?
Life is a problem: it's made up of mostly suffering and then we die. Certain subproblems of life can be optimized methodically, and tricks are welcome in such cases: the articulation and complication of dark truths about human imagination; instantaneous graphical, text, and quantitative data on potential new commutes.
But even the post-modernists knew that tricks alone were not enough: they also gave us an appreciation for process over product. Engineers know this, at least those who truly understand Lean Startup do. Minimum Viable Product is as French New Wave of a philosophy as you get. (Is "Minimum Viable Product" the least beautiful rewrite of "the journey is the destination" possible, or what?)
And process is the definition of inefficient. If a process were truly efficient it wouldn't exist. You would have an idea and then there would be a product in O(1) time. No engineer would release something created on that schedule. So why hurry everyone else along?
Christopher Isherwood wrote A Single Man at a rate of eight pages a month, and not because he used a typewriter (I know that this is not provable, but I just know it's true). He wrote at a rate of approximately 950 characters per day, or less than seven Tweets!
Of course, I read it at a much faster rate than that, and it was sent from Amazon's servers to my Paperwhite at a much, much, much faster rate than that, thanks to several of the algorithms and data structures in this book and the hard-working engineers who figured out how to implement them for this very purpose for millions of people. Around the world. Simultaneously. (Cool! Nifty!)
However, clearly the actual writing of the book had an expensive O(something very large) runtime. It was, in fact, supported by a teaching position at a state-funded institution and the post-war housing boom in California (also subsidized by the American government).
As many know, bipolar disorder is a chronic psychological illness characterized by alternating episodes of mania and depression. During manic episodes, bipolars experience an increase in energy and a decreased need for sleep, with some forgoing sleep altogether. Attention span is low, and judgment impaired. Behavior may become aggressive, intolerant, or intrusive. He or she may feel out of control or unstoppable, or as if he or she has been "chosen" and is "on a special mission," or have other grandiose or delusional ideas.
I'm not trying to make any person or persons seem crazy so much as trying to show that some really extreme efficiencies, such as those created by manic episodes, don't come free. There is no such thing, I believe, as chronic mania. Absent of pharmaceutical stimulation, mania occurs only in conjunction with alternating episodes of major depression.
One thing that I was surprised to learn from this book is how imperfect some of the math is. There are some algorithms and data structures that depend on patterns of probability, even randomization, to increase efficiency in a real world with unpredictable inputs. That is, their worst-case run-times are actually quite high, but their average runtimes over time fall within desirable ranges. They work like an insurance system: the super fast searches, insertions, and deletions make up for the unexpectedly slow ones over time. Goodrich and Tamassia call this "amortization," but it sounds an awful lot like redistribution of resources to me.
Algorithms are Socialist Democrats!
Some of them, anyway.
"I wrote this story on Paris, and I'd never been there. You don't have to— It's just a trick."
Americans love freaks like Rain. We love natural talent, effortless success. But, paradoxically, we also don't trust it. We ask it what its parents do for a living, where it grew up (Gabe asks Rain both of these things), we try to reduce the improbable input to if-then logic. But this bipolar love-hate relationship with outliers does not make for a robust system. If redistribution is good enough for our algorithms, it's good enough for us.
Read
November 17, 2019Must-read for every dev.
June 14, 2017
Perfect book for self study. Had to put off reading it after seeing poor reviews on amazon. It is a shame that this book is not known more widely than what it deserves. Need to go one more round doing most of the exercises to make the concepts stick.
Best Algorithm/DataStructure book with almost good OO java implementations - save for the eye gauging generics syntax
Best Algorithm/DataStructure book with almost good OO java implementations - save for the eye gauging generics syntax
January 1, 2011
Required for data structures class. I found better descriptions of the algorithms covered in this book on Wikipedia. At least the book contains Java code for some of the implementations and examples of how the data structures work. A good book for the beginner. You can find better as a reference.
November 9, 2018
I hate Java but I have to teach it my students this semester as a TA for a Data Structures class. This book was surprisingly very very good. It covers all the essential data structures you need to know and also even the essential algorithms you need to know (even some advanced ones). The authors did a great job seperating the language from the concepts and only bringing them together in the super helpful implementations. I've read too many CS books where entire concepts/algorithms are written in math equations and actual implementations are 'left to the reader.'
April 27, 2025
Required textbook for my Java data structure class. Contrary to some other reviewers, I like concrete implementations in the book. Maybe more detailed explanation when it comes to some relatively more advanced algorithms. For example, in one of Chapter 13's exercises, authors talk about Rabin-Karp. Sounds really complex to me. It would be helpful to list a couple of recommended readings.
December 25, 2021
awesome book if you can persevere
August 22, 2022
So complicated!!!
February 19, 2023
In my quest to find a digestible DSA book that doesn't just gloss over implementation in pseudocode, this is an improvement from the textbook I was provided at community college.
May 5, 2023
Our teacher based his classes almost completely on this book, so keep in mind that I am probably biased.
While especially the beginning of the book is important to understand for every developer (e.g. arrays, linked-lists, hash-sets, time-complexity, etc.), I found the book to go into an unuseful direction after some time. I am not sure why so many people find it relevant for day-to-day development, but I sincerely hope only very few developers actually implement binary trees by hand for real-world applications.
In my opinion, this book should be more about understanding the concepts of a framework you're using, not about going into the depth required to actually implement it yourself. And is more relevant data-structure related stuff you need to actually use in actual day-to-day development not mentioned in this book, as opposed to covered things like e.g. splay-trees, which I find to be a niche structure you're almost certainly never going to use.
Then again, it is probably more relevant for "low-level" developers that use something like C, but for Java developers (which this book heavily leans on) it shouldn't be such a big deal to manually implement tree-rotations.
I did like the style of the book though. From the presentation of pseudo-code to the visualizations, you can really feel that the authors wanted to provide high-quality material.
Maybe it's unfair to treat the book based on the topic it's covering. And if you focus on the first half, it is a good book that starts off with little knowledge required beforehand and teaches you some vital concepts of software development. But I cannot recommend it further than that.
While especially the beginning of the book is important to understand for every developer (e.g. arrays, linked-lists, hash-sets, time-complexity, etc.), I found the book to go into an unuseful direction after some time. I am not sure why so many people find it relevant for day-to-day development, but I sincerely hope only very few developers actually implement binary trees by hand for real-world applications.
In my opinion, this book should be more about understanding the concepts of a framework you're using, not about going into the depth required to actually implement it yourself. And is more relevant data-structure related stuff you need to actually use in actual day-to-day development not mentioned in this book, as opposed to covered things like e.g. splay-trees, which I find to be a niche structure you're almost certainly never going to use.
Then again, it is probably more relevant for "low-level" developers that use something like C, but for Java developers (which this book heavily leans on) it shouldn't be such a big deal to manually implement tree-rotations.
I did like the style of the book though. From the presentation of pseudo-code to the visualizations, you can really feel that the authors wanted to provide high-quality material.
Maybe it's unfair to treat the book based on the topic it's covering. And if you focus on the first half, it is a good book that starts off with little knowledge required beforehand and teaches you some vital concepts of software development. But I cannot recommend it further than that.
August 12, 2014
While I had difficulty understanding the material at first, it was because I felt mainly confused about how to program the concepts from ground zero. Then I realized I wasn't really reading as closely to the book as I had intentioned, because the author does in fact have explanatory statements that suggest most of the code that is covered is included in the Java library. I had to highlight the book on my kindle, which is an excellent rendition of the textbook, in order to make sure I understood the concepts, which is why I gave it a 4 out of 5 for not making concepts easily understandable.
October 29, 2008
Reading for CSC 383 - Data Structures
Read
September 7, 2009nonono
Want to read
July 14, 2011A superb book to read.. i admire it
April 19, 2014
The book had so many not-well organized written information. Not suitable for teaching Data Structure courses in the college for it lacks consistency and to-solve problems.
November 23, 2021
A good book on algorithms for begginers. I suggest to read it along with the youtube list https://www.youtube.com/playlist?list...
April 15, 2017
Must-read book of data structures ever
Read
November 1, 2016good
July 31, 2013
Lacked conciseness.
Displaying 1 - 19 of 19 reviews