Slashdot Mirror
Developing Java Software
Simon P. Chappell writes "It's good to learn a programming language, but it's a far better thing to learn to write programs in that language. What the world needs are less programming language books and more books on programming with the language of your choice. Enter Developing Java Software, 3rd edition by Russel Winder and Graham Roberts. Dr. Winder is the primary author and I became aware of this book when he mentioned it on the Groovy mailing list. Knowing him to be an intelligent and helpful member of the Groovy development team, I rushed to suggest that I could review it for him." Read the rest of Simon's review.
Developing Java Software (3rd edition)
author
Winder and Roberts
pages
885 (19 page index)
publisher
Wiley
rating
7/10
reviewer
Simon P. Chappell
ISBN
0470090251
summary
A good book for learning to write programs with Java.
Developing Java Software is a text book, and is targeted towards university undergraduates, most likely in some form of computer science curriculum. It is also completely suitable for self-learners who want to teach themselves how to write software in Java. The book has been used by the authors when teaching undergraduate classes at University College London, so it has been fully tested in the academic environment.
There are five parts, with twenty four chapters between the first four parts and ten appendixes in the fifth. Each of the chapters are short, most are less than 40 pages, tightly focused and fairly self-contained.
The first part, the longest of them all, starts out with the introduction chapter that no book is complete without. Really, how many people who want to learn Java don't know that it used to be called Oak and was originally designed for set-top boxes? Anyway, after that little excursion, the book moves onto useful stuff like "Programming Fundamentals", introducing concepts like statements, variables and expressions. Next is "Adding Structure" where we discover methods and control structures. Chapter four is "Introducing Containers" and does a good job of covering arrays and the whole slew of container data structure classes in the standard library. Chapter five is a little time off for good behaviour, where we get to spend some time "Drawing Pictures" before heading into chapter six for "Classes and Objects". Chapter seven explains "Class Relationships" while chapter eight introduces us to "Exceptions". Chapter nine is "Introducing Concurrency with Threads". We finish up with chapter ten covering "User Interfaces".
Part two addresses the "Process of Programming" and this is where it really differentiates itself from the rest of the Java book crowd. Chapter eleven gives an overview of "The Programming Process". Chapter twelve begins the process of making that real by addressing "Unit Testing". Chapter thirteen continues the story with "Test-driven Programming Strategies". More practical advice comes in chapter fourteen as they introduce the reader to "Programming Tools".
Part three brings two "Case Studies in Developing Programs". Chapter fifteen introduces the case studies. The first study, "Contacts Book" is in chapter sixteen and the second, a "Pedestrian Crossing Simulation" is in chapter seventeen.
Part four is "The Java Programming Language in Detail". This is the more reference portion of the book and it's seven chapters cover variables, types and expressions, flow-control, classes and packages, inheritance and interfaces, exception handling, threads and concurrency.
Part five is the "Endmatter" and holds ten appendixes.
The first thing to like with this book is that it has an engaging style. The style comes not just from the body text, but also from the notes, tips and references in the margins of the book. As someone who learned Java almost ten years ago, I have difficulty plowing through yet more body text explaining the same old stuff that every other Java book covers; yet, jaded and cynical as I am, I enjoyed the sparks of honesty and humour in the text.
As I alluded to in my opening remarks, this book takes the approach of trying to not only teach Java, but how to approach and actually write programs using Java. The book takes an iterative approach and emphasizes the use of testing tools. Interestingly, they use TestNG rather than the de facto standard JUnit. This is the first book that I've seen that uses TestNG; perhaps JUnit is finally getting some competition?
The book is completely targeted at Java 5. All of the code examples use the new features where appropriate. This makes the book worth considering for those that already know Java but want to finally climb onboard with the latest version.
Naturally, there is a website available at www.devjavasoft.org where all of the source code for the programs in the book may be downloaded, together with answers to the exercises and any updates or revisions of the material in the book.
One of the challenges of writing or updating a book of this size is that it's possible (nay, almost guaranteed) to miss important things. The tip at the top of page 190 is a classic example, where the reader is advised that calling System.gc() will force the Java Virtual Machine (JVM) to perform a garbage collection. This is not, and has never been, true. The most that the System.gc() call will do is let the JVM know that now would be a good time for it to garbage collect, but there are no guarantees that any collection will actually take place. With this being the third edition of the book, I expected errors of this sort to have been caught by now.
Another point to consider is that with this being a textbook the writing style is less like a mass-market book and it also includes questions and exercises at the end of each chapter. I normally avoid books of this sort, although this does seem to be one of the better ones.
I hate being picky about typography, especially with the average level being quite good these days, but this book is set in a smallish font for the amount of text on each page. It is a serif font, but I didn't find it the most comfortable to read. Also, and this is the most egregious fault in the whole book, the program listings are set in a proportional font! I could hardly believe it when I saw it. While I realize that the authors are unlikely to be responsible for the final font selections, I fear that it damages an otherwise strong book and does them a disservice.
This is a good book for learning Java. More importantly, it's a good book for learning to write programs with Java.
You can purchase Developing Java Software 3rd edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Developing Java Software is a text book, and is targeted towards university undergraduates, most likely in some form of computer science curriculum. It is also completely suitable for self-learners who want to teach themselves how to write software in Java. The book has been used by the authors when teaching undergraduate classes at University College London, so it has been fully tested in the academic environment.
There are five parts, with twenty four chapters between the first four parts and ten appendixes in the fifth. Each of the chapters are short, most are less than 40 pages, tightly focused and fairly self-contained.
The first part, the longest of them all, starts out with the introduction chapter that no book is complete without. Really, how many people who want to learn Java don't know that it used to be called Oak and was originally designed for set-top boxes? Anyway, after that little excursion, the book moves onto useful stuff like "Programming Fundamentals", introducing concepts like statements, variables and expressions. Next is "Adding Structure" where we discover methods and control structures. Chapter four is "Introducing Containers" and does a good job of covering arrays and the whole slew of container data structure classes in the standard library. Chapter five is a little time off for good behaviour, where we get to spend some time "Drawing Pictures" before heading into chapter six for "Classes and Objects". Chapter seven explains "Class Relationships" while chapter eight introduces us to "Exceptions". Chapter nine is "Introducing Concurrency with Threads". We finish up with chapter ten covering "User Interfaces".
Part two addresses the "Process of Programming" and this is where it really differentiates itself from the rest of the Java book crowd. Chapter eleven gives an overview of "The Programming Process". Chapter twelve begins the process of making that real by addressing "Unit Testing". Chapter thirteen continues the story with "Test-driven Programming Strategies". More practical advice comes in chapter fourteen as they introduce the reader to "Programming Tools".
Part three brings two "Case Studies in Developing Programs". Chapter fifteen introduces the case studies. The first study, "Contacts Book" is in chapter sixteen and the second, a "Pedestrian Crossing Simulation" is in chapter seventeen.
Part four is "The Java Programming Language in Detail". This is the more reference portion of the book and it's seven chapters cover variables, types and expressions, flow-control, classes and packages, inheritance and interfaces, exception handling, threads and concurrency.
Part five is the "Endmatter" and holds ten appendixes.
The first thing to like with this book is that it has an engaging style. The style comes not just from the body text, but also from the notes, tips and references in the margins of the book. As someone who learned Java almost ten years ago, I have difficulty plowing through yet more body text explaining the same old stuff that every other Java book covers; yet, jaded and cynical as I am, I enjoyed the sparks of honesty and humour in the text.
As I alluded to in my opening remarks, this book takes the approach of trying to not only teach Java, but how to approach and actually write programs using Java. The book takes an iterative approach and emphasizes the use of testing tools. Interestingly, they use TestNG rather than the de facto standard JUnit. This is the first book that I've seen that uses TestNG; perhaps JUnit is finally getting some competition?
The book is completely targeted at Java 5. All of the code examples use the new features where appropriate. This makes the book worth considering for those that already know Java but want to finally climb onboard with the latest version.
Naturally, there is a website available at www.devjavasoft.org where all of the source code for the programs in the book may be downloaded, together with answers to the exercises and any updates or revisions of the material in the book.
One of the challenges of writing or updating a book of this size is that it's possible (nay, almost guaranteed) to miss important things. The tip at the top of page 190 is a classic example, where the reader is advised that calling System.gc() will force the Java Virtual Machine (JVM) to perform a garbage collection. This is not, and has never been, true. The most that the System.gc() call will do is let the JVM know that now would be a good time for it to garbage collect, but there are no guarantees that any collection will actually take place. With this being the third edition of the book, I expected errors of this sort to have been caught by now.
Another point to consider is that with this being a textbook the writing style is less like a mass-market book and it also includes questions and exercises at the end of each chapter. I normally avoid books of this sort, although this does seem to be one of the better ones.
I hate being picky about typography, especially with the average level being quite good these days, but this book is set in a smallish font for the amount of text on each page. It is a serif font, but I didn't find it the most comfortable to read. Also, and this is the most egregious fault in the whole book, the program listings are set in a proportional font! I could hardly believe it when I saw it. While I realize that the authors are unlikely to be responsible for the final font selections, I fear that it damages an otherwise strong book and does them a disservice.
This is a good book for learning Java. More importantly, it's a good book for learning to write programs with Java.
You can purchase Developing Java Software 3rd edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Good advice for Java 1.5 and up, but without autoboxing you'll be using primitives because of their pervasiveness in the JDK.
Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!
I can't disagree more. Most programmers already know programming pretty well, and don't need their books on specific programming languages to be diluted with general programming instruction. Each of us is a programming amateur just once (I hope), but learns many additional languages throughout his career, and I think we want those non-newbie books to be concise and get to the point.
Every new programmer must learn to program in some language, but we certainly don't need a large variety of books that cater to people at that stage of proficiency - just one or two good ones.
... is more skilled programmers. I learn new languages from the language specification. Once you know how to write code in one language, and you actually _understand_ what you are doing, picking up a new language is easy.
"It's good to learn a programming language, but it's a far better thing to learn to write programs in that language. What the world needs are less programming language books and more books on programming with the language of your choice"
Not really, I agree with Steve McConnell when in his book "Code Complete" (2nd edition) says that you shouldn't programm in a language but INTO a language.
Most of the important programming principles not on an specific language but on the way one use them. Don't limit your programming thinking only on the concepts that are supported automatically by your language. The best programmers think of what they want to do, and then they assess how to accomplish their objectives with the programming tools at their disposal. (McConnell 843)
Sigs are for morons... Wait a minute...
Please use "Int" instead of "int"... A good JVM will run this code nearly as fast, but the added bonus is that you make your code way more generic. Java is not C++.
Yeah. While you're at it, make sure to store the value of pi in a variable, just in case the value of pi changes in the future.
Yes and then they forget about the rest and you get situations like this (when asked to explain how a certain program works):
Q: So, where does this program start?
A: [no answer but a face which is one big question mark]
Q: Well a program has to start somewhere doesn't it?
A: It does?
Q: Well somebody told you how a computer works, didn't they?
A: Uhhh yeah
Q: So they told you that a processor performs instructions one at a time?
A: Yeah sorta
Q: So that means it has got to start somewhere, doesn't it?
A: Uhhhhuh
So here I got a student that after 2 years knew how to design pretty class diagrams, could explain the meaning of inheritance, overloading, overriding, etc but basically didn't know that there is something like a program "flow"!
So I'm sure that nowadays you should start with objects and classes real soon, but I still doubt the wisdom of doing it before having explained the more basic building blocks of any language.
I'm not trying to speak negatively about this particular book's contents, but just comment generally in response to a previous poster's reply. I think what we need less of is books that tell us how to use API's and control structures and logic as such. What we really need is a shift in the way we're taught to program in schools to mimic real world software creation. This book would more appropriately been titled "How to Program in Java" because development in the real world is quite different from just learning the language specifics. Software development is more about the deadlines you need to meet for the customers end and the balance between the most technical solutions and the most feasible ones. Essentially it's about the efficiency you complete a task given constraints of time and resource. We should stop writing books that just walkthrough different languages, and start teaching students in a way that places them in team projects and make them collaborate to complete projects. My undergrad school had only ONE class that was designed in this fashion, yet I would say that almost 100% of my work existence operates in this reality.
So why not just write a class called FormattedText and define a String member variable rather than make String a base class? After all, the methods you'd inherit from String are all relevant only to the actual character content, not formatted character content, and so can be called on the toString method.
A good JVM will run this code nearly as fast...
Translation: "Lots of JVMs will run this code so slowly that your customers will think their machines have locked up."
In some cases it is possible to control what JVM your customer uses. I once managed a Java dev team that produced great, fast code, including excellent Java3D graphics stuff. But performance on some customer's machines was terrible, because they were running one of those all-too-common JVMs that wasn't so good. My solution was to ship a good JRE as part of our install, hidden away in the application tree and used only by our application (thereby not breaking every other application on the machine that depended on the bad JRE's bugs.) This increased the size of our installer by 15 MB or so, but it was worth it to get a better customer experience. Our support calls dropped to almost nothing after that.
However, not everyone shipping a Java application has this luxury, particularly those writing fo rthe Web. To suggest to those people that they should adopt some particular programming practice because it won't cause major issues with a "good" JVM is like telling a drowning person that water is necessary for life. It's true, but it isn't the least bit relevant to the practical predicament the person is in.
Blasphemy is a human right. Blasphemophobia kills.
Besides, continue is just a fancy way to do a break followed by a goto. Anything that keeps manual goto statements out of code is a good thing.
Right, because goto's are ill-advised because they're spelled G-O-T-O, but if you have something that does essentially the same thing but uses a different name, then it's okay.
Sometimes theory has to bend to make room for the practical.
I do not fail; I succeed at finding out what does not work.
Java is not C++.
Neither is it C# - you'll be wanting Integer, not Int, except that for large amounts of number crunching that's a truly horrible idea. Mind you, for large amounts of number crunching Java isn't a particularly good idea in the first place if performance is key.
It's official. Most of you are morons.
I'll be the first to defend the fantastic job dynamic compilation can do (such as automatically inlining calls to virtual function if it decides it can - and uninlining when it can't anymore), or the GC (like the new generation pretty much behaves as allocating on the stack).. BUT.
This is just moronic.
True, javac and the JVM will automatically translate Int(eger)s in ints when they can, and thus it will be as fast... As long as you don't store it in an object, or pass it to a virtual function that the JVM can't inline. Because then it has to create the actual object, it will have to dereference it everytime it's used, and the GC will have to deal with it.
Second, it's not "more generic" in any way, since Integer is final - so you can't specialise - and, OTOH, java will autobox an int as needed - so you're not actually gaining anything -.
Third, using Integer opens you to NullPointerExceptions
This is the kind of "rule", defended through a lack of understanding of what's going on behind the scene, that is causing much of the performance problems some Java programs have.
Learn the libraries to write fast code. Don't concatenate, use StringBuffer-s. Don't use buffer.append("a" + "b") - kinda defeats the purpose :) . Don't copy arrays to add an element, use Vector/ArrayLists. Don't do linear search, use Hashtable/HashMap. Don't insert into sorted arrays/vectors, use TreeSet. Don't search inside a Vector, use HashSet. Learn how to write objects that can be hashtable keys (i.e. they must have proper equals() and hashCode()). Learn how to write objects that can be used inside Tree-s (i.e. they must be Comparable-s that have proper equals() and compareTo()). Learn how to make objects sortable or implement Comparable correctly.
Yeah, kinda basic but you will be amazed what kind of speed improvements you can get by learning these and using them whereever it is appropriate. With the proper data structure (most of them are already in the JDK) your app will fly.
Oh, and don't redraw AWT/Swing like crazy. That's why the app is so slow. Learn how to use invokeLater to avoid deadlocks/bad data, etc.
Learn how to synchronize properly with no deadlocks and what wait() and notify() are for.
Learn char and byte streams and learn memory streams (ByteArrayInput/OutputStream, etc).
Learn to love try-finally for dealing with streams.
Learn to log.
Learn by writing actual app code. Nothing beats that.
In my University, I was taught general concepts: structures, recursion, iteration, abstractions, conditions, logic, programming paradigms, etc., never tied to a specific language. In fact, we used to use a pseudo-language to express solutions to problems.
Real languages (Pascal, X86 assembler, basic, fortran, C, Java, C++, scheme, SQL) were used only in lab practices. It was pre-supposed that you already knew them or you had the basic concepts to learn them.
Whenever I see that someone has been taught an specific language at the university (sometimes a whole semester!), I tend to think that this person will not be able to fullfil his/her position, because he/she has been taugth an specific technology instead of knowledge. It's like a doctor that has been taught how to operate certain medical device instead of how the human body works.
Learn principles and then you'll be able to tell which language is the best at the job.
And as a nice side effect, you'll always be able to catch up with whatever shows up in the ever changing madness of IT.
I am surprise nobody covered "Head First java". Its one of the best books to learn core java. Your fundamentals are clear once you read this one and moreover you won't sleep reading this book. One of the best books that i have seen on java.
And don't forget about StringBuilder
Do you really need thread-safe access to your buffer?
Every little helps.
"There is nothing nice about Steve Jobs and nothing evil about Bill Gates." - Chuck Peddle