Developing Java Software 170
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.
I usually buy reviewed books from /. but.... (Score:4, Informative)
Re: (Score:2)
Why purchase? A good alternative.... (Score:5, Informative)
Anyway, the Thinking in Java book is both available for free download (see URL above) and if you wish a hardcopy (or the latest release) then you can also purchase it [mindview.net]. In my opinion this is a much better book which is also presented in a more fair way.
Java User Interfaces (Score:4, Funny)
Was the ink from the first printing dry before Chapter 10 became outdated and deprecated?
Java EE 5 book? (Score:2, Offtopic)
Re: (Score:1)
Huh? (Score:5, Insightful)
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.
Re:Huh? (Score:5, Insightful)
There are thousands of books on programing in different languages. The same 'Hello World' code slapped into chapter 1 of each of them. But how many books are there that can help a good programmer become a good developer?
-Rick
Re: (Score:2)
What you're describing isn't programming, it's Software Engineering.
Re: (Score:2)
-Rick
Re:Huh? (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
A proper CS program will also teach the students t
Re: (Score:2)
Er... you may know the end
Re: (Score:2)
There are plenty of good books on software development. But we don't need one for each new language. The software development process is the same whether we're talking about C++, Java, Python, Perl or befunge. Programming is language specific. Software development is language agnostic.
Re: (Score:2)
-Rick
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2)
-Rick
Re: (Score:2)
I would even say that most programmers do NOT know programming pretty well. They know some programming and can get their day to day tasks done in a mediocre way. Anyone who's worked on a large project will know that...
And to top it off, I'd also say that working in a corporate environment, where it's typical to buy
Re:Huh? (Score:5, Insightful)
Most programming language books I've seen will give you just enough rope to hang yourself... you'll be able to write a sweet multithreaded Hello World program with a nice GUI and a database connection, but without understanding how and why to develop and use objects properly, you might as well be coding in PHP 4.
Re: (Score:2)
Naah.. Take a language like Python for instance. Suppose you're a really good C programmer, and you have to write a Python program which adds 2 to each integer in a particular array. So you write:
for i in xrange(len(array)): array[i] += 2
Thing is, an experienced Python programmer would use a more functional approach (even though the above imperative approach is also possible):
array = [x + 2 for x in array]
Or...
array = map(lambda x: x + 2, array)
It's not enough to know the syntax of the language
Re: (Score:2)
For me (an experienced C coder, and one who has never used Python), the first one is obviously the "right way" to do it. Assuming that it does what it's supposed to do, I might as well choose the way that I will understand easiest when reading it tomorrow.
Why, because then somebody else's code might look a little different than yours?
Re: (Score:2)
Re: (Score:2)
And I can't disagree more with this. Programmers who know programming pretty well are rare. A very large number stick with single language or two and are resistant to new approaches. Look how long it took for OOP to become mainstream, and I still read posts here from people who just can't see the point of it. There n
You exaggerate (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes that's a need — but it's a need that's already been met. The first thing anybody does when they're trying to get a new language accepted is to write a language reference. For Java, it's Gosling, Arnold, and Holmes [amazon.com]. For C++, it's Stroustrup [amazon.com] For Perl, it's the camel book [amazon.com]. And so on. Yes, these books meet a
Re: (Score:2)
Look at K&R. About the best goddam programming book ever. They got down to brass tacks right off the bat AND as a bonus they showed you how to be a better programmer. Not told you, showed you.
Back in the day there were three other Kernighan books everybody had. The Unix Programming Environment, which showed you t
What the world _actually_ needs... (Score:5, Insightful)
Re: (Score:2)
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.
No. Having a wealth of experience in C, Java, and Haskell (for instance) will do absolutely nothing to help you when you try to write a web server in BrainFuck.
Re: (Score:2)
Re: (Score:2)
The parent's parent had a very good point in that a great many professional programmers lack the skills to elevate their game to that of developer. The world is worse off for this as well.
I'm lucky enough to work with several guys who are genuine senior developers. I'm not a coder, but I've
Re: (Score:2)
Underscores and HTML (Score:4, Funny)
Of course, if you're really 1337, you'll pretend you're on a terminal with non-destructive backspaces and use a construct like this^H^H^H^H____ for underlining.
BAH (Score:2)
Hmmm, doesn't sound that good (Score:4, Informative)
Re: (Score:2)
Continue is the "Devil" (Score:2)
The first example of the use of continue made me want to cry!
Re:Continue is the "Devil" (Score:5, Funny)
If you're not the baby Jesus, you don't count.
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.
Re: (Score:2)
You could make the same argument about 'break'. However, whilst one can simulate the functionality of 'continue', or 'break', or even 'return' with goto, each of these keywords is significantly more specialised and limited in scope. Equating the disadvantages of goto with continue is just silly.
Re: (Score:2)
Re: (Score:2)
I disagree. If you are using an IDE that provides the option of collapsing blocks, then wrapping the code to be skipped actually makes the code easier to read.
Personal opinion :). I dislike collapsing blocks because you can't see all the code at a glance. I prefer being able to have a good overview of my code, so I tend to small, compact functions that will fit, more or less, on a single screen.
Secondly, there are situations where a break is neater and more concise than ending the loop via a condition. Compare:
Re: (Score:2, Insightful)
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 h
Re: (Score:2, Informative)
But that's a big picture view, and if that's not against the actual, conceived spirit of Java, it seems to be of little interest to many its practitioners. More than for any other language community I've seen, Java folk are a generally insular bunch, think Java is all anyone really ever needs, and that knowing how things actually work are unimportant, you only need to know how to get something to work in Java.
So
Re: (Score:2, Interesting)
Not really (Score:4, Insightful)
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)
Mod Parent Up - Wise words (Score:2, Interesting)
Java / Programming / Enlightenment (Score:4, Funny)
Yes, but what good is that if you don't know how to achieve enlightenment. Maybe what is really need is a book that teaches the Java language, AND how to go about the development process in a good way while using the Java language, AND how to achieve enlightenment while going about the development process in a good way while using the Java language. I mean, otherwise, what's the point? Or, on the other hand, maybe you just need a book that teaches Java.
a different way of learning (Score:2, Insightful)
Other Java books (Score:3, Informative)
My current favorite Java programming book is Java Concurrency in Practice [jcip.net] by Broan Goetz and others. It's not for beginners, but if you really want to understand how to write multi-threaded code in Java you need to read this book. Several times, probably, because it's a tricky subject.
Other books I like for Java are Effective Java [sun.com] (though he needs to update it for Java 1.5) and Java Puzzlers [javapuzzlers.com].
I don't know of any books that are good descriptions of the Java 1.5 features for experienced programmers. Some people like Thinking in Java [mindview.net], but it seems pretty wordy to me. I originally learned Java from Java in a Nutshell [oreilly.com] but it's been something like 8 years, so I don't know if the newer editions are any good.
Disclaimer: some of the authors of these books are my co-workers, though I don't know them very well.
Re: (Score:2)
Re: (Score:2, Insightful)
StringBuffer, Hashtable/HashMap, Vector/ArrayList (Score:5, Insightful)
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.
Re:StringBuffer, Hashtable/HashMap, Vector/ArrayLi (Score:3, Interesting)
You don't know as much as you think you know, especially about Strings. To begin with, I suggest you do some Google searches for the phrase "Premature optimization is the root of all evil." Now then...
You don't seem to be aware that the following two lines are either identical, or so close to identical in their execution that you will never be able to discern the difference with any debugger or benchmark:
System.out.println("The product of " + a + " and " + b +
Re: (Score:2)
*gets out popcorn and settles in to watch*
Re:StringBuffer, Hashtable/HashMap, Vector/ArrayLi (Score:2, Insightful)
Do you really need thread-safe access to your buffer?
Every little helps.
Re: (Score:2)
Learn the fundamental principles first ... (Score:3, Insightful)
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.
Re: (Score:2)
Elsewhere though? Learning language specific concepts is quite useful. You can later on "translate" them to another language.
I'm not necessarly talking about a semester just teaching the language itself here, but more like learning the advanced, langua
My first thought ... (Score:2)
And more important than either of these is to be able to successfully modify programs in that language.
Very few of the jobs I've had in several decades of working as a programmer involved writing programs. Far more of the jobs in the real world consist of modifying a program that already exists, either to correct bugs or to add new features. This requires a very different set of tools and ta
Grammar nazi (Score:2)
What the world needs is fewer programming language books.
I didn't want to get all Lynn Truss on the lad, but hey, if he can be picky about typography, I can be picky about grammar.
Re: (Score:2)
Speaking of Lynne Truss, have you read this delightful review of her book?
http://www.newyorker.com/critics/books/articles/0
-David
Re: (Score:3, Insightful)
Re: (Score:2)
Autoboxing still comes at an instance-construction expense, no matter how well-tuned the implementation.
I'd much rather see signatures that distinguish between intrinsic and box arguments, as it allows fine-grained performance tweaking.
I am rather disappointed that we still don't have unsigned types in Java. It really is critical for providing efficient mapping of XML types, database types, and CORBA/IDL/IIOP interfaces. I'm also going to have to find an appropriate library that will map Java's 64-bi
Re: (Score:2)
Re:No basic types (Score:4, Insightful)
Sometimes theory has to bend to make room for the practical.
Re: (Score:2)
I'm not the poster of your post's parent, but I did a bit of searching (since I was interested too), and in most cases it seems to be simply that he believed that unsigned types just add complication to little real benefit. He often cites that Java was supposed to be reasonably simple to understand the semantics of, and that unsigned types tend to dilute that. I tend to agree (I never really "got" unsigned types), but here's some indicative quotes:
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
By "emulate unsigned arithmetic", do you mean jumping to the max value when you remove one from zero? Is this something you need to do frequently?
Re: (Score:2)
This requires upcasting the byte to an int and doing a bitwise & with 0xFF to wipe out the sign. Then you do your arithmetic with the ints and then downcast back to a byte if need be.
If you think this rare, realize that there are all sorts of byte streams out there that were not created by Java applications,
Re: (Score:2)
What a pain. Cheers for that clarification. I realise it's not rare, but it is an interoperability issue rather than a direct issue with Java in and of itself.
Re: (Score:2)
Re: (Score:2)
Yeah, along with (generally) requiring a VM, I suppose. I expect it was something of a pain in the ass for the JNode team...
Re: (Score:2)
Try this:
Re:No basic types (Score:4, Insightful)
Re:No basic types (Score:5, Informative)
First of all, String and the primitive wrapper classes are used by most of the core classes like ClassLoader and Class. If they could be overridden, it would be a gigantic security hole. Also, many crucial mechanisms rely on those classes' immutability, so allowing for the possibility of a mutable subclass would introduce considerable instability.
Second of all, people all too frequently seem to want to use inheritance for every task. Inheritance is not a toy. It's a String and some other data, not a new kind of String or a String with specialized behavior. Subclass when you must, not whenever you can. As someone else pointed out, you're far better off using a class (such as java.text.AttributedString) that aggregates a String and your other attributes of interest.
Re: (Score:2)
Actually, these days people all too frequently seem to want to use interfaces for every task.
Re: (Score:2)
Yes, I imagine, sometime in the far future, someone *might* possibly think about a different implementation. It happens rarely. In the meantime I have two pieces of code to update every time there is a change to a method signature.
Re: (Score:2)
Re: (Score:2)
First of all, String and the primitive wrapper classes are used by most of the core classes like ClassLoader and Class. If they could be overridden, it would be a gigantic security hole.
One could get around this problem simply by restricting the effects of the overrides to a subset of classes. For instance, one could restrict it to a certain namespace, or a certain application domain. I should point out that the JVM-based language Nice [sourceforge.net] allows one to override existing methods without incompatibility issues with standard class files, so it's quite possible to have the functionality described without compromising security.
Re: (Score:2)
You mean like CharSequence [sun.com]?
Re:No basic types (Score:5, Insightful)
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.
Re:No basic types (Score:5, Informative)
It allows the same binaries to run on Windows on different processors -
Java may not perform quite as fast as C/C++, but the difference is neglible, and is only noticable in applications requiring alot of processing.
Actually, it can be the other way around. The more processing, the more chance that the run-time profiling and optimising gets to work, the faster Java runs.
Java programs are however slower to start, since they require that the JVM be started and the JIT compilation to be performed.
The JVM starts fast, and modern Java does not require any JIT compilation before the program starts. Instead the interpreter starts running, and hotspot optimisation kicks in later.
The Swing toolkit, IMO, does a huge disfavor to Java in this regard. Because the entire toolkit is emulated, making the GUI slow, contributing to the general perception of Java as slow.
Was true years and years ago, not now. It isn't all emulated - Swing uses DirectX to write to displays on Windows, for example. I am not actually sure that 'emulated' is meaningful. Swing draws controls using the Windows graphics API. So does every other Windows app. These days, having custom controls is very common (just look at media players).
I much prefer the SWT toolkit, since it both integrates better with the native environment and performs better.
Not true any more either. SWT has a reputation for actually being slower than Swing on at least some platforms, such as X. (Anyway, what does 'native GUI' mean on X-Windows anyway?)
In fact most people wouldn't be able to tell a Java SWT app apart from a C/C++ GTK/Windows/Mac application.
With Java 6, the same is true for Swing - a lot of work has been put into that, especially with the Vista interface.
Re: (Score:2)
To be fair to Sun and to Swing, they have been improving that library greatly in the last while. The version of Swing which comes with Java 6 (released the other day) is actually really quite good.
Re: (Score:2)
This isn't true.
http://en.wikipedia.org/wiki/Common_Language_Runti me [wikipedia.org]
"Common Language Runtime (CLR) is the name chosen by Microsoft for the virtual machine component of their
Just because you have JIT compilation does not mean you aren't using a VM. The combination of VM and JIT has been around for decades.
Re: (Score:3, Insightful)
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.
Re: int vs Integer (Score:2)
Exactly why I use Integer over int in most cases. With int, you cannot have an undefined value, with Integer you can. Sometimes, the int/Integer may be optional. If there is data there (!= null) I can use it, else I won't. With an int, you can't do that check, it is always defined.
So, like most programming decisions, it all depends on your needs.
Re: (Score:2)
Re:A Leveling book. (Score:4, Funny)
You know, I bet it's also a good book for learning how to develop applications with Java.
Re:Gee whiz, what a true and deep nugget of wisdom (Score:2)
Re:Gee whiz, what a true and deep nugget of wisdom (Score:1)
Funny, I was reading that and thought to myself that it was overqualified. What they ought to say is It is good to learn many programming languages, but it is a far better thing to learn to write programs
Re: (Score:3, Funny)
I can't recall ever having a grade on anything I've written drop from an A+ to a C- based on what font I used. This guy REALLY hates proportional fonts.
Re: (Score:2)
Re: (Score:2)
One scandinavian photo magazine, using 1 - 10 grades is actually so bad that you actually have to recalculate the grades. The grades almost always land in the 5 - 10 range, where 5 would mean utter crap. One pretty effective way of dealing with this is to subtract 5 from the original grade and use the result as a grade in the range 1 to 5. So far this "tactic" has worked p
Re: (Score:2, Funny)
Re: (Score:2, Funny)
Re: (Score:2)
Re: (Score:2)
Not saying it's a bad book. I agree strongly with his statement about recent college grads needing more knowledge about how to develop software. It's just hard to take