Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Books Media Book Reviews

Java Enterprise In A Nutshell 103

Posted by timothy from the shouldn't-that-be-a-beanpod dept.
g00mba_b0y writes with this review of O'Reilly's Java Enterprise In A Nutshell. "As the name implies, this massive tome (971 pages stem to stern) covers a mind numbing range of technologies associated with 'Enterprise' Java software development. There are 17 sections in all, as well as your standard API reference pages. As you would expect, all of the usual suspects are there - Servlets, JSP's, EJB's, JNDI, RMI, CORBA, etc. In addition there were other enterprise technologies that I found useful as well - Messaging, SQL, Java Mail and so on." Note his disclaimer ("I am an avowed O'Reilly technical series fan, and proud of it. Whenever I want to understand a new technology I head to the O'Reilly shelf in my local Borders before I look anywhere else. So adjust your expectations accordingly.") and read on for the rest.
Java Enterprise In a Nutshell
author Flanagan, Crawford, Farley
pages 971
publisher O'Reilly
rating 4 out of 5
reviewer Jonathan House
ISBN 0596001525
summary Quick reference for Java Enterprise technologies.

The Long Version:

When I sat down with this book my intention was to skim through each section, look to see if there was anything that they missed, and crank out the 'ol review. What I found was enough content in each of the technical sections to draw me into actually reading the whole section. I mean, who would take the time to read a full section on CORBA nowadays unless there were interesting things there (yes, I see all of you CORBA proponents shaking your fists out there -- don't you have some IDL to write?).

Once I completed the reference sections I cracked open the latter half of the book to take a peek at the API section. I found it well organized, aesthetically pleasing, and about as useful as a screen door on a submarine. Note that this API publishing is not unique to O'Reilly -- It seems that most of the technical publishing companies still commit arboreal mass murder to publish these API sections. Note to publishers: When the half life of the information you are printing is measured in months, think about a different delivery mechanism. I actually timed how long it took to find a reference using JavaDoc API info and a book. IIRC the JavaDoc lookup was about 3 times faster.

Enough of that drivel. Back to the review. As you read through the different technical sections of this book the individual styles of the authors become apparent -- you can tell that different sections are written by different authors. This is A good thing -- you are getting the technical poop from the one that knows the subject best. To rely on a single author for this size of reference would leave a lot of gray area.

There is one specific area that I want to drill into, and that is the technical examples. I consider myself a relatively informed and skilled enterprise software architect (in the J2EE world -- don't get me started on that Dot Net crap). When I see a manual entitled Java Enterprise - I am expecting not only an API reference (see API rant above), but some real meat as to best practices in building enterprise level applications using this technology.

So how did this book do in the technical example area? I'd have to give it a "B." In most cases the examples were adequate to explain the technology at hand, but not really give deep insight into how best to take advantage of said technology. Now, don't get me wrong -- this book has earned a place on the "near" bookshelf (the place where I keep all of my most referenced manuals). My opinion is that when you are trying to serve to very different purposes (desktop reference / enterprise technology primer) something has to give.

Let me give a couple of examples of what I am talking about:

  1. In the JDBC section there is a point where the book identifies OODBMS (Object Oriented DBMS) databases as a possible alternative to the rigors of Object/Relational mapping. Yes, the technology exists and does work, but how many companies out there run enterprise systems off of OODBMSs? It's a small market, and with the massive investments that most US companies have in RDBs, that equation is not going to change soon. To say that OODBs are an alternative is a good thing in a quick reference, but in my opinion needs a disclaimer if mentioned in an enterprise Java book. Along those same lines, it wouldn't have hurt to mention some of the available O/R mapping tools out there (go Open Source!).
  2. In the Servlets section there is a point where an application implementation is mentioned to illustrate a technical point (binding a java.sql.Connection instance to a HTTP session). Right in the same paragraph the author mentions that this is a "bad idea" (no kidding -- unless you are an Oracle sales rep ...). Now why go to all of the effort of painting this example, and then telling the reader that they shouldn't ever do it? Guys, take the time to figure out a valid example that illustrates the part of the API that you are explaining, 'kay?

Again, don't get the wrong idea here. I'm definitely not panning this book. It's a valuable resource and worth the $30 - $40 that you are going to plunk down for it. But if you are going to write a desktop reference for Enterprise Java make sure that the examples are restaurant quality. After all, there is enough bad code out there in the world, and we can't have our beloved O'Reilly contributing to it, can we?

In Summary (Finally! he's almost done!):

As I mentioned before, this book has earned the right to be within arm's reach from my little work pod. Not only is it a comprehensive reference, it makes a handy workout aide as well (971 pages...). And do yourself a favor. If you haven't checked out the O'Reilly line of technical books, head down to the nearest bookstore, grab yourself a double latte (try the Irish Cream and Hazelnut mixed together), find a comfy chair and give the series a once-over. You'll be glad you did.

You can purchase Java Enterprise In A Nutshell 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.

Java Enterprise In A Nutshell More

Java Enterprise In A Nutshell

Comments Filter:

  • Huh? (Score:5, Funny)

    by grub ( 11606 ) <slashdot@grub.net> on Thursday May 15, 2003 @12:02PM (#5964847) Homepage Journal

    Java in a Nutshell??? Aren't they called coffeebeans?

    Sorry, feel free to obliterate my karma for that lame one.

  • webservices (Score:5, Interesting)

    by ramzak2k ( 596734 ) * on Thursday May 15, 2003 @12:03PM (#5964871)
    Dunno , I think i will pass up this one. J2EE 1.4 is around the corner and has a whole slew of webservices related protocol made native including SOAP, WSDL, JAX:RPC. This would be outdated in no time

    • Re:webservices (Score:4, Funny)

      by American AC in Paris ( 230456 ) on Thursday May 15, 2003 @12:21PM (#5965084) Homepage
      J2EE 1.4 is around the corner and has a whole slew of webservices related protocol made native including SOAP, WSDL, JAX:RPC. This would be outdated in no time

      ...just remember that you'll need to be able to support things like IRRW, SWIP-3, Turbo ND, and ARD(i) just as soon as the marketing machine can crank 'em out--and they won't be in J2EE 1.4!

      J2EE 1.4 is gonna be great, sure, but there's an entire universe of coding fads yet to be discovered, and your boss will be clamoring for you to stay ahead of the game. J2EE 1.4 will probably be as relevant as soda-cracker punch cards by the week before it's release--mark my words...

    • Re: webservices (Score:2, Informative)

      by mocha ( 52890 )
      O'Reilly is publishing "Java Web Services in a Nutshell", which I started to edit but Brett McLaughlin completed. The author is Kim Topley. It will be available in June.

      Robert Eckstein
      O'Reilly and Associates

  • 971 pages (Score:2, Funny)

    by GigsVT ( 208848 ) *
    971 pages ... ORA must have some huge nuts.

  • I've given up... (Score:5, Insightful)

    by forgetmenot ( 467513 ) <atsjewell.gmail@com> on Thursday May 15, 2003 @12:16PM (#5965021) Homepage
    ... on Java books:
    - They're outdated within months.
    - As a general rule I've found the individual APIs are too complex to be well-served by books that cover a broad spectrum.
    - The official specifications have all the information you need anyway.

    The way to approach Java is pretty much the same way you approach programming languages in general: don't try to master them all, pick one or two and excel at that. With Java - there's a lot of APIs and many ways to skin the cat. Select the one methodology you're most comfortable with and concentrate your skills there. I'm not saying ignore all the other APIs, just don't spread your knowledge too thin. And not everything needs to be done with EJBs!

    Incidentally, I used to own just about every O'Reilly java book published. Found I never used them, the online javadocs had everything I needed already.

  • Wow... (Score:5, Insightful)

    by TopShelf ( 92521 ) on Thursday May 15, 2003 @12:18PM (#5965044) Homepage Journal
    When I sat down with this book my intention was to skim through each section, look to see if there was anything that they missed, and crank out the 'ol review.

    Now that's in-depth reporting! Did this guy come from the NY Times? Actually, I wouldn't be surprised if a healthy portion of "reviews" are done in such fashion, even in professional rags.

    • Re:Wow... (Score:3, Funny)

      by bigjocker ( 113512 ) *
      Well, the editors don't read the site, the posters don't RTFA, do you expect the reviewers to RTFB?

    • No, that is nothing -- the following is an actual review for a book I saw on Amazon.com:

      Free Review Chapter looks impressive, March 24, 2003 Reviewer: karthik (see more about me) from India
      I went through the free chapter available for download at oreilly's website. It hosts the Junit Chapter for free. I'm in the process of setting up an automated test framework at my work place. Got to admit, it definitely helped. It did'nt have any chapters on ANT integration with JUnit, but looking at the contents ,

  • Nutshell? (Score:4, Funny)

    by 1u3hr ( 530656 ) on Thursday May 15, 2003 @12:20PM (#5965075)
    Oxford Dictionary: "in a nutshell -- in few words"

    O'Reilly: "in a nutshell -- in 971 pages"

  • Is he crazy? (Score:4, Interesting)

    by Captain Rotundo ( 165816 ) on Thursday May 15, 2003 @12:23PM (#5965105) Homepage
    My last "Java In a Nutshell" practically fell apart from all the API look-ups. I rather like the API reference at the end of the book. and my current Enterprise in a nutshell is heading the same way, along with my Perl in a nutshell while I'm at it.

  • Enterprise? (Score:3, Funny)

    by Anonymous Coward on Thursday May 15, 2003 @12:30PM (#5965166)
    Now where's that Sun memo that said not to use java for the enterprise.

    In a nutshell, don't use it for the enterprise!

    • I can never get a consistent definition of "enterprise application". Here is a collection of candidates from c2.com:

      Complex business logic
      Access to relational databases
      Distributed computing, generally using some sort of remote procedure call or remote method invocation protocol
      Distributed transactions
      Data exchange between heterogeneous systems
      Message-oriented middleware
      Directory and naming services
      Interpersonal communication (e-mail, chat, shared documents, videoconferencing)
      Security
      Web-browser-based clien
      • Wow, SSH satisfies at least 6 of those.

        I always wonder why people have to come up with such complex solutions to problems.

        Just the other day, we needed some type of thing to act as a hot folder for a web application that needed to copy files from one location to another remote one.

        I wrote a 6 line bash script to run from cron every minute, and simultaneously, my coworker at the other location who wasn't aware I was working on the problem, wrote a 100 line multithreaded java program to do almost the same
        • I wrote a 6 line bash script to run from cron every minute, and simultaneously, my coworker at the other location who wasn't aware I was working on the problem, wrote a 100 line multithreaded java program to do almost the same thing. :)

          No kidding. Java is a popular paddle in the BLoat races. What did Mr. 100-liner say when he/she saw yours?
    • Yeah, they used Java for the control panels on NCC-1701B, and look what happened to that.
      • It survived the crippling space-time warping conditions near a temporal rift, despite not being completely outfitted, staffed and being under the command of an inept captain?
        • Yes, you have found out my guilty secret.

          Although I have watched every episode of TOS, TNG, TAS and Voyager, and DS9 up until season 3 (I'm waiting for the DVDs), not to mention all the movies, I'm just not that much of a Star Trek geek.

          I have no idea what Stardate it is right now. I can't name the Excelsior-class starships. I know that the T stands for Tiberius, but I couldn't tell you the episode title that information was revealed in. I've never had a wet dream about Deanna Troi. I don't know any of th
  • Is the API ref arranged the old way, where subpackages got their own chapter, or the new way, ala the 1.4 version of "Java in a Nutshell", where java.util, java.util.zip, java.util.logging, etc. all live in the same chapter, without the little black tabs on the side to help you find stuff?

    Obviously, the value of looking up stuff in that section is somewhat diminished when the reader is made responsible for second-guessing the placement of the content (when does "Vector" come before "JarFile" despite being

  • Gimme paper, and screw the scrollbars (Score:5, Interesting)

    by Get Behind the Mule ( 61986 ) on Thursday May 15, 2003 @12:54PM (#5965397)
    It seems that most of the technical publishing companies still commit arboreal mass murder to publish these API sections.


    Here's the age-old argument again, and I couldn't disagree more. As a medium for technical documentation, ink-on-paper just can't be beat.

    With docs on paper, you can scribble notes in the margin. You can cross-reference by jamming your thumb in one place and your index finger in the other, and flipping back and forth. With a little skill, you can get your other eight fingers into the act as well. You can lie down on the couch with it, and take it to the john. The iLoo was just a hoax.

    I hate having to scroll up and down to be able to see more than a few paragraphs. I hate having to click back and forth, or having to spread out windows on a screen, in order to be able to see two places at once. Electronic documentation just isn't natural, isn't intuitive, isn't human.
    • And it comes in handy if you're network guys can't seem to keep the proxy up for more than fifteen minutes at a stretch.

    • Bound documentation is easier to read in many cases, though I find I still use online docs.

      For me, I would rather have the documentation bound separately: say, a multi volume set of Java API's, with J2SE in one volume, and others grouped logically.

      Any amount of time I can spend reading something other than a computer screen is welcome. I find I can get hypnotized by the screen after a while, and I swear, I think my eyes are going.

    • And I must respectfully disagree with you on the usefulness of online documentation.

      I only need the docs when I am on my computer and I am always online so I always have access to documentation when I need it. And since I work from multiple locations I find it very inconvenient to lug around many pounds of dead trees everywhere I go. So I find the accessibility of online docs to be superior.

      I also think hyperlinking and searching is more effective than bookmarks and vgrepping through the index. I like
    • As a medium for technical documentation, ink-on-paper just can't be beat.

      Probably it can be equalled -->

      Cross-reference - ctrl+click on your favourite tabbed browsing environment.
      couch/loo - work is afoot. My colleague can't stop about reading /. on a Zaurus (sp?) whilst in the loo. More readable interfaces are inevitable.
      Scrolling up and down - copy and paste to an editor. I have not seen metrics but am willing to wager that a screen full of characters contain more info than a dead-tree page.

      Scrib
    • I always had the manual open while I was programming until the mid-90s. We could not have the documentation on the screen at the same time as the code, so it was easier to have the physical copy nearby. But "pasting" an example into the code requires much typing.

      By the late 90s, I had a 20" monitor and would program at 1024x768 or highter resolution. I had one project where I usually ran at 1920x1440 so I could fit several files on the screen at the same time.

      Most online technical documentation is stil

  • fear of a bad review (Score:2, Insightful)

    by Anonymous Coward

    Again, don't get the wrong idea here. I'm definitely not panning this book.

    "Because if I did, I wouldn't get any more free books from OReilly"

    Some books deserve a bad review, dont' be afraidt to write one.

  • Seriously ... (Score:5, Insightful)

    by Enonu ( 129798 ) on Thursday May 15, 2003 @12:56PM (#5965418)
    *HALF* the damn book is API documentation??? As a Java Developer, hell, as a programmer, I find it insulting that the publisher/author thinks I have enough time to waste looking through a book for API documentation where a 1 second JavaDoc browsing session will suffice. Also, I simply stay away from large books because they are hard to handle, and the binding usually cannot cope with such a large page count over time.

    Book that actually concentrate on problems and their respective solutions, or even better, those that attack from multiple angles are the programming books worth reading.
    • Yes but this is a book about enterprise programming so it needs to look big and important. Including all the API is a very convenient way of padding out a book, ignoring the fact that all this stuff is available via javadoc anyway.

      The reviewer bemoans the fact that some of the samples are a bit lightweight. To take the servlet example he gives, at least they note its bad practice. The number of reference manuals I have seen that advocate opening JDBC connections direct from JSP pages is just shocking.
    • My thoughts exactly, API documentation lookups are much quicker done with the aid of a good IDE like IntelliJ IDEA. Just type in the class name press Shift+F1 and you have the documentation. Same for function references.

      Books like this should stick to a giving a good idea of what's in each package and how to use them and skip the API reference, it's just dead weight.

  • Nutshell? (Score:1, Redundant)

    by nate nice ( 672391 )
    "(971 pages stem to stern) "

    That's a huge frickin' nutshell!

    • (971 pages stem to stern) That's a huge frickin' nutshell!

      Here in Texas, we grow 'em big!
      • That's what they say, everything is bigger in Texas. Texas Toast brand bread is good for French Toast...weird.

  • Since, given its size, the word "nut" in "nutshell" obviously can't refer to the hard covering of a seed, it must be referring to the user who is using it...

  • Reviewer Maturity (Score:5, Insightful)

    by JamesOfTheDesert ( 188356 ) on Thursday May 15, 2003 @02:20PM (#5966189) Journal
    . I consider myself a relatively informed and skilled enterprise software architect (in the J2EE world -- don't get me started on that Dot Net crap).

    I gather from this that the reviewer is not informed and skilled with .Net, but nonetheless feels confident in dismissing it as crap.

    If lack of personal knowledge does not disuade the reviewer from voicing an opinion, why should I give a rat's ass what he thinks?

    • Am not sure if you are to take that "crap" seriously. In fact, a colleague of mine asked our HR person if she had fixed the "pay-roll crap" -- he meant his address change on the pay check.

      It is a fad these days I think -- am not sure if I like it.

      I read the reviewer's statement as
      I consider myself a relatively informed and skilled enterprise software architect (in the J2EE world -- don't get me started on that Dot Net stuff as I do not know about it).
    • I bet that this was more a statement to get the readership (anti-MS Slashdot crowd) on his side. By dismissing an important MS technology he hoped to actually establish his credibility in this forum.. and it probably worked.
    • I've spent a bit of time looking at dotnet and seahash. My first impression was that Microsoft really didn't mind the taste of Java, nosiree, not at all.

      It's obvious to anybody who's coded a bit of Java that Microsoft's time with it left a deep, lasting impression. Because the dotnet api is a virtual mirror of the Java API. seahash, likewise, seems to be the illegitimate child of Microsoft's having slept with Java.

      So, no, not crap, just a cheap imitation. Bill doing what he does best: stand back while
      • > cheap imitation

        Um, in the same way that Java is a 'cheap' Smalltalk knock-off? Next you'll be telling me that Sun invented the virtual machine, byte-code, OO, and OO APIs.

        Both Java and C# are OO-lite languages ("blue-collar", as Gosling calls them) designed for rapid, uncomplicated OO development -- nothing wrong, as long as you realize languages are just tools.

        And oh, those who write c-sharp as seahash are about as pathetic as the ones who write windoze instead of windows. Wish people learnt that n
  • ... if you're worried about 971 pages of paper.

    http://safari.oreilly.com/ [oreilly.com]

    It lets you have N books on a shelf (min time one month). Not just O'Reilly books.

  • I thought this book was a great tool for coming up to speed very quick on how these technologies all fit together. I don't need all the "how to" fluff you normall get, so this just hit the spot. If I need reference, I wouldn't ever think to use a book like this, except possibly to use some of the examples to get me started.
  • Why slam object databases? It's good that the book is promoting them, we need more people doing so and raising awareness. Anybody using an RDBMS probably is aware of all those issues. Bringing up a better alternative is a good thing, and several ODBMSes are definitely enterprise capable if anybody cares to take the plunge.

Slashdot Top Deals

"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_

Close