Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

Beginning Java Objects 148

Posted by timothy from the sipping-coffee dept.
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.
This discussion has been archived. No new comments can be posted.

Beginning Java Objects More

Beginning Java Objects

Comments Filter:

  • cheaper (Score:1, Funny)

    by SHEENmaster ( 581283 )
    If you're REALLY a cheapskate, you'll convince all of your friends to learn Java. A month later, you'll have every "24 hours", "21 days", "for dummies", etc book ever written about the language.

  • Both books? (Score:1, Informative)

    by fishybell ( 516991 )
    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.
  • Looks like it all depends on if you are more of a visual learner or if you learn more from having hands on the code.

  • oreily nutshells (Score:5, Interesting)

    by 514x0r ( 691137 ) on Wednesday August 06, 2003 @01:40PM (#6626995)
    any of the nutshell books are horrible to learn from--though i find them invaluable as reference and count 4 behind me right now.

    funny alton brown ref.
    • 4? Just 4? How did you even find out about slashdot, marketing-guy? I have 7 behind me, and this is just my work collection. I have about the same at home. I tell ya, geeks these days. In my day, we had EVERY nutshell book, multiple copies and multiple versions. You didn't know if it was 2nd edition or 1st. That's the way it was and we liked it. We _loved_ it!

      psxndc

    • I have 2, C++ and Java in a Nutshell. Really, what else does a code Guru need?
      • linux in a nutshell.

        i hate to admit it, but here--at work--i have ASP in a nutshell.damn i feel dirty.
        • I borrow a persons at works ASP in a nutshell when I need it and my work has a shower for when you get that dirty feeling. But worse yet at home I have Delphi in a nutshell. Though I am began to use safari at O'reily and find it a good way to use reference in work scenario's. Get the reference you need for the project and smile as no one can laugh at your bookshelf they see behind you, only keep the linux, java, c, c++ and php books there leave asp, windows and Domino books hidden online.

        • I had the "ASP in a Nutshell" book in a previous job. It was very useful - the floor in my office sagged a bit, so I put the book on the floor under my bookcase to keep it level. It was the perfect size and served me well for over a year in that capacity.
    • Oddly, Java in a Nutshell is exactly where I learned Java. For that matter, I learned Perl from an O'Reilly book as well. I enjoyed the process a lot, and consider myself really good at both (well, proportional to the amount of time I spend programming in each).

      By that time, however, I had learned a dozen or so major languages already, so that may have helped. Once you've learned BASIC, Pascal, C, LISP, Prolog, and some assembly language, picking up any other programming language is quite painless. Whe
    • No kidding! Who reads a book that has in a nutshell in the title? There are not many nuts that are big. The analogy obvious means there is just enough information to remind you. In other words, you need to already know it!
      Am I the only one who sits down to browse through a book before I buy it? Especially when I am expecting to learn the language from it?

  • I don't know about that (Score:5, Funny)

    by Anonymous Coward on Wednesday August 06, 2003 @01:43PM (#6627026)
    ...the incredible power that Java offers...

    I have been programming Java for about two years, and did not receive any incredible powers. You can make your computer do a bunch of stuff, but most of it is pretty lame and deals with either printing the text or displaying some images. However, Java failed to deliver the promise of being able to walk on water, fly high into the sky, pass through walls and understand any language without an interpreter.

    I am switching to .NET.

    • Dude, just:

      import christ.jesus.*;

      there is the new one:

      import matrix.neo.*;

      but it's just now catching on.

    • Well, goodbye then... (Score:5, Insightful)

      by conan_albrecht ( 446296 ) on Wednesday August 06, 2003 @02:01PM (#6627170)
      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).

      • have you done it? Is it sweet? Any pointers?
        What I'm actually working on doing, if you care, is wrapping an app called dcm4jboss in jython, but I'm still trying to get dcm4jboss working the way I want. I know python and c++ (along with some others) and have read and made small changes to java. From my jython book it looks pretty damn easy.
      • Yes, Java didn't deliver on the client side.

        I don't know about that. I think that there just isn't enough work put into the GUI by most people. Creating a *nice* GUI is HARD, no matter what system you're using. Macs make it a bit easier with the philosophy that every window should be as simple as possible. However, Windows (the standard most software strives for) strives to cram as many buttons and controls in as small of a space as possible. Under Windows, your program needs toolbars, drop down menus, si

      • follow good programming concepts (such as forced catching of exceptions)

        It's arguable whether this is actually good practice. Neither C++ nor C# have the concept of checked exceptions and, after programming Java for many years, I've been toying in my head with the merits myself.

        At the very least, I think that the checked exception baseclass should be a sub-class of the unchecked exception rather than the other way around like it is in Java (RuntimeException=unchecked is subclass of Exception=checked).

    • understand any language without an interpreter
      No, it always been one language but the VM is needed I'm afraid.
    • Really, if you had done any work with Java at all, you would see that you do indeed have these powers..

      walk on water...
      Take your bloated code and use it as floats for your feet - you're walking on water

      fly high into the sky
      Stand on top of the heap and start your program - you'll be high in the air in no time.

      pass through walls
      Java uses pass-by-value, so you must convert yourself into something of value. I recommend having your face printed on currency and then slip yourself through a seam in the

  • Exceptions (Score:5, Insightful)

    by CraigoFL ( 201165 ) <slashdotNO@SPAMkanook.net> on Wednesday August 06, 2003 @01:48PM (#6627060)
    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 (Score:4, Informative)

      by wcbrown ( 184278 ) on Wednesday August 06, 2003 @01:51PM (#6627087) Homepage
      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:Exceptions (Score:2, Insightful)

      by Osty ( 16825 )

      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 exception

      • 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.

        You certainly should not be basing program flow on exceptions.

        Agreed, and Java in no way promotes this practice. Unfortunately, lazy programmers see this as an easy way out to pull crap like you mentioned regarding the file stream.

        I agree that exceptions are a fundamental part of Java and other languages, and they should definitely be covered by any good J

        • Re:Exceptions (Score:4, Informative)

          by CraigoFL ( 201165 ) <slashdotNO@SPAMkanook.net> on Wednesday August 06, 2003 @03:18PM (#6627731)
          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.

      • Re:Exceptions (Score:3, Insightful)

        by clary ( 141424 )

        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 excepti

        • Re:Exceptions (Score:2, Insightful)

          by Osty ( 16825 )

          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

          • Re:Exceptions (Score:3, Insightful)

            by Electrum ( 94638 )
            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.

            • 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.

              I didn't say it was right, just that it had been done. And of course you can use locking methods to mitigate the race condition, though by doing so it's unclear whether it's still a better approach than just catching the exception, performance-wise.

              • I didn't say it was right, just that it had been done.

                True.

                And of course you can use locking methods to mitigate the race condition

                Nope. Locking can only be done on an open file. See flock(2) and fcntl(2).

                • Nope. Locking can only be done on an open file. See flock(2) and fcntl(2).

                  Oops. My fault :) I was thinking more along the lines of a critsec or mutex to avoid cross-thread race conditions, and it totally slipped my mind we were talking about the filesystem. Hehe. Anyway, I was advocating not writing your code this way, unless you can't avoid it. However, I'm not sure it's too big of an issue. You'll still need to catch exceptions on the filestream open call anyway, in case something else fails, a

        • 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.

          It depends on how "exceptional" the circumstances are. For example, if a "file not found" condition is unexpected and requires error recovery, then it should be handled as an exception. If it is something that can occasionally happen during the normal flow of events, then the programmer s
          • the programmer should check for the existence of the file before trying to open it

            And code a classic race condition? No thanks.

            • If only one thread is accessing the file, then having it deleted between checking and opening should be handled with an exception. If multiple threads are creating, deleting and accessing files (not the best design) then I would prefer using synchronization through a shared resource rather than using exceptions.

      • Re:Exceptions (Score:5, Insightful)

        by CraigoFL ( 201165 ) <slashdotNO@SPAMkanook.net> on Wednesday August 06, 2003 @02:43PM (#6627476)
        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 [sun.com]
        java.lang.Error [sun.com]

        • A generally excelent discussion of why exceptions are nice, but I can't let this go by:

          "thank god we don't have to deal with all those result-structs of C/C++"

          C++ had exceptions & try/catch blocks many years before Java existed.
          • I'm no C++ expert, but IIRC C++ exceptions were a non-standard language enhancement available only to certain compilers. Please enlighten me if I'm wrong. :-)

            Regardless, I think exceptions are a good thing, in Java, in C++, in C#, and even in VB.NET of all places. Accept no substitutes!

            • Early versions of C++ did not have exceptions, but exceptions are now part of the ANSI standard. Java exceptions are modeled somewhat after C++ exceptions except that Java throws an exception object, while C++ can throw any type/object.
            • IIRC:
              They weren't in the ultra-super-early compilers. They were added almost imediately by every copiler vendor worth mentioning, and were in just about the first draft of the standard. The standard commitee took basically forever hammering out other obscure details, so C++ wasn't an official ANSI standard until recently.
              So if you're talking the accepted standard, everything was non-standard until a year or two ago. If you're talking the draft and/or de-facto standard, you were right 20 years ago...

              I'm
      • You certainly should not be basing program flow on exceptions.

        I tend to agree, but if you read ms's best practices around .net and web application design you would be suprised at how exceptions are working their way into common flow. Even for something as trivial as an authenticate method "token = authenticate(username,password)" they would rather you throw an exception if the password was invalid instead of a return code. In the end the flow does seem somewhat better..

        try
        {
        token = authenticate(...)

        • I'd say that's a perfect example of where exceptions are apropriate. You have a simple function (authenticate) that returns a simple value. If it can't return that simple value, it needs to alert the caller, and pass back an entirely different type of information.

          Also, if the code that knows what to do if that exception occurs is several levels up the call stack or a several blocks scopes out, you don't need to write code at every level checking for the error and passing it along.

          • Except that the authenticate function should be in its own try block so that the code that handles the failed authentication stays near it

            e.g

            try
            {
            authenticate ()
            }
            catch (AuthException e)
            { /* Log in the security log + tell the user */
            return ;
            } /* do other stuff which might be several pages long */
    • throw java.lang.URADorkException

  • Too many beginner books? (Score:5, Insightful)

    by Osty ( 16825 ) on Wednesday August 06, 2003 @01:50PM (#6627075)

    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?

    • If I had to speculate, I'd say that it was because every author thinks they bring a fresh and clearer perspective on OOP that they have to share with their readers. Or it's filler to bulk up the book. Choose based on your level of cynicism.

      • Re:Too many beginner books? (Score:5, Insightful)

        by stratjakt ( 596332 ) on Wednesday August 06, 2003 @01:58PM (#6627153) Journal
        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.
        • "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."

          I have to agree with you on that. Someone figured out they'd be fabulously wealthy if they harnessed the collective ignorance of the people who only want to get into programming for the perceived money.

          This is how you get those people in CS courses who are obviously not cut out for it. Back in first year I was writing this quiz in a CS

    • I agree. I recommend the "Language A for Language B programmer" books for this reason.. if you're already familiar with one language, you usually don't have too much troubling learning a new one... one example is this: on amazon.. [amazon.com]
    • A buddy of mine who is a published author once told me that publishers demand a thick book that "advertises itself" on the bookshelf. Many "fluffy" chapters are added for that reason, much to the dismay of the original author(s).
    • I think it's because each author believes he/she is writing the One book you will need to begin. As in: "Why would you have 5 other books on the subject when this one is the only one you need?" They're then obligated to start at the very beginning.

      It might be interesting for O'Reilly or another publisher (some entity above the Author level) to produce an "Intro to Procedural Programming" and "Intro to OOP" and similar set of books. So that when you wanted to learn something from O'Reilly books, you'd by th
    • Ah, well - it's better than having too few.

      Back in the day (i.e 5 years ago), when I started out with Java, there were only those horrid "Teach yourself Java in 21 days", or even worse, "24 hours", books around. At least that I could get my hands on so that I could learn the basics of Java by the end of the week.
      Java was still very much the Next Big Thing, expected to Save the World, and "everyone" thought it was just for web-programming and applets, and though we were mad when we started using it for a la

    • WHICH set of basics? (Score:3, Insightful)

      by alispguru ( 72689 )

      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 [paulgraham.com] by Jonathan Rees, and you'll see why Java OO != Smalltalk OO != CLOS OO (to name two models you've probably see

  • Anyone can learn Java (Score:4, Funny)

    by DavidNWelton ( 142216 ) on Wednesday August 06, 2003 @01:50PM (#6627081) Homepage
    If they can do it, so can you:

    http://www.newtechusa.com/PPI/talent.asp

  • Rare Exceptions (Score:4, Insightful)

    by k-hell ( 458178 ) on Wednesday August 06, 2003 @01:50PM (#6627085)
    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! ;-)

  • What If You're a C++ Developer? (Score:5, Informative)

    by puppetman ( 131489 ) on Wednesday August 06, 2003 @01:57PM (#6627135) Homepage

    If you're a C or C++ developer, you probably won't need either of these books - Eckel's Thinking In Java [mindview.net] will probably do you just fine, and you can download it for free.
  • This one is a great addition to the book shelf, you all know how to do certain things Java Objects but this book clarifies nicely why you are actually doing it. Also, it introduces nice advanced Java Object concepts which hardcore OOers might not have come across before.
  • Barnes and noble [barnesandnoble.com]: $35.99
    Amazon [amazon.com]: $31.49

  • Java is easy - except it isn't (Score:5, Interesting)

    by RevMike ( 632002 ) <revMikeNO@SPAMgmail.com> on Wednesday August 06, 2003 @02:07PM (#6627219) Journal
    If wcbrown thought that most Java books are tough on the beginner, he'll be in even worse straits in the J2EE world.

    The Java language itself is fairly sparse. The collection of libraries that make up the JRE (Java Runtime Environment) is immense. And java is pretty useless until you learn your way around the APIs.

    I like the language in general. The exception handling model is good. The standard APIs are rich. The namespace issues are handled well.

    Developing in Java is a pain in the ass, however, due to classpath and packaging issues. The various IDEs help somewhat, but they can also obscure these issues and prevent you from learning them. In addition, everyone knows that vi is the one true editor - and vim provides good syntax highlighting too.

    Best advice to a budding java developer is learn to use apache Ant right from the start. Using JUnit early on is also a good idea. Doing small projects with Ant and Java is far easier and more informative than doing projects in java alone or in an IDE.

  • > 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.

    Incredible powers with ducktape on C(++)? I guess it depends on the direction one's coming from. I came from the direction of C++ and python and I would never describe java as powerful. IMHO, it's a blockish, rigid, boring language with many libraries.

    Discovering Common Lisp didn't help

  • From newbie to J2EE (Score:2, Informative)

    by 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 i
  • This previous school year I took the first year of a two year computer science class (I am part of the first year where the AP exam will be in Java instead of C++ ). I will not be able to take the second year next year because of scheduling conflict but will be able to take it my senior year. Our class left off at advanced math problems being solved by recursion (the Towers of Hanoi [cut-the-knot.org] problem sticks out in my head.) What would be a good book to review what we learned this year and be prepared for my second ye
  • 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 bo
    • I took a Java class last semester and decided to use Learning Java instead of the course textbook, the abysmal An Intro to Object Oriented Programming with Java (by T. Wu).

      I knew I had made the right decision when I looked up the continue statement. The O'Reilly book said 'terminates the current iteration of the innermost loop and evaluates the boolean expression that controls the loop', whereas the Wu textbook said only 'reserved keyword -- do not name a variable continue'(!)
  • Why does the Slashdot Java icon look like a bucket of steaming poo?

    Ah. Never mind.

  • This is a good review. I liked the reviewers take on the two books and he certainly told me what he liked about the book being reviewed.

    He could, perhaps, have told us a bit more what he didn't like.

    Tony

  • My brain absorbs technical manuals like a sponge. I can read a coding reference book and write significant working code in a few hours.
    I wish I had the same power to learn human languages that way.
  • Having recently completed a physics PhD, I decided to learn how to program more rigorously. As the reviewer suggested, I read Beginning Java Objects followed by Thinking in Java. Having browsed through a few other books before reading BJO, I really think that it is particularly useful at highlighting and explaining the important concepts of OO programming. After reading this book I found that many aspects of Java that previously seemed very confusing were crystal clear and I wondered why I hadn't picked

Slashdot Top Deals

"When the going gets tough, the tough get empirical." -- Jon Carroll

Close