Beginning Java Objects

A few weeks ago, reviewer honestpuck looked at Head First Java , comparing it to O'Reilly's Learning Java, 2nd Edition. Now wcbrown writes with a review that starts on the other foot; he reviews Beginning Java Objects: From Concepts to Code in comparison with Head First Java. Read on for his review. Beginning Java Objects: From Concepts to Code author Jacquie Barker pages 688 publisher APress rating 8 reviewer Bill Brown ISBN 1590591461 summary This introduction to Java centers around a single application and follows it through from concept to modeling to development.

Coming to Java from ColdFusion and ASP has been a long and arduous journey. Those languages lack the strong typing, the formal structure, and the incredible power that Java offers. In the course of grappling with concepts completely foreign to those languages, I have purchased and read many books. I've read Thinking in Java, Java: How to Program, and Java in a Nutshell, all in a futile effort to learn the language in a systematic and useful way. Each book came up short in the teaching department: one covered Java too abstractly, another too concretely. Reading these books' turgid style was a surefire turn-off to the language. After a while, I realized that the problem wasn't totally with me -- that these books were not designed for newcomers to the language.

I then came across two books that changed my view of Java introductory texts completely. Both Beginning Java Objects (hereafter BJO) and Head First Java (hereafter HFJ) take beginner-centric approaches to instruction. They both seem to understand that reading computer language overviews is a necessary evil and that most books fail to connect with their readers. They both take active roles in guiding the reader through Java, though their executions are wildly different.

Two Different Styles The fundamental difference between the two books is teaching style: they're both obviously the products of serious pedagogical thought. BJO's pedagogical considerations are understated, while HFJ's are explicit and pronounced. BJO moves the reader from start to finish on a single project, introducing Java syntax and language elements as needed and largely in the final third of the book. HFJ, on the other hand, divides major topics into smaller units interspersed with pictures, diagrams, and tables in order to break up the monotony.

The effect of BJO is that each chapter builds on the previous one, thus discouraging browsing through the book haphazardly. This was the first computer book that I have read cover-to-cover, though it took me forever to get through at over 650 pages. It starts with an introduction to objects and object-oriented programming. This first section gets you thinking about the concept of objects, gradually working in the seeds of the book's example project, so that you're thinking about what objects you'll eventually need. The second part involves modeling those objects you deemed necessary in the first part using UML. It's by no means a complete guide to UML, but the author wants you to realize that UML is a vital part of the design phase.

The final part introduces the majority of Java syntax and focuses on implementing those objects you've modeled. First, the author works on a command-line version of a university registration system using the file system to persist data. Finally, she implements a GUI version using Swing that still uses the file system.

HFJ, on the other hand, reads like a computer book version of Alton Brown's cooking show Good Eats. Syntax lessons share the pages with funny anecdotes, cartoonish diagrams, silly exercises, and sidebars of various kinds. Some of the jokes and visual aids will make you groan, but they are, by and large, helpful and not too lighthearted. At first, the style seems like a gimmick but you quickly lose that sense of novelty. The book is organized around 17 topics that the authors think are important. Each chapter only marginally builds on the previous, so skipping around is both possible and suggested. The topics range from the common (objects, polymorphism) to the rare (RMI, sockets, exceptions). There's also an appendix that covers briefly 10 items that didn't quite make the cut for the book but were too important to leave out entirely. If I had to characterize HFJ's teaching style, I would describe it as visual.

Which is Better? So they have different styles, which one should you buy? I think that if you have to choose one or the other, you need to evaluate your learning style. Think back to when you learned your last language or important subject. How did you learn it? Did you systematically follow a tutorial? Or did you come up with an application and learn what you needed as you needed it? I would describe the first method as a hierarchical learning style and the second as a visual learning style. There's much more cognitive psychology here that would better inform such casual definition, but that's beyond this review.

For the hierarchical or systematic learner, BJO is the book for you. The author's presentation of an application from start to finish is very well done and the application actually bears a striking resemblance to something that would exist in the real world. The introduction of UML to the design process will warm the cockles of a systematic learner's heart. What's more, the natural progression from one topic to the next will help those learners who need structure and rigor in their instruction. HFJ might strike this type of learner as cutesy and flighty. While it's definitely a more soporific read, you really have a sense that you're learning from every paragraph and page.

The visual learner would probably not get very far into BJO because there's little code to read or practice with until the third part of the book. HFJ is perfect for this type of reader since it encourages flitting about while it entertains your brain into learning. The topics aren't covered as thoroughly as in other books, but that's because the authors are trying to present only what's necessary in order to avoid cranial overload. The book's breezy style makes for very easy reading and I more than once found myself eager with the anticipation I normally reserve for fiction of the page-turner variety. In addition, the book covers some topics, like exception handling, that I hadn't encountered in my introductory Java book adventures and it does so in a very compelling and memorable way. There is an application that is developed over the course of the book, but it's not as well integrated into the book as the one in BJO is. Unlike BJO, this book sometimes leaves you unsure of why you're learning a particular item until later. Often, though, these lapses are addressed in a sidebar they call "There are no dumb questions," but I would have preferred to see more of them.

Anything Left? Neither book, though, is perfect. For example, both books whizzed through some subjects that really deserve more treatment: exception handling in BJO and variable types in HFJ. Also, neither discussed persistence beyond the file system. In the real world, I have a feeling that file-based persistence is one of the least common varieties. I can understand, though, that dealing with JDBC and the like would have increased the lengths of the books as well as their complexity. Finally, neither book did a good job of telling the reader what the next steps in learning Java should be. Java is a huge topic and it is very confusing for the beginner to get a bearing in the Java ocean. Having an expert say "If you're interested in JSP, you should find books on these subjects next, and then these" is of inestimable benefit. Heck, it's even hard to know what areas of Java you might be interested in if your introduction to Java is casual and not demanded by work needs.

BJO omits any mention of unit testing your applications, but I think that's largely a shortcoming of having published the book in 2000. HFJ revels in test-driven development and includes writing a test as the second step of the three-part development process. Each code sample includes a test class and the authors stress repeatedly the importance of TDD. Unfortunately, they don't mention JUnita, glaring omission since the two are practically synonymous. Tests are emphasized but the reader isn't shown how to use them effectively. With the value attendant in a test-first development process, these omissions are of serious concern.

Concluding Thoughts These two books combined make for a very solid introduction to Java. Though they take different tacks, I think the categorization of people's learning style into a simple dichotomy is not realistic. People learn through a variety of means, yes, but often that variety is present in an individual. Reading both books will ensure that your learning style is covered as well as reinforcing the basic principles of good Java programming through repetition. There really isn't enough overlap between the two books to make the reading of them both tedious.

Once you've read these two books (or just one if you're a cheapskate), you should probably consider moving on to Bruce Eckel's Thinking in Java and perhaps finding a good book on JDBC or Java and XML. Eckel's book covers much of the same ground as these two, but there are some sections in his book that you absolutely must read to progress as a Java programmer (or learn them on your own, of course). Where you go after that is up to you and I would recommend a quick survey of the topics at prominent Java Web sites to see what sort of areas are available.

You can purchase Beginning Java Objects: From Concepts to Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Exceptions

[CraigoFL]

The topics range from the common (objects, polymorphism) to the rare (RMI, sockets, exceptions).
[rant]
Exceptions are one of the more fundamental (and useful) features of the Java language. Whether or not they are "in your face" (as far as source code is concerned), they exist and have the potential to greatly change the flow of your program. Considering them "rare" is a tremendous disservice to those learning how to use Java in a productive manner. I hope that this is simply the reviewer's choice of language, and not a flaw in the book iteslf.
[/rant]

Re:Exceptions

[Osty]

Exceptions are one of the more fundamental (and useful) features of the Java language. Whether or not they are "in your face" (as far as source code is concerned), they exist and have the potential to greatly change the flow of your program. Considering them "rare" is a tremendous disservice to those learning how to use Java in a productive manner. I hope that this is simply the reviewer's choice of language, and not a flaw in the book iteslf.

The problem with exceptions is that they're not so exceptional anymore. Think about it. The name implies that an exception is something that shouldn't have happened (you ran out of memory, a parameter was bad, something just totally blew up). That doesn't mean that you tried to open a file that doesn't exist -- that's not an exceptional case for a filesystem-handling object, because it happens all the time. Exceptions should be used as error handling, and nothing more. If you can clean up after an exception and try again or continue on, great. Otherwise, you should be showing/logging a useful error and bailing out. You certainly should not be basing program flow on exceptions.

I agree that exceptions are a fundamental part of Java and other languages, and they should definitely be covered by any good Java book, but any book that covers exceptions should take the time to teach the user how not to use them as well as how to use them.

Re:Exceptions

[clary]

The problem with exceptions is that they're not so exceptional anymore. Think about it. The name implies that an exception is something that shouldn't have happened (you ran out of memory, a parameter was bad, something just totally blew up). That doesn't mean that you tried to open a file that doesn't exist -- that's not an exceptional case for a filesystem-handling object, because it happens all the time. Exceptions should be used as error handling, and nothing more. If you can clean up after an exception and try again or continue on, great. Otherwise, you should be showing/logging a useful error and bailing out. You certainly should not be basing program flow on exceptions.

Ah, but in practice, exceptions are used for just such not-so-exceptional circumstances. This is not a choice that can be made by Java applications programmers since a bajillion Java API classes work this way.

One could argue that this is a good thing, that checking for things like file not found in a catch block instead of checking return values inline can lead to cleaner code.

The Java API defines java.lang.Error (and to some extent java.lang.RuntimeException) for those "real" error cases, those cases that might require logging an error and bailing out.

I'd be interested in anyone's favorite references on when it is better to report non-success status in return codes, and when it is better to throw an exception. That is a class design issue that comes up all the time.

Re:Exceptions

[CraigoFL]

The name implies that an exception is something that shouldn't have happened (you ran out of memory, a parameter was bad, something just totally blew up).

Well, you can (and I will) make the arguement that Java has a slightly finer-grained approach to what you just described. In addition to the class Exception, there's also the class Error, and both implement the same interface Throwable.

IMO, the names are appropriate. An Exception means that a method encountered a condition that it can't express in terms of its return value (thank god we don't have to deal with all those result-structs of C/C++). We generally associate this with "bad", but really it doesn't have to mean anything other than "out of the ordinary". An Error takes one step closer to "bad" with it's harsh-sounding name.

Note that, in your examples, the running out of memory condition causes an OutOfMemoryError, not an Exception.

The issue becomes recoverability; an application could probably recover nicely from a FileNotFoundException (perhaps by creating a new file and continuing on merrily?). However, most apps (more specifically, their programmers) wouldn't have any idea what to do if they ran out of memory; hence, you generally don't catch Error, even though it's possible to do so.

I agree that exceptions are a fundamental part of Java and other languages, and they should definitely be covered by any good Java book, but any book that covers exceptions should take the time to teach the user how not to use them as well as how to use them.

I agree with your agreement. :-P Too many tutorials gloss over them. They are very powerful and make a programmer so much more productive, but yet aren't really all that complicated. I'm usually "disappointed" (to borrow a recent cliche) to see how often they're considered a specialty feature.

FYI, here's some javadoc links:
java.lang.Exception
java.lang.Error

Re:Exceptions

[Osty]

Ah, but in practice, exceptions are used for just such not-so-exceptional circumstances. This is not a choice that can be made by Java applications programmers since a bajillion Java API classes work this way.
One could argue that this is a good thing, that checking for things like file not found in a catch block instead of checking return values inline can lead to cleaner code.

If Java forces you into using non-exceptional exceptions and using exceptions for program flow, then Java is poorly designed (I'll admit that I haven't used Java in some four years, though I have been using C# for the past 6 months and I've not yet run into a scenario in C# that requires me to handle an exception for a non-exceptional error case). And as far as making the code cleaner, I disagree. The extra syntax you need to handle an exception is clutter, and can put significant space between the error handling code and the code that caused the exception, making the flow harder to follow. Most importantly, however, exceptions are expensive. In C++, for example, an exception costs you around 1000 processor cycles. Compare that to two or three cycles to check a return value, and you'll see why exceptions should only be used for exceptional cases. Java and C# may handle exceptions differently so that they're not as costly, but they'll still be more costly than a simple comparison and jump.

You may think I'm splitting hairs, but you'll notice a marked performance increase if you rewrite your code to use normal flow control constructs to control the flow of your code, rather than using exceptions.

I'd be interested in anyone's favorite references on when it is better to report non-success status in return codes, and when it is better to throw an exception. That is a class design issue that comes up all the time.

I don't have any references, just this rule of thumb: If an error is unexpected, then it's exceptional and should be handled with an exception. If it's an expected error, then it should be handled with a return code. To go back to the example of opening a non-existent file that I used in my original post, it's pretty obvious that a file not existing is non-exceptional (now, if the file that's missing is a critical config file that your application requires and can't generate on the fly, you should throw an exception, but the library method to open a file stream should not). What has been done before is to provide two methods. One checks the existence of a file, and will return true or false, and the other opens a stream and throws an exception if the file's not there. In that scenario, you really should check for the file's existence before opening the stream. Personally, I wouldn't write a method in that manner, preferring to return an error code if opening the stream failed so that it's not necessary for the user to make an existence check first.

Re:Exceptions

[Electrum]

What has been done before is to provide two methods. One checks the existence of a file, and will return true or false, and the other opens a stream and throws an exception if the file's not there. In that scenario, you really should check for the file's existence before opening the stream.

That method is completely wrong. It contains a race condition: the file can be deleted or renamed after it is checked but before it is opened.

Too many beginner books?

[Osty]

The problem I've generally had with books about programming languages is that they almost invariably start out with several chapters (anywhere from one to five) dedicated to concepts that either you should already know, or that you should learn elsewhere. If I have a library of 50 computer books, I only want one book that covers object oriented programming concepts, for example. I don't need nor do I want all 50 to cover OOP. Even if I only have a library of 5 books, I'd still rather have only one that covers the basics. That way, I don't have to dig through five different, sometimes conflicting, explanations of the same concepts. Rather than dedicating the first 200 pages of a 600 page book to that and selling for $50, they should cut those pages and sell the 400 page book for $30.

Yes, I understand that beginners need books too, but even they don't need a discourse on object oriented programming every time they buy a Java, C++, or C# book. Why can't we have one or two definitive books covering basics, and get rid of that stuff in the rest of the books?

Re:Too many beginner books?

[stratjakt]

I'd say its because theres still millions of newbies out there who still think they'll become fabulously wealthy, just as soon as they learn how to program a computer.

That and once a programmer gets sufficiently advanced, their need for dead tree references diminishes to nothing. I know I rarely use any references, except maybe for the odd syntactical thing that I'll forget. (the "how do you call strncpy again?" type things)

It's not like I've nothing left to learn, it's that anything I learn from here on in will be through experience and doing.

I'm past the "this is what a stream and a class and an object is" stage, which is the real learning curve.

Rare Exceptions

[k-hell]

The topics range from the common (objects, polymorphism) to the rare (RMI, sockets, exceptions).

I think it's a understatement to call exceptions 'rare' though. It's an important part of Java, but may be difficult to fully master. At least in my programs, exceptions are far from rare! ;-)

Well, goodbye then...

[conan_albrecht]

most of it is pretty lame and deals with either printing the text or displaying some images.

If this is all you did with Java, you missed its real strength: server-side frameworks. Yes, Java didn't deliver on the client side. But it is excellent on the server side, with frameworks such as Tapestry, Struts, Servlets, J2EE (JBoss). It will be a while before .Net matures in these areas as Java has.

Personally, I've switched to Python for a lot of work, but for team-based enterprise development, Java is the best thing out there. It forces the weaker programmers to follow good programming concepts (such as forced catching of exceptions).

WHICH set of basics?

[alispguru]

Even if I only have a library of 5 books, I'd still rather have only one that covers the basics. That way, I don't have to dig through five different, sometimes conflicting, explanations of the same concepts.

Ah, but which basics? The term "object-oriented" means different things to different people. The differences you're seeing in these books are probably caused by this.

Go read this article by Jonathan Rees, and you'll see why Java OO != Smalltalk OO != CLOS OO (to name two models you've probably seen, and one you probably haven't).