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

Both books?

[fishybell]

Once you've read these two books (or just one if you're a cheapskate)

Being the cheapskate that I am, I would hope that either book would be sufficient to learn a programming language's syntax, nuances, etc. Unless I've never programmed before and expect to learn to be an professional level programmer in Java, one book should be enough to cover my needs.

Re:dont like java

[v_1matst]

er... Java -does- come with a compiler: javac.
It comes with the SDK... javac == java compiler... It compiles into byte code which the virtual machine then handles for whatever platform you are on. There are other specifics obviously, but that is the general idea. Perl and the like however do -not- have compilers as they are an interpreted language... and therefore have interpreters...

Re:Exceptions

[wcbrown]

I know how important exceptions are. If you read the review, I noted how refreshing it was that HFJ actually offered an entire chapter dedicated to it.

Rare and common, in the context, meant rare and common among Java books. That's all I meant.

Re:dont like java

[necio_online]

This is not longer true. You can compile perl code.

perldoc perlcompile

What If You're a C++ Developer?

[puppetman]

If you're a C or C++ developer, you probably won't need either of these books - Eckel's Thinking In Java will probably do you just fine, and you can download it for free.

Re:What If You're a C++ Developer?

[puppetman]

This looks interesting:

http://www.amazon.com/exec/obidos/tg/detail/-/02 01 612461/102-3787245-0027333?vi=glance

Just googled "C++ for java developers"

Some Prices for the interested

[camilita]

Barnes and noble: $35.99
Amazon: $31.49

Re:Java is easy - except it isn't

[wcbrown]

That's good advice. That's the thing I liked most about HFJ: the test-driven development emphasis. Why they didn't get into JUnit is beyond me.

Re:Exceptions

[CraigoFL]

Trying to open an stream to a file that doesn't exist is exceptional, because the app should have checked this before attempting to open the stream.

Allow me to disagree with this (and explain why). I believe that this line of thinking is just a throwback to the C/C++ days, when there wasn't any other way to do it.

So, you want to open up a stream... that's something along the lines of:

File foo = new File( "foo" );
FileReader reader = new FileReader( foo );

Now, what you're suggesting would go something like this:

File foo = new File( "foo" );
if ( foo.exists() ){
FileReader reader = new FileReader( foo );
} else {
System.out.println( "File is missing dammit" );
}

However, the FileReader constructor must declares that it throws a FileNotFoundException.. there's no way to force the programmer to check if the file exists beforehand. So you have to wrap in try/catch (or declare the exception in the calling method of course):

try
{
File foo = new File( "foo" );
if ( foo.exists() ){
FileReader reader = new FileReader( foo );
} else {
System.out.println( "File is missing dammit" );
}
}
catch ( FileNotFoundException e ){
// This now is (probably) impossible-to-reach code.
// What should we do here if this happens anyway?
// Probably the same thing we did before.
System.out.println( "File is missing dammit" );
}

So now you have a redundant check to see if the file exists (remember, whatever check happens in FileReader's constructor still happens). In addition, the check in File.exists() doesn't necessarily duplicate the check in FileReader(). If FileReader() does some additional (and desireable) checking that File.exists() doesn't, then the call to exists() is truly superfluous and maybe even dangerous (especially if you're dealing with multiple threads).

Instead, I like to do this:

try {
File foo = new File( "foo" );
FileReader reader = new FileReader( foo );
} catch ( FileNotFoundException e ) {
System.out.println( "File is missing dammit" );
}

This way, there's only one check. Not only do you get the performance gain (which may or may not be trivial), but you also don't have to re-do your error handling code.

I believe that, with the proper care (which isn't that difficult to have with the right training), exceptions can be used to control program flow and increase code readability. Of course, this can be abused too, just like anything else.

From newbie to J2EE

[Anonymous Coward]

You can go from knowing nothing about Java to programming J2EE systems by following this plan (I'm serious):

1. Read Beginning Java Objects. I agree with just about everything the reviewer says about this book. It's very well-written for people who've never programmed using OO before (but not for people who've never programmed in procedural), and in fact isn't even really a Java-specific book until the last third of the book. It's a great way to learn the concepts and terminology, which are all-important in the OO world.
2. Read Thinking in Java by Bruce Eckel. BJO is a great book to get the basic ideas down, and TIJ is a little too advanced for the complete newb -- but TIJ will teach you the rest of the language, the things that BJO leaves out. Also, the latest edition of TIJ does go into test-driven development.
3. Learn how to use the Ant build tool. Whether you do this from a book (Java Development with Ant is excellent) or from online tutorials, Ant will spare you much agony and will keep you from becoming overly addicted to a particular IDE's build conveniences.
4. Read Core Servlets , which will teach you the basics of servlets and JSP (the web layer of J2EE development). It will help if you already have a strong concept of the HTTP protocol from previous experience in PHP, ASP, Perl, etc.
5. Join a J2EE-focused mailing list (such as struts-user, j2eerocks, etc), and read the posts. Whoever said you don't learn via osmosis never subscribed to a mailing list -- even if only subconsciously, you will start to pick up terms and concepts such as design patterns or unit testing. Eventually you will find yourself answering the most-frequently-asked questions (usually with a link to the archives).
6. Learn how to use Struts and JSTL, using either online tutorials or a book (any will do). This will help you unlearn the bad habits of using scriptlets as they are taught in Core Servlets (see above). It's good to know what they are and how to use them, but stick with an MVC framework and JSTL for real development.
7. Now you need to fine-tune your Java knowledge. Read Sun Java Certification by Kathy Sierra and Bert Bates, which practically guarantees you'll score above 90% on the SCJP. At least you'll master all the nuances of the language that were left out of BJO and TIJ. This book should not be ignored.
8. Read Mastering Enterprise JavaBeans by Ed Roman et al. This is the final stage of your J2EE training, where you learn how to write and use EJBs. Then realize that for most applications, EJBs are overkill and go back to using DAO with JDBC or some other persistence framework. But you should still know this stuff.
9. Finally, start refining all of this knowledge by reading some patterns books like Agile Software Development: Patterns, Principles, and Practices, or Patterns of Enterprise Application Architecture. Fowler's Refactoring is pretty good too.

Of course, you should be actively engaging with these materials and coding as you go along, or none of this will stick. It took me about ten months, following this lesson plan, to consider myself a J2EE programmer -- and I started at the beginning, knowing nothing but PHP and Perl. I'm now an employed J2EE programmer (becoming a rarity in this country).

O'Reilly's "Learning Java", 2nd ed.

[The Revolutionary]

I found the first edition of this book to be very helpful in becoming proficient in the Java language and standard libraries.

It covers all of the important concepts, really in as much detail as I believe one might want short of looking at the API documentation itself, including many particularities of each that aren't quite so intuitive: types, objects, classes, interfaces, io, threads, collections, reflection, beans, Swing, and more.

Looking at the O'Reilly website, I see that the second edition of the book also includes discussions of regular expressions and NIO, the new higher performance I/O system.

I won't be purchasing the second edition of the book, but if you are new to Java, I believe I can recommend it.

You get an overview of the entire language and the important standard libraries. It provides enough detail that it can often serve as a reference until you feel comfortable using the Java whitepapers and API specifications as your primary reference.

700 pages.

If you don't have a lot of experience with really taking advantage of object orientated concepts and design, and you find yourself using Java more than C/C++, I also recommend Oreilly's, "Java Design Patterns: A Tutorial". It puts much of the content of the original Design Patterns book into a Java context, and gives you numerous detailed and concrete examples of employing these patterns in Java and especially in standard Java scenarios. It provides suggestions for how to tell if you should use a particular pattern, as well as the advantages and disadvantages of each.

I'm certain that reading it will help you produce Java code that is more elegant and more maintainable. It will also help you be more conversant in object orientated design concepts.

And oh yes: avoid implementation inheritance unless you have a very good reason to use it; saving lines of code is not generally such a reason =)