Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


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

Building Java Enterprise Applications, Volume I 154

Posted by timothy from the thick-and-thin dept.
David Kennedy writes: "This is a review of Brett McLaughlin's new O'Reilly title, Building Java Enterprise Applications. Volume 1: Architecture, subtitled Designing with EJBs, Databases, and Directory Servers." Read David's in-depth review, below.
Building Java Enterprise Applications, Volume I: Architecture
author Brett McLaughlin
pages 300
publisher O'Reilly
rating 9
reviewer David Kennedy
ISBN 0596001231
summary Practical guide, with examples, for building a J2EE application from scratch.

Summary:

Building Java Enterprise Applications is an excellent book, and ought to be on the bookshelf of every J2EE programmer working on the mid- and back-tier. If you are like me, then you then have a series of books on various parts of the J2EE alphabet soup -- a few on EJB/JNDIs, one on JMS, one on RMI, one on JDBC, a database/SQL primer, a J2EE patterns book (I recommend Depur et al. by the way), maybe even some hyped-up case studies from Sun's press etc -- but nothing on how to design an entire J2EE application from scratch. There is nothing scarier than a blank piece of paper at the beginning of a project -- this book provides a combination of a tutorial and worked example, along with an insight into the thought processes of the designer.

There are not enough books of this type for the J2EE platform; the emphasis on tying together disparate technologies to build a coherent system is exactly what I need at this stage of my career, and I found the author's constant revisions and tweaking of his design fascinating and reassuring. I'm going to pre-order Vols. II and III.

Check your sources.

You might recognise the author's name -- Brett McLaughlin is the author of another O'Reilly title, Java & XML*, and writes for flashline.com, IBM Developer Works, JavaWorld and others. You can either Google for these or visit the web-site newInstance. In my opinion he knows his onions, is aware of what other root vegetables are out there, and, most important, he can communicate well.

What's the book about?

I'll give you a bit of the blurb first, as it's a fair description of the material:

"Java has many enterprise APIs: JNDI, EJB, JMS, JAXP, and the other XML APIs, JDBC and more. But how do you as a developer put the pieces together and build something that works? How do these components integrate with back-end servers (databases and directories) and with front-end platforms (web servers and web services)?"

"[This] is Volume I of that series; it covers the business logic and back-end of an enterprise system, including entity EJBs, JDBC, JNDI (...), and JMS. Volume II will discuss architectures for web applications; Volume III will venture into the still-uncharted territory of web services."

That's quite an ambitious series; and something of a departure in style for O'Reilly, who have built their enviable reputation by providing definitive titles on one technology at a time. This more a book on when to use a tool, and which tool to use, rather than how to use a tool. I think it's good to see O'Reilly branching out in this way, but it brings them into the preserve of other publishers. It might be interesting to see how this new type of title does.

So what is covered in detail?

Let's have a detailed look at the contents:

  1. Introduction
  2. Blueprints
    This chapter outlines the case study that the author uses for the remainder of the book. This takes the form of a simple, but not trivial, financial-services tool. The blueprints are high-level sketches of the business need, the Data Layer, the Business Layer, and the Presentation Layer.
  3. Foundation
    This covers designing the data stores, databases and directory servers.
  4. Entity Basics
    Basic design patterns, coding and deploying beans.
  5. Advanced Entities
    IDs and CMP, data modeling and the nasty details.
  6. Managers
    Managers, in the facade sense, for entity beans and the LDAP directory.
  7. Completing the data layer
    Nasty details, populating the data store.
  8. Business Logic
    The facade pattern and stateful/stateless design.
  9. Messaging and packaging
    JMS on the client and server. Packaging.
  10. Beyond flexibility
    The wrap-up chapter, covers the major design points, discusses adapting the material to your own projects, and hints and what presentation layers may be added as a teaser for Vols. II and III.

As you can see there are no surprises in the contents. Once the high-level problem and solution is laid out, there's just a sensible progression through the layers. I particularly liked the practice of stopping and reviewing at regular checkpoints -- it helped tie the material together and emphasize the layering in the design.

There are some detailed appendices giving vendor specific instructions for databases, containers etc. This section also contains all the non-unique code for each layer, e.g., all the entity beans that weren't discussed in detail.

  • SQL Scripts
    Cloudscape, InstantDB, MySQL, Oracle, PostgreSQL.
  • SQL Deployment
    Ditto.
  • Directory server setup
    iPlanet, OpenLDAP.
  • Application server setup
    BEA Weblogic only.
  • Supplemental code listings
    All code also available in completed final form on the associated web-site.

Sounds wordy...

It's not. This is a short book, only about 300 pages including appendices and index. (Compare that to something like Roman's classic EJB book ...) Chapter content is only 200 pages. Fully a third of the content of the book is code; this is definitely one for the programmer, those of you who delight in detailed breakdowns of requirements, user stories, schedules, etc will find little or nothing of interest here.

Equally, there is little in the way of explicit (non-coding) high-level design discussion -- all the code is evolved directly from the well-written text. This is not a bad thing at all -- the design seems sensible and straightforward, always a good sign, and mostly presents an admirable example to any young programmers watching.

All this doesn't mean you are reading a listing though. As on any project involving EJBs, there is a lot of more-of-the-same code between beans -- most of this code is concentrated in the appendices, and only the material under discussion is presented. New code is always presented in full, from package declaration to closing brace. This is refreshing and permits you to actually get something working as you read through the text, although you'll need to be prepared to set up app servers, databases etc to get maximum benefit.

Target audience?

Experienced Java programmers who have started using the J2EE platform and are fairly comfortable with all the bean types, JMS, JNDI etc. This book states several times that it is not a primer on any one technology, and provides ample references to more detailed texts when appropriate.

This is very much a book for a wannabe J2EE developer who can't quite figure out how to fit the pieces together, or, like me, just has a gap in his/her skillset when it comes, to, say, LDAP.

What's good?

Lots of it. Mainly, the best thing is the clear presentation of a LOT of code via a well partitioned example application (which will also be re-used in Vols II and III). The code is of good quality too, and presents several idioms that while obvious now, were unknown to me when I started EJB work... with the usual reworking-over-a-weekend later on. In particular, there are some commonsense pieces of code -- like a nested exception class for those of us still using pre-1.4 (and remember, you're tied to what your app server supports), some simple session and entity bean Adapter classes, simple Value Object classes etc. As I said, nothing earth-shatteringly novel, but it's nice to see a lot of these idioms used together to simplify the code.

Another admirable thing about the book is the handling of the detail. I've read several books which follow the practice of putting in Gotcha! box-outs, and to be honest, few of them are that useful unless you are a novice. I'm been programming for a few years now, and was amazed at the silly difficulties I've had with my first EJB project -- as a result I'm pleased to say that the box-outs indicating problem areas sound like the voice of bitter experience. For example, there is discussion on following the correct style for accessors/mutators under CMP (getId works, getID cheerfully fails), advice on the very fixed order in the deployment descriptor XML, problems with case-sensitive searches in JNDI, etc. Those of you who've worked with, particularly, EJB1.0/1.1, will undoubtedly have groaned as you realised the problem de jour was something simple-but-outside-your-code like those examples.

Admittedly it's not my area really, but I also found the whole treatment of directory servers very clear and useful. For the first time I understood (a) how they work (b) when they complement databases (c) how to use them easily from my code. Again, I admire the level of detail achieved without being confusing -- I don't see many introductory books include things like the default port number for directory servers using SSL (636 - well, I didn't know that!).

What's bad?

Not much. By nature of the book it doesn't go into huge detail on all technologies used -- there were a few areas where I wanted more. In particular I would have liked to have seen more on testing; now that XP is pretty much mainstream, no one can deny that unit testing is vital on production projects. (When I started using EJBs I had to kludge together a nasty version of JUnit which fitted into the sub-optimal build and client-server framework we were using. I've since found that there are better ways to test EJB layers, but I can still only think of one book, by Richard Hightower, which walks you through examples.) Although the build files in the example use Ant, which makes JUnit and other tools very easy to integrate, there is no mention of unit testing. This is a pity.

The only other things that caught my eye were minor -- coding style in particular. The coding style in the book is very straightforward and Sun-standard, but I have to admit that I'd have liked more JavaDoc'ed code. The code on the website is much more fully commented. I understand that printing this means more paper, and thus a thicker and more expensive book, but on some of the custom methods it would have clarified things for me.

In particular, and I'm being picky here, I didn't find that the authors practice on handling nulls and errors fitted with my own -- admittedly I don't so much practice "defensive coding" as "paranoid coding." Most methods were not null safe, and that can be a nightmare to debug in an n-tier system. Also, he took the line of returning null to indicate failure or error. I understand it's a valid design decision -- my experience says to go with more explicit errors in a larger project, and I would have liked a page or two on the choices here.

Another area where I feel there is room for improvement in the presented style is in the use of hard-coded Strings for lookups - for example, in the AccountManager object there are several lookups of the AccountHome, e.g.: 


    AccountHome accountHome = (AccountHome)context.lookup(

        "java:conp/env/ejb/AccountHome";  // Whoops, finding this can be tough!
From experience code reviewing EJB based projects, it's going to save a lot of pain looking for typos if this repeated hard-coded String is (a) extracted as a constant so it can only be mistyped in one place and (b) refactored into a lookup method. It's a fairly minor point, but useful to do right from the start on an EJB project and worth pointing out to someone starting their first one. (Mis-typed meta-data like this is a bit of a weakness in the J2EE framework in my opinion - I always feel that I'd save a lot of time if the compiler or some J2EE aware verifier could check over those Strings to see if they match anything else in the build... I've used vendor tools which claimed to do so, but as they didn't even check that methods/lookup names were in the bean source I wasn't sure what was being verified!)

One last thing: I know it's minor, but why the insistence on importing explicitly? I feel it makes maintenance more difficult -- change one LinkedList to an ArrayList and you're off fiddly with minor imports again. I also didn't find this: 

import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.ObjectMessage;
import javax.jms.Session;
import javax.jms.TextMessage;
import javax.jms.Topic;
import javax.jms.TopicConnection;
import javax.jms.TopicConnectionFactory;
import javax.jms.TopicSession;
import javax.jms.TopicSubscriber;
as appropriate for a printed book as this: 
import javax.jms.*;
It would have been nice to trade those 10 lines wasted for some custom JavaDoc. However, all told there is remarkably little to grumble about in this book -- I couldn't even spot the obligatory editorial mistake. (That really annoyed me.)

Alternate titles?

Can't think of a good one. (Either a sign that this book is one you might want to look at or else so completely specialised as to be of use to only one person in the world, and that person is probably the author. Luckily, I think it's the former in this case.)

It is however worth a trip to the bookstore for companion, as opposed to alternate, titles before reading this - it assumes detailed knowledge of several J2EE areas, but provides suggested (O'Reilly) titles for reference.

Sounds good -- but what do you know anyway?

Time for the disclaimers. Some material in the book I found useful because I lack experience -- in particular, some database and LDAP stuff.

However, 5 years of getting paid to play^H^H^H^Hcode, and a personal reference library of some 120+ books has made it easier to spot the rare decent title! Most of my J2EE books are from my experience of EJBs for the last year or two, so I know what mistakes are easy to make, as I've made 'em. [I'm actually catching up on my reading, and hence reviewing, due to the Great Telecomms Downturn finally affecting me - anyone want a J2EE developer? :-) ] Finally, I paid for this book (which isn't the case for some of my other reviews).

You can purchase Building Java Enterprise Applications, Volume I from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

(* Bonus mini-review: a useful book, but not easy reading, I found it hard to slog through, but managed my first XLST work in about 10 minutes using it.)
This discussion has been archived. No new comments can be posted.

Building Java Enterprise Applications, Volume I More

Building Java Enterprise Applications, Volume I

Comments Filter:
  • This was an enteprise length review! You sure need to be hired in a big corporation and/or goverment to have enough spaceout time to read it. And then even have time to write a comment.

    I work for the goverment, did I say that?

    How much E17 do you want to be?

  • Wha? (Score:1, Flamebait)

    by Zen Mastuh ( 456254 )

    I thought this whole "New Economy" was dead & buried. They should have released this book last year, when marketroid expressions like "middleware", "b2b", "j2ee", yada were not yet the butt of jokes.

    • Re:Wha? (Score:5, Informative)

      by mborland ( 209597 ) on Tuesday October 01, 2002 @09:54AM (#4367131)
      I thought this whole "New Economy" was dead & buried.

      A lot of people seem to equate EJB/J2EE with dot-bombs. I think that's unfortunate, because it can be a really useful framework for development. Certainly there are times when people have overapplied EJB (used it where they shouldn't have) and there are also organizations whose projects get mired when trying to work in such a framework (but they are usually mired because they're sprawling projects, not because of the framework).

      I tend to use 'slimmer' solutions than a full-blown framework like EJB (yes, I like 2- and 2.5-tier applications). ;-) But I would like to caution those who strike out at Java/EJB/J2EE as though it's just marketing speak. It ain't all a crock, and like anything that achieves some popularity it will attract idiots who will give others a bad impression.

      • Re:Wha? (Score:2, Insightful)

        by ashultz ( 141393 )

        I like two tier applications too... it seems that often people put in a middle tier just to have 3. You can often combine the logic and the webserver on the same box (running Apache + a JSP engine, for example). Unless you've got weird load issues, forcing another level of boxen isn't useful, and slows things down.

        But then it's not "3 tier" and therefore must not be scalable. Or something.
        • I like two tier applications too... it seems that often people put in a middle tier just to have 3.

          My feelings as well. Unless you're actually going to use the middle-tier as such, it's probably not worth it. Usually I try to use functions/stored procs as a pseudo-middle-tier. This helps with basic DB security (by removing direct access to tables) and also helps enumerate and optimize queries/actions, for ease of development and faster responses, respectively.

          I used to get into battles over 2- vs. n-tier solutions (for simple apps) but now it seems that the battle has quieted, as people are more versed with the pros and cons of either approach.

        • But then it's not "3 tier" and therefore must not be scalable. Or something.

          Yeah...stuff like medium-heavy use of EJBs, esp. Entity Beans, lets you scale...and makes sure you need to.

          Seriously, I think so many EJB projects are way over-engineered anyway. I've been on a project that went down this path. Then they gave the bulk of it to a buch of Indian consultants who took a much more conservative J2EE approach. Jury's still out, but I'm putting my money on the simpler approach.

      • I tend to use 'slimmer' solutions than a full-blown framework like EJB (yes, I like 2- and 2.5-tier applications). ;-) But I would like to caution those who strike out at Java/EJB/J2EE as though it's just marketing speak. It ain't all a crock, and like anything that achieves some popularity it will attract idiots who will give others a bad impression.

        Just for the record, the author of Building Java Enterprise Applications isn't one of those idiots. I haven't read the book yet, but Brett McLaughlin is a smart guy, and I think it's unlikely he presents EJB's as a magic bullet. A few years ago he wrote in an article for O'Reilly's online Java thing: [oreilly.com]

        I'd estimate 50% to 70% of the companies that have purchased or are purchasing J2EE solutions could easily get by with a simple servlet and a JDBC-based solution. Presentation logic housed in the servlet coupled with database access through JDBC would suffice for most types of applications, including many e-commerce solutions.

        i.e., what you just said.

    • Re:Wha? (Score:2)

      by oops ( 41598 )
      Since when was 'J2EE' marketdroid speak? J2EE specifies a set of APIs that Java serverside people can all speak (or at least they're familiar with a subset of these). If I'm talking J2EE, then I know I'm talking about the servlet API, the JNDI API etc.

      Furthermore if you talking about J2EE 1.3 vs. J2EE 1.2, I then know about the capabilities of those sub-APIs, and the containers.

    • Re:Wha? (Score:1, Interesting)

      by Anonymous Coward

      Ummmm.... Middleware was around long before it became a hip marketing term, and it will be around for a long time yet. (regardless of whether idiots talk about it or not)

      b2b. Ok now that's a stupid buzzword. But it (imperfectly) describes an area of great need for companies (In short. companies need to do business with each other) Technology that addresses this need will be around a long time after all the stupid x2x labels go away.

      J2EE. Well, it has (indirect) roots that go back to TP monitors. (before your time) Time will tell how much staying power this particular technology has, but it is sure going strong today. (If it fades away, it will be because the next son-of-TP-monitor technology has come along, not because the needs it addresses have gone away)

      The whole "New Economy" disaster was a bunch of know-nothings who thought that they were inventing this stuff.
    • Do my a favor. Go do a search on your favorite job-market search engine for J2EE jobs.

      You'll find more than most any other language.

      Java != dot-com

      Companies (not dot-coms, but companies like insurance and non-web based) still make websites (internal and external). Java is the answer for enterprise size sites.
    • Yes, these are buzzwords, but frankly the J2EE framework is very useful even if it's a big buzzword. The funny thing is that most of the companies doing work with things like EJB's aren't little dot bombs, but rather large corporations. Banks, insurance companies, etc, are the things that need the huge transaction that make things like EJB useful.

  • i'm wondering ... (Score:3, Interesting)

    by dlasley ( 221447 ) on Tuesday October 01, 2002 @09:44AM (#4367075) Homepage
    what's the subtle message in the exclusion of iPlanet, WebSphere, JBoss, etc. with the summary line: "Application server setup - BEA Weblogic only"

    no doubt in my mind BEA makes a helluva product, but i'm surprised the king of the open source publications doesn't have an entire section devoted to Building Enterprise Java Applications with _______ (insert your favorite jakarta packages here)
    • The subtle message is this. BEA Web Logic is the number one J2EE environment.
      So they only bothered to document setup for that.

      Some time ago, when I was looking for J2EE books, I noticed that most of the vendor specific stuff
      in books was for Web Logic.

      I was looking for books on HP Bluestone at the time.
  • For the person who is learning, it's beneficial to see exactly which package a particular class belongs to. Obviously in this code example it didn't matter but if you were dealing with 4 different packages all added using a *, then one might be hard pressed to find a class.

    Considering it's a book on Java, being specific suits it's audience. The author isn't worried about code maintenance issues here.
    • For the person who is learning, it's beneficial to see exactly which package a particular class belongs to.

      I agree completely, but in a printed book paper costs money. An entire page of imports in a code sample doesn't help the reader at all and simply wastes trees.

      I'm def in the "start importer" camp. The only time you really need to explicitly import individual classes is to resolve a class name conflict (e.g. org.cpfeifer.ListItertor and java.util.ListIterator).

      In the past I have used individual imports if I was using an external library and wanted to make the dependancies explicit. But in 1.4 they through in the kitchen sink (60% more classes than 1.3), so it's not as big of deal as it used to be. And I'm lazy.
      • The only time you really need to explicitly import individual classes is to resolve a class name conflict (e.g. org.cpfeifer.ListItertor and java.util.ListIterator).
        Nope , you still don't need to import classes individually. but you must specify the full class name where u use one.e.g.
        import org.cpfeifer.*;
        import java.util.*;
        and then
        org.cpfrifer.ListInerator iter1 = new org.cpfeifer.ListIterator();
        java.util.ListIterator iter2 = new java.util.ListIterator();
        Or it you are using a returned value, just typecast it to the fully qualified class name
      • The fact that 1.4 is 60% bigger than 1.3 is a reason *to* use individual imports, not a reason not to. That's what, 1000 new classes to keep track of? How do I know that the Document in your file is an XML document + not a swing text one? It's a lot easier to grep for "Document" and have it pop up in the import statement then have to play guessing games about which classes are in which packages. (Yes, I know that you'd have to be explicit if you have 2 classes with the same name in different packages. That's not my point).

        Individual imports are a real pain in the butt to code. They're a huge help for the next guy, though. Maintenance programmers usually don't know the modules they're working on well. This means they're not sure whether your JPanel is really a javax.swing.JPanel, or the custom com.foo.JPanel that's buried in an inner class 3000 lines into your file. They're often not familiar with APIs, either (senior guys usually write new code, they don't maintain it).

        I agree that for a book maybe individual imports aren't the best idea, but in the Real World they're incredibly useful. Remember, it's not for you - it's for the other guy.

    • It's also specified by the Jakarta coding standards [apache.org].

  • Book Code != Professional Code (Score:5, Insightful)

    by ChimChim ( 54048 ) on Tuesday October 01, 2002 @09:56AM (#4367142) Homepage
    When I was growing up, and wanted to learn how to program, I did it mainly through books I could buy each month at the local bookstore. So it took me awhile to figure out why real code didn't look like it did in books. Here's my answer to soem fo the author's complaints:

    Another area where I feel there is room for improvement in the presented style is in the use of hard-coded Strings for lookups - for example, in the AccountManager object there are several lookups of the AccountHome, e.g.: AccountHome accountHome = (AccountHome)context.lookup( "java:conp/env/ejb/AccountHome"; // Whoops, finding this can be tough!
    Yeah, but reading it is easier, especially if you're skimming through or haven't read a particular chapter where they introduce all their constants. Obviously, good practice differs.

    One last thing: I know it's minor, but why the insistence on importing explicitly?
    So that readers can see the exact dependencies of the class you're writing. In fact, I often write imports explicitly in production code as a form of documentation, but usually not for packages like java.io or packages where nearly every class is needed.

    I didn't find that the authors practice on handling nulls and errors fitted with my own
    Handling nulls is crucial, but it also clutters the example and makes it longer (somewhat). I would look at it (if they'd included it) and known they were being defensive, but I could see another reader possibly mistaking it for a special case? But i assume page length was [probably the main reason.

    Books can strive to give you as much code as possible, but really, you shouldn't use it (and many books have such disclaimers). You're not buying code, you're buying the ideas behind it, so code should be explanatory and descriptive rather than production ready. Some books come with utility libraries or include code from popular, well-used libraries, but even then never cut and paste book code into a production project!
    • One last thing: I know it's minor, but why the insistence on importing explicitly?
      So that readers can see the exact dependencies of the class you're writing. In fact, I often write imports explicitly in production code as a form of documentation, but usually not for packages like java.io or packages where nearly every class is needed.

      At a place where we used to work, the development team argued a lot over explicit/implicit includes. The C/C++ folks loved implicit includes. The Ada people hated them. The Ada folks won.

      As much of a pain as it was at first, I became a convert. You may have more "Class not found" errors up front, but it makes it much easier to track down missing .jar files when you go to install, since the runtime knows the full name of the class you're trying to find.

      I also don't worry any more about name collisions. I work for a usability testing company, so of course one of our crucial classes is named "Test". We use JUnit to unit test all over the place, and that has a "Test" class as well. These sorts of things can't be avoided without everyone ignoring Java's convenient naming heirarchy and redundantly calling everything "com.mycompany.foo.MyCompanyFoo". Of course, it's a pain when you spell things out explicitly from java.util, but on production code it's always better to have a little up-front pain than to set yourself up for surprises down the road when you really don't have the time to deal with them. (I should note that Emacs' m-x sort-lines makes it easy to wrangle the list, and vim has a similar feature.)

      My only exception to this rule is in JSP pages, where you don't have the package-level include, so I choose one package to include implicitly. Any more than one and there's a potential for name conflicts.

      • You may have more "Class not found" errors up front, but it makes it much easier to track down missing .jar files when you go to install, since the runtime knows the full name of the class you're trying to find.

        Uh, imports don't exist at the runtime level (unless, I suppose, you're using some special runtime tool that scans all the source files for import statements). All class references are made fully-qualified in the generated .class files.

        Any more than one and there's a potential for name conflicts.

        Exactly - this is the real reason why imports should usually be explicit.

    • Wow, I had just made a list of comments to address the reviewer's weaker points and then I read ChimChim's post. Right on! You said everything I wanted to. As an experienced technology educator, it is very difficult to write code that highlights the core notions of an API without adding clutter even it migth be useful in a production environment. According to this review it sounds like the author did a great good of this and I will certainly check out the book.
    • Of the 5 jobs I've had in the past 6-7 years, the 4 most recent all required explicit imports except for core libraries, but most explicitly included everything anyway. I also advocate this practice whenever the issue comes up..without explicit includes, there's no way to tell which package a class came from without deeper inspection, and there's no way to tell (at a glance) what classes and packages a piece of code is dependent on.

      What's more, modern IDEs for Java (Eclipse) automate the process of expanding imports, according to a set of configurable rules. Ultimately, there's no excuse NOT to explicitly import.
  • I've read the book and eagerly await volumes 2 and 3. It is one of few comprehensive approaches at building serious software. If you learn by example, this is a good book for you.

  • Trashed on Amazon (Score:3, Funny)

    by tkrotchko ( 124118 ) on Tuesday October 01, 2002 @10:12AM (#4367244) Homepage
    I usually pay attention to their reviews, particularly when you can get at least 3 people responding.

    http://www.amazon.com/exec/obidos/tg/detail/-/05 96 001231/qid=1033485007/sr=1-1/ref=sr_1_1/103-198980 7-1175041?v=glance

    Not a great review; the primary complain is too many mistakes and typos.
  • "Building Java Enterprise Applications"

    Enterprise uses Java for it's computer systems? No wonder it can't go faster than warp 5...

    On the other hand, it does make their system portable to other races' ships.

    AM
  • The code quoted in the review:

    AccountHome accountHome = (AccountHome)context.lookup("java:comp/env/ejb/Acc ountHome");

    will also break when using a non-RMI messaging layer (like CORBA). I've done the same myself in projects but to be fully compatible, you need:

    AccountHome accountHome = (AccountHome)
    PortableRemoteObject.narrow(context.lookup("java:/ comp/env/ejb/AccountHome"),
    AccountHome.class)

    Also, it seems to be common practice now to put these lookup/casts in static methods of a utility class, (XDoclet will write the class for you) both to keep them in one place and to keep the code clean.
  • Is this book, or will this book, be available through the Safari subscription programme? I'm considering subscribing and this book would certainly be a candidate subscription for me. Anyone from O'Reilly care to answer?
    • It looked like a great book and I had some free slots left, so I just added it to my bookshelf - very good so far.

      This sort of book is exactly why I subscribed to Safari. It's very handy but I'm not sure I want a physical copy, I can read through the whole thing to decide that.

      One warning though, I think the book was three points!! Safari subscriptions work by using a fixed set of points to put books on your "bookshelf", which then must sit there for about a month before you can replace it with another book. Very fair and ten points are $14.95 a month, most books are only one point.

      BTW, you should be able to see for yourself what books are on Safari [oreilly.com], it lets you browse and see excerpts I beieve. It's only when you try to read a book that you need the subscription.

      A side note, I'm also evaluating the online book site "books24x7" for work and I like Safari quite a bit more,both in terms of site usability and quality of books.
  • does anybody know of a j2ee / jdbc book that has in-depth coverage of distributed transactions? i have a j2ee book that tells you how to do it, but i want hard core examples and more than several pages on the subject.

    thanks.

    andrew

  • Brett McLaughlin is the author of another O'Reilly title, Java & XML ...

    I have to say this is not a good exultation for this book.

    Brett McLaughlin Java & XML* book is the weakest book in the O'Reilly stable by a considerable margin. It has a very babbled writing style and lacks clarity, it is poorly structured/organised and very disjointed, being neither reference or tutorial. I suspect that he learnt XML as he wrote the book. The Index is useless, the topics show little natural progression and many XML related topics lack proper explaination.

    he can communicate well.

    I have to strongly differ.
    • I have to agree with you . I still have _that_ Book , it's a waste .

  • I know Brett (Score:2, Informative)

    by MarkWatson ( 189759 )
    Brett and his partner hired me to add SOAP and UDDI support to a commercial app server. He is extremely knowledgeable, and was great to work with.

    I have not read the book in question, but I did find another poster's comment amusing about basing the book on Weblogic instead of open source - grin .

    Almost all of my Java consulting involves small or medium scale deployments, so open source solutions like Tomcat/JSP or Tomcat/JBoss/JSP (if transactions required) is all I really need.

    re: posts on why use Java at all:

    There is also great support for doing web services in Smalltalk, Python, etc. (i.e., support for light weight HTTP service, SOAP, etc.). That said, Java with great tools (like Tomcat, JSP, etc.) is a great platform. Really, language is not so critical, but good design is.

    -Mark

  • import statements (Score:2, Informative)

    by dobratzp ( 155212 )

    Explicit import statements are generally preferred for a number of reasons. Consider the following:

    import java.io.*;
    import java.util.*;
    import java.sql.*;
    import javas.jms.*;

    If you see a reference in the code to Session, you will either

    1. know exactly that they are referring to javax.jms.Session and either know its API or be able to look it up in the docs. In this case, you don't care about the import statements.
    2. or have never heard of Session, and decide to look up its documentation. If you see at the top of the file import javax.jms.Session, then you know exactly where to look. If you just have a bunch of wildcard import statements, you have to check through potentially all the packages for java.util.Session, java.sql.Session, etc.

    Also, when someone reads your code, they can browse the imports to check for specific classes you use that they are unfamiliar with. No one is going to read the entire documentation for all the packages you may have used if they only need to understand a few classes.

    The gripes about typing are somewhat unfounded. Any reasonable java-aware editor will be able to automatically manage you import statements.

    Remember: "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler)

  • Fundamental flaw of most J2EE apps (Score:4, Informative)

    by smagoun ( 546733 ) on Tuesday October 01, 2002 @12:35PM (#4368178) Homepage
    Most J2EE apps are terribly flawed from a maintenance and flexibility standpoint.

    Why? There's a fundamental issue at stake that Sun has partially solved, but not completely: What your application does should have nothing to do with how it does it.

    For example, take the "bank account" app that I've seen used as a tutorial in many places. Customers can have one or more accounts, and they can perform operations on those accounts (deposit, withdraw, transfer). The code necessary for those operations is trivial. It's the support code that makes writing enterprise apps so difficult. At the minimum, you need:

    • A database schema
    • Code to read/write the DB in a transaction-safe manner
    • Presentation code (webapp, could be something else)

    You'll probably want to expose a few other interfaces, like an API for your app to be used on a message bus so other apps can access it.

    It sucks to have to write all of that extra code. It gets even worse if you have to modify your app (add/delete fields, features, etc). Sun is slowly chipping away pieces of the problem (EJB sort-of makes persistence easy, unless you need stored procs, etc), but they haven't solved one of the big the underlying issues:

    The application has data that can exist in multiple representations. Each representation requires work to make sure it's always in sync with the rest of the representations.

    There's an easy way out - define your data, and let the computer generate the different representations for you. While you're at it, have the computer write the code that can convert data in one format to another format. This is obvious for things like going from one XML format to another, but not so obvious when trying to convert a web form into a java object, or a java object into a database record.

    By defining your data and using code generators or other automation techniques (reflection) to create those different representations, you can slash maintenance costs, time to add new features, etc. Want to add a new field to an object? Update the canonical representation of the object, and presto, your entire app supports it, from the web UI down to the DB schema. Want to add a new data format? Write a generator for it, and all of your objects automatically support that new format.

    The overhead is higher at first, but it pays off incredibly quickly. On my last project we saved many many man-years by doing this. Check out thesandboss [sf.net]project for an LGPL set of tools to help out with this, based on the SAND architecture [epinova.com].

    (Yes, I've glossed over about a zillion issues. It's not that I havent thought of them, it's that the problems are solvable. The main point is that your data representations should always be in sync with each other, without your lifting a finger. And no, UML doesn't quite get you there yet).

    • The application has data that can exist in multiple representations. Each representation requires work to make sure it's always in sync with the rest of the representations.

      I find this a flaw of many OOP methodologies in general. They end up mirroring the "noun model" in programming code. This not only ends up duplicating the relational schema, requiring synching up upon change, but bloats up the code to high heaven.

      Relational thinking and OOP are at odds on many things and the industry has not settled this. Heavy OO fans would prefer OODBMS's, but the market has pretty much pissed on them (beyond small niches). Thus, they try to force OO and relational together, and they make lousy bed buddies, fighting over terrority and design approaches. The approach that Sun appears to have taken is to *duplicate* the same or similar info in both the relational DB and the programming code, making the kinds of messes you talk about.

      I prefer to store UI field info in tables (AKA "data dictionary" or "field dictionary".) These tables then generate the UI's as needed. You simply fill in the needed cells instead of setting a boatload of code attributes (set/gets). A good table browser makes such a table far easier to view, navigate, and filter for your needs than programming code. Code is a horrible place to manage wods and wods of attributes IMO. Perhaps your head is different, but code just sucks eggs IMO for such for the way my head works.

      By defining your data and using code generators or other automation techniques

      IMO, code generators are evil. You are going from a compact representation of attributes to a less compact representation (code). IOW, bad information factoring. It is like entering and management spreadsheet data via XML instead of a grid.

      I cannot believe the market-place tolerates such shit. It must be job security or contractor security. I don't get it.

      Sample data dictionaries:

      http://geocities.com/tablizer/ddsamp.htm

      More about data-centric philosophies:

      http://geocities.com/tablizer/whypr.htm
      • Foxpro music seqwuencer? Xbase apreciation? God, no wonder you don't like Java...you don't like OOP.

        Well fine, don't use it. For those of use who have done both and believe OOP is superior we will read this book and use these hints to create great software...you may continue living in the 80's

      • I prefer to store UI field info in tables (AKA "data dictionary" or "field dictionary".) These tables then generate the UI's as needed.

        IMO, code generators are evil. You are going from a compact representation of attributes to a less compact representation (code). IOW, bad information factoring. It is like entering and management spreadsheet data via XML instead of a grid.

        Um. So is it good or bad to generate stuff? You can't have it both ways. Your compiler is a code generator, like it or not. You go from a compact representation of information (C, Java, whatever) to a less-compact version (asm/0s and 1s) that the computer can understand.

        Furthermore, the compact representation of the information that's provided as input to the generator is the goal! It sounds like we agree - compact good, big piles of code bad. The code generator lets you make one tidy little file - your data definition - that the generator then blows out into the various APIs that other components need. You still have the piles of code, but you don't have to think/worry about them, because they're always there and they always "just work.".

        Sure, it would be nice if we didn't need to generate any code and we could just operate on the data itself, but there are real-world considerations that make that difficult. RDBMSes talk SQL, browsers talk HTML, and there's a bunch of stuff in between. You still have to get from the UI to the DB, and you can either write that code yourself, or have the computer do it for you. By defining the data and then transforming the data definition (via code generation or other method), you can have your cake and eat it.

        (And yes, I hate getters/setters too, but they're only about 1% of the stuff you can actually generate)

        • Um. So is it good or bad to generate stuff? You can't have it both ways. Your compiler is a code generator, like it or not.

          I mostly mean what an application developer has to deal with. Besides, compilers don't generate programming code, but machine code. And, there are interpreters which don't generate anything (except hidden work files maybe).

          that the generator then blows out into the various APIs that other components need. You still have the piles of code, but you don't have to think/worry about them, because they're always there and they always "just work.".

          So the generated code is not meant for developer eyes but to communicate between components? I find it odd that computer components communicate via a human-intended language. It would be better to eliminate such a "middle man" and have the components read the original format to begin with.

          You still have to get from the UI to the DB, and you can either write that code yourself, or have the computer do it for you.

          Again, why does the inter-communication medium have to be repetitious-looking Java (program code)? The intermediate form should *not* be Java UNLESS it is meant for app programmer eyes.

          If your GUI layouts/attributes are stored in XML or a database, then the GUI engine should read those *directly*, rather than have them translated into Java first, since Java is meant for humans to read primarily and not computer parts.

          It seems like another effort from SUN to lock you into Java, or some motivation besides technical merit. The same GUI engine could then read stuff *independent* of language.
      • You make some good points - smagoun's methodology is a solution to a problem that doesn't have to exist, but in practice, it does exist in most companies and enterprise software being built today.


        Also, your solution isn't quite well fleshed out enough for me to buy into whole hog. A pure meta-data model (sorry, I know that's not precise terminology, but I think I am using it in the same way you are using the term data dictionary) is well suited to data that you only need to take from a form field, stick into a particular DB table and field, and retrieve and display later.


        If your application needs any particular logic to be based off of some fields, metadata models fail - you need semantic knowledge of field's meaning and associations in the application code.


        Unfortunately, many enterprise applications have a lot of data they just need to shuffle around and pass along to somebody else farther downstream, and a lot of data they actually need for application manipulation. In my experience, if you try to handle complex data types with a data dictionary-style mechanism, your dictionary ends up with so many damned parameters it becomes unmanageable. If the data is handled in code, you will just have more code for complex data, and less code for passthrough or simple data.


        Also, I should point out that in general, code generators keep data in MORE COMPACT form, not less compact - I believe that smagoun is referring to a build system that uses generated source code files as intermediates in the build process, not as verbose files that are to be edited manually. The advantage this provides is that you can get compiled code performance out of data manipulations that would otherwise require semi-interpreted performance if they actions are all determined at runtime (example - autogenerated externalization methods in Java vs. default object serialization - huge performance difference in performance critical apps).

        • If your application needs any particular logic to be based off of some fields, metadata models fail - you need semantic knowledge of field's meaning and associations in the application code.

          I would have to look at a specific case of alleged failure. For there are different approaches to "meta data" with various trade-offs.

          In my experience, if you try to handle complex data types with a data dictionary-style mechanism, your dictionary ends up with so many damned parameters it becomes unmanageable.

          How is a data dictionary with a jillion parameters more evil than a class or method with a jillion parameters/attributes? (Good) table browsers give you any view of the info you want. You want it verticle? No problem. Horizontal? No problem. Stretched out linearly like code? No problem. Query to only see/edit certain things? No problem. It is far more rubber-bandy than code.

          I will agree that tools for a table-centric approach are kind of spotty, but this is because the market is hellbent on the code-centric approach these days. Someday the pendulum will probably swing back the other way, but for now it is a bit frustrating for us table fans. I hope we don't get QWERTY'd into it forever.

          Also, I should point out that in general, code generators keep data in MORE COMPACT form, not less compact - I believe that smagoun is referring to a build system that uses generated source code files as intermediates in the build process, not as verbose files that are to be edited manually.

          IOW, the generated code is not used by humans. If so, then why use Java as the info transfer mechanism? (This question is raised in a nearby reply.)
          • IOW, the generated code is not used by humans. If so, then why use Java as the info transfer mechanism? (This question is raised in a nearby reply.)

            I'll answer the other reply here, too.

            The generated code IS used by humans. Perhaps more importantly, the generated code is used by other systems that speak a certain format, like SQL.

            For example, start with a simple chunk of data: a "user." It has a username and a password. Your data definition might look like this:

            user {
            String username
            String password
            }

            That's about as concise as I can get without losing human readability (which is a requirement for the data definition). Now, you probably want to manipulate that data at some point. Say you want to manipulate it in Java, because you're stuck with a shop full of Java engineers. You need a java class file:

            public class user {
            private String username;
            public getUsername() {return username;}
            public setUsername(String u) {username=u;}
            [...]
            }
            You also want to store that data in an RDBMS from Java. Assume you want to do it simplistically, no EJB or anything:
            public class UserPersister {
            public storeUser(User u) {
            connection c = getDBConnection();
            c.execute("insert into user username=" + u.getuserName() + ", password=" + u.getPassword());
            }
            }
            Of course, your object isn't much good unless you can display on a screen somewhere (say as part of a webapp). You need a servlet or a JSP or something (I don't care what) to display that object:
            <html>
            <body>
            username="${user.getUsername()}"<br>
            password="${user.getPassword()}"<br>
            </body>
            </html>
            Writing all of that stuff by hand sucks. So I make the computer do it for me, based on my data definition. I never have to touch the generated code (in fact, it's not allowed). That doesn't mean it's useless, though - the generated stuff still does things, and it gives other programmers familiar and always-up-to-date tools to work with.

            It sounds like your approach is to make tools that understand the data definition directly, which is a valid approach. They're just two different solutions to the same problem. I like code generators because they spit out stuff that other people can work with without any understanding of the data definition, or how to use/abuse it. As you said, the tools just aren't there for table-driven code right now. And what happens when you have to switch DBs/storage paradigms?

            • Say you want to manipulate it in Java, because you're stuck with a shop full of Java engineers.

              Not a requirement I like, but if its forced its forced.

              and it gives other programmers familiar and always-up-to-date tools to work with.

              Huh? Pick something because it is good, not because it is "up-to-date". (Except maybe for QWERTY-like support reasons.)

              I like code generators because they spit out stuff that other people can work with without any understanding of the data definition

              Huh? You are *echoing* the data definition in your code. Thus, if you look at the code, then you have to understand it. If you don't look at the code, then why rely on code generators?

              And what happens when you have to switch DBs/storage paradigms?

              It appears that languages change at least as often as databases for a given application over time. Is tying your design to a particular language or programming paradigm less evil than (allegedly) tying it to a given database?

              Besides, you can wrap only the simpler relational operations without lots of conversion fiddle-fadding. OOP cannot protect you from the complex stuff changing. IOW, if you use a lowest-common-denominator, then it is easy to wrap regardless of paradigm. It is tough to specify complex relational operations via "flat" API's alone due to the richness of the language (and some weaknesses of SQL itself).
      • I am responding because it is rare for me to see somebody endorse a position I hold dear. Although it is probably a bit off-topic since the general issue is a review of a EJB enterprise book, but it does seem crazy that certain OO solutions can be advocated with a straight face. There seems to be an almost instinctive negative reaction by most programmers to the idea that data might be retrieved by lookup keys instead of using an explicit attribute. This is in spite of the fact that mapping all data into explicit attributes creates all sorts of nightmarish headaches in many applications (persistent serialization to name just one complication).

        Few people are willing to question this OO dogma. Somehow they cannot believe that a data value will be given its full "semantic" meaning unless it is explicitly defined as an attribute in a particular object. If the compiler does not enforce the declaration of "type", they just don't think it is a proper data value. Although a compiler may prevent you from accidentally violating certain proper usages of that attribute, that small utility of preventing "typo" style errors is hardly worth the cost of the infrastructure that approach generates. When I examine field information using the JDBC api, I can discover all relevant type information without actually having an attribute declared to be that type. It seems silly to not use that information directly instead of having to load the information into an explicit attribute.

        In the world of RFCs and the Internet, almost all parameters in a protocol are specified using some type of name-value approach (HTTP headers is the classic example). No implementation of these RFCs (such as web servers for HTTP) explicitly binds all of these parameters in their code. There is a soup of data out there, you grab the data items you need into temporary attributes (using human written code), but let the rest slide along with your main data objects as you process a request. It is a winning formula that creates tight and flexible code. It is the type of code that drives Apache, PHP, perl, and all the stuff that is actually out there in real usage instead of a the demo ware data entry apps created for fortune 500 companies.

    • That's just a fundimental flaw of most apps (Score:1, Interesting)

      by Anonymous Coward
      J2EE framework is designed for the three tiers you mention:

      - jsp pages contain presentation in HTML with a bare minimum of actual java, it references:
      - JavaBeans, that contain all the "business" logic, this in turn references :
      - RDBMS that contains all the raw data.

      People just don't use them right. And I agree with you that that's a minimum. The Actual java code should probably be broken up into some higher level and lower level tiers.

  • Ok, something i've never quite understood. What is the benefit of Java on the server? It sort of made sense on the client even though most
    companies have standard client configurations. I fail to see any advantage on the server. It seems to me that when installing / designing a back
    end to a n-tier system the ability to be cross platform doesn't buy you much. The servers are specified to match the application. Java's
    'standard' API's for database manipulation seem to come at the cost of performance. Yes, i've heard all the arguments about java
    performance, but lets face it highly performance critical systems simply cannot be tuned as easily when you have a JVM between you and the
    hardware and a set of generic libraries between you and the database, communications etc interface. So, lets assume that the applications don't
    really need the performance. It then comes down to the question of whether or not Java and friends provide sufficiently high level abstractions
    to ease development costs. Again, I simply don't find the java tool kits sufficiently better than assorted 3rd party system, even ones not
    designed for building middle tier systems. Take Delphi for instance, the built in database manipulation components and its ability to handle
    distributed systems, aren't really its strong point (building front ends) but its secondary support in the enterprise versions seems better than
    J2EE. Then there are M$ offerings like C#.net. Admittedly a dirty word on /., and ignoring the M$ hype about how much faster it is, it does a
    damn good job at enterprise backends.



    In the end it seems to me that (especially here on /.) J2EE's strongest benefit is that you can build a system without involving M$. The
    negative is that it seems to cost more, particularly for development.

    • Ease-of-management also comes into it. Migrating servers is a lot easier when you don't have to worry about recompilation; just copy over some .class files. That's the advantage of the virtual machine: no worries about weird big-endian/little-endian bugs, 32 bit vs. 64 bit, etc. Couple that with the fact that Java is the most mature JVM environment with great tools and APIs, and you can see why it's widely used.

      I won't deny .Net will become a contender. But Java also benefits from competition in the app server space. Bea vs. IBM vs. iPlanet and so forth means higher performance and more features. Where is the competition for .Net's app server environment? In the MS Transaction Server/COM+ days, it was all just MS - no choices. Will the same be true for .Net? I think so, and that scares a lot of people.

      Finally, Java runs well on *nix, and *nix is THE choice for big, serious sites. Sun makes Solaris, and Sun makes Java; that's all that needs to be said about that.
      • (* Ease-of-management also comes into it. Migrating servers is a lot easier when you don't have to worry about recompilation; just copy over some .class files. That's the advantage of the virtual machine: no worries about weird big-endian/little-endian bugs, 32 bit vs. 64 bit, etc *)

        Bosh! Many interpreters don't have such problems. If the numeric implementation is hardware-specific, by chance, it is usually for *speed* purposes. The more native, the faster. IOW, there is a tradeoff. Swappability and speed are often at odds.

        That's one reason why Java GUI's sucked so bad: they tried to emulate too much from scratch, and found it that it was too much work to get right (and slow).

        (* Couple that with the fact that Java is the most mature JVM environment with great tools and APIs, and you can see why it's widely used. *)

        Debatable. I will agree that support is strong because the hype has brought in a lot of vendors. But this is just a self-fullfilling prophecy via the "network concept" of vendors and users rather than raw merit. AKA, the QWERTY-syndrom.

        IMO, Java is hypeware and bloatware and PHB-friendly mediocrity at work.
        • Hey but head...check your calendar...it's 2002. Some of the tripe you dish out may have been true in 1997 or 1998 but not today in the era of 1.3.1 and 1.4.1 jdk's. (Swing is quite peppy now and SWT from IBM is downright fast)

          Java does well on the server simply because it is the best tool for that job. End of story. It is also much easier to maintain and upgrade than garbled PERL or old C hacks. It also provides a choice that other middleware (from MS mostly) do not offer.

          Next time you decide to slag a technology, try programming in it first..

          • Java does well on the server simply because it is the best tool for that job. End of story. It is also much easier to maintain and upgrade than garbled PERL or old C hacks.

            Some choice we have here: Java OR C OR Perl. Whatta diverse world. That it?

            You know, personally I also think that Perl sucks. But Perl programmers seem to do wonderful things with it and can often even read and maintain other perler's code.

            As long as they are productive, I have no place to bash Perl just because it ain't my bag. (Oh, I'll still complain though :-)

            I think programming and paradigms is probably subjective. If you want productivity, then give people tools that best fit their head. Surveys by Ed Yourden tend to confirm this (although it is highly preliminary).

            If you can show that Java and/or OOP are *objectively* better, then I would just loooove to see the actual evidence. Until then, please don't dictate to me what works best for me. Give me tools that fit my head well, and I can crank sh_t out faster than a vast majority of Java fans (and have it be more maintainable and simpler).

            Probably the same with Perl fans. Paul Graham beat a lot of projects using LISP, a language created in the 1950's, and is now wealthy because of it, if you want an actual example of tool-fit-based productivity.
        • "Bosh! Many interpreters don't have such problems."

          I wasn't speaking only about Java. In general, interpreted code is nice to have on servers.

          "IMO, Java is hypeware and bloatware and PHB-friendly mediocrity at work."

          It's pretty enduring for hypeware, don't you think? Anyway, aren't you the guy with the huge problem with object-oriented anything? Maybe a bit of bias showing through here?
          • It's pretty enduring for hypeware, don't you think?

            COBOL was enduring. Does that make it "good"? One of the worse languages from a software-engineering standpoint, yet it is common even today. (IMO, it has been given a second life by shifting much of the complexity to relational databases instead of code-centric noun management.)

            Anyway, aren't you the guy with the huge problem with object-oriented anything? Maybe a bit of bias showing through here?

            I would rather see something like Python be more common. It better allows multiple paradigms and can use libraries written in other languages. It is not perfect IMO, but if you are gonna hype something *with* OO capabilities, then why not Python? It has soooo much more potential than Java.

            Java is warmed-over OO-Fortran IMO.
            • Cobol wasn't hypeware, either, so I don't get your point here. Cobol did its job well for many years, and now it's legacy code, mainly. It followed a natural lifecycle. Java will too. In the here and now, Java does a good job.

              Python is nice. But Java is way more than just the language. Its got containment and infrastructure in the form of app servers, a vast number of APIs, a huge community, and a ton of third party support. From a pure language perspective, maybe Python is better, who knows. But really, it's design and infrastructure that count; languages are very often not as important.

              By the way, what "multiple paradigms" (this from the guy that hates buzzwords and PHB speak) does Python support?
              • Cobol wasn't hypeware, either

                In its heyday it made many of the same promises that Java did: cross-platform, write-once, easier to read/program, etc. Either it succeeded, and Java is not original, or it failed, and that talk was just hype.

                Its got containment and infrastructure in the form of app servers, a vast number of APIs, a huge community, and a ton of third party support.

                Containment? Like nuclear waste? I don't follow.

                This is the "QWERTY" argument more or less. "It is good because everybody supports it because everybody uses it".

                But really, it's design and infrastructure that count; languages are very often not as important.

                Could you please clarify what you mean by these?

                By the way, what "multiple paradigms"...does Python support?

                For example, you can call a regular function without a dot-path behind it.
                • Sure, Cobol succeeded in its claim. Java is succeeding, too. They are both successful workhorse languages that get the job done. The "hype" you claim is so vile - write once, run anywhere, and so forth - may have been made before. But it's still nice to have; these are virtues. Java (the platform) does not deserve your scorn, as it is an excellent server-side solution.

                  Regarding containment: have you ever worked with J2EE? Object containment, like EJB servers. Or in MS world, MTS/COM+.

                  My comment about the lesser importance of specific languages is simply this: design is what counts. Bad design = bad implementation; no language can save you. Many people like to work with objects; J2EE is an object-oriented, heavy duty framework. Its attendant language is Java.

                  So by "multiple paradigms" (argh) you mean Python allows you to break object orientation. That's not an advantage for me, but maybe for you it is. I wouldn't want to be the one who documents that sort of code.
                  • Regarding containment: have you ever worked with J2EE? Object containment, like EJB servers. Or in MS world, MTS/COM+.

                    Nope, I found no need for them. I tend to use databases and/or HTTP get/post in place of those. Why use complex gimmicks when common-but-powerful tools already exist right under your nose.

                    it is an excellent server-side solution.

                    I just don't see what is so special about it.

                    Many people like to work with objects

                    Fine. Just don't cram it down the throats of those who don't want it and don't need it to get the job done. It is hyped beyond its merit.

                    you mean Python allows you to break object orientation. That's not an advantage for me

                    Heaven forbid somebody violate the great doctrine of the ChOOrch. Even a sizable portion of OO fans I debate with believe in "best paradigm for the job" rather than "OO at all costs".

                    oop.ismad.com
      • Ease-of-management also comes into it. Migrating servers is a lot easier when you don't have to worry about recompilation; just copy over some .class files. That's the advantage of the virtual machine: no worries about weird big-endian/little-endian bugs, 32 bit vs. 64 bit, etc

        This sounds nice but, does it really work that way? How often will a large company migrate their servers running a custom application from
        one platform to another without bringing in someone to test and verify the system? Is the savings every few years worth the extra development
        cost? In the past, by the time the system needed 'migration' rather than upgrading, it was time for a completely new application. Companies
        migrated from the mainframes and minicomputers of the early 80's not because the couldn't handle the business anymore, but because it cost to
        much to maintain the old hardware or the old business paradigm the software was written for was outdated. In some cases they updated
        because it was cheaper to train someone to use a GUI application than the old TTY one. In 10 years will it really matter if you can migrate
        your business backend? Will you want to?



        Finally, Java runs well on *nix, and *nix is THE choice for big, serious sites. Sun makes Solaris, and Sun makes Java; that's all that needs to be said about that.

        This sounds like my last statment, the real reason for using J2EE is to avoid M$. The middle tiers apparently arn't particulary performace intensive. Combined with the fact that companies like IBM make enterprise level PC servers means there really isn't a hardware reason. (There are dozens of companies making hot swap/failover M$ solutions too.) After the sun fiasco with the processor cache bugs causing random data corruption, and the coverup, I lost all my trust in them. To a certain extent the other Unix vendors as well. For all the talk about how closed the PC is, it seems far more open than the Unix vendors. Christ, I can't even access the HP user to user support boards without proving I have a machine under warantee or a support contract. I am now applying a basdardized Open Source theorem to my hardware. 'Millions of users make the bugs shallow and hard to cover up.'



    • >What is the benefit of Java on the server?

      Well, we ship our Java servers on Windows, but our customers are asking about Linux. When they get serious, it will only cost them a little extra to have it. We have to cover costs for extra testing and packaging, but the code already works.

      Even for Windows though, Java is a dang solid language. If something breaks, it spits out a stack trace and we can fix the problem pretty quick. Or we can force a stack dump on all threads. It's absolutely brilliant for debugging.

      As for performance, we used to think that was going to be a problem, but then we tuned our Oracle instances and fixed our SQL statements and stopped doing stupid things, and now our server processes take about 5% CPU under standard load. Extra load is caused by external things like virus checkers locking database files while they scan them, Java is the least of our worries.

      My major gripe against Java is the startup time for the VMs: scripting is not really an option, because programs don't ever start really quickly. For that I prefer Python.

      Of course, my comments apply only to Java, I can't vouch for J2EE.
    • There really aren't many good arguements for Java on the server-side. Of them, the best seems to be abstraction. The JDBC drivers are required to support ANSI SQL (different versions for different levels of drivers). Also consider that at some point soon, a lot of people are going to have to port their projects to take advantage of the new 64 bit processors and for the Itanium. To you it may be as simple as "a simple recompile" but we both know it's not that easy when you are using third party libraries and components. Half the world can be brought to a halt because one component vendor isn't on the ball in the Delphi/C world.

      The real strong arguements for Java on the server side though come from the wealth of code and architecture available for free. J2EE is a great technology. C# doesn't support clustering, distributed transactions, nor the object persistence that J2EE supports. Do you fully understand how much effort it would take for you to write a security system and distributed transactions for your entire enterprise? How about optimization of this system? J2EE halves the time to market if you need these features. J2EE is often much faster than raw database access because it optimizes your accesses by cacheing as much data as it can. How long would it take you to write a clustering solution for your application? In an enterprise situation, if you can't scale, then you're not going to fly. Ebay doesn't run on one computer, and it doesn't make mistakes when two people bid almost simultaneously. Writing C code for distributed transactions, security, and clustering would take longer than writting the code to make EBay work on one system. J2EE may increase the amount of time it takes to make EBay work on one system, but if it works on one, with J2EE it will be fine on as many as you want.
      • Also consider that at some point soon, a lot of people are going to have to port their projects to take advantage of the new 64 bit processors and for the Itanium. To you it may be as simple as "a simple recompile" but we both know it's not that easy when you are using third party libraries and components. Half the world can be brought to a halt because one component vendor isn't on the ball in the Delphi/C world.

        As many other people have pointed out only a very narrow subset of applications will accually see a benifit from moving to 64-bit. Database are one of them, but we arn't talking about databases we are talking about the backend logic driving them. I suspect that there arn't many systems running today that will see a huge benifit from moving to 64-bit that arn't already running on a Sun/AIX/HPUX/etc box.

        Secondly, I don't see how Java solves the problem of 3rd party vendors not being on the ball. If your database vendor thinks that the 'C' libraries are more important than the java drivers it makes the problem even worse. It seems the PHB factor is what drives this.



        C# doesn't support clustering, distributed transactions, nor the object persistence that J2EE supports. Do you fully understand how much effort it would take for you to write a security system and distributed transactions for your entire enterprise? How about optimization of this system?

        Correct C# (c/C++/most other languages) doesn't support these features. Its supported by the enviroment, in the case of C# by .NET. Personally I find old M$ technologies like DCOM/COM+/MS Transact to be more advanced than the J2EE support. Most of this stuff has been around forever (ever use an AS400?), in many cases its easier to use than the Java version. In others its a pain in the rear. Which is sort of my original point, that Java doesn't appear to be the best framework when compared with assorted other techologies. When compared to straight C it will win, this is primarly a function of the C minset forcing everything to be explicit. Besides a lot of this isn't a particularly big deal because the database backend will guarantee a certain level of tranactional consistancy. Ebay isn't as tight as you think either, this is a function of the fact that in the end all that matters is who is the highest bidder or in the event of a tie who placed the bid first. Just as long as consitancy is maintained all kinds of 'bad' things can happen. I've accually seen "you have won this item" screens from ebay on things I placed a bid on seconds before it closed, only to have it not be true because some other sniper managed to get a bid in after mine but before the auction closed.

        • Some database engines and database connectivity software is written in java. Also mathmatical software will benifit from the extra precision. Then again, the new 64bit systems arent't really just bringing an extra 32 bits to the table. They are bringing twice or greater number of registers. The benifits of this architecture will be experienced instantaneously by those that use them.

          An old Java library will still work in new java implementations. You don't have to wait for the JDBC drivers to be updated for itanium, PPC, etc. support. In C/C++/Delphi (not C# or .Net with the CLR), you just can't do that.

          *COM* is a cludge that requires more code to do the same task. If COM was worth a it's bits, .Net wouldn't exist. .Net doesn't have a persistance engine that doesn't require you to save the data through the same proprietary SQL statements. When you buy into .Net, you've made your mind on exactly what kind of system your software will run on. When MS increases the tax, you'll have to eat the losses, or redevelop on a different platform.

          As for ebays faults, it just goes to show you how much debugging you can save by using J2EE as well. You don't have to worry about any of those problems with J2EE.

          I don't think you'll be finding a system that does as much as J2EE that is easier to use.
  • One last thing: I know it's minor, but why the insistence on importing explicitly? I feel it makes maintenance more difficult -- change one LinkedList to an ArrayList and you're off fiddly with minor imports again.
    That's due to bad practice. I almost never import LinkedList or ArrayList, I'll do this instead:
    import java.util.List;
    ...
    List alist = java.util.LinkedList;
    ...
    Now changing LinkedList to ArrayList is simple and involves no import changes. Always work with the interface where one is available to you -- you should rarely pass around the actual class if an interface is available.
    • Exactly right. But you meant:
      List alist = new java.util.LinkedList();
      It's also a little silly that the language provides no way to specify a single concrete type for the referants of a bunch of different supertype references. For example you might have to write something like this:
      List list1 = new java.util.LinkedList();
      List list2 = new java.util.LinkedList();
      List list3 = new java.util.LinkedList();
      You would have to edit the source in three places to make the change to ArrayList. A macro processor would solve the problem. A Pure Java (TM) approach:
      List list1 = new java.util.LinkedList();
      List list2 = list1.clone();
      List list3 = list1.clone();
  • Book Review of Building Java Enterprise Applications Vol. 1 Architecture [compunotes.com]

    "Before you dive into the coding, read this book to summarize and organize your overall design and implementation. It will be well worth your time. I'm looking forward to seeing the rest of the volumes in this series."
  • One last thing: I know it's minor, but why the insistence on importing explicitly?

    Because programmers using wild card imports should be taken out the back and shot in the head. I don't want to spend 10 minutes searching for class Foo that is in one of the 20 packages you happened to import with an 'import x.y.z.*'.

    However, I agree it doesn't make that much sense in book source code examples.

  • I bought the book some time ago, and I really like it. I am a Java trainer (Sun) and read a lot of similiar books, but this is one is really "small and beautiful", easy to read, lots of good code. I am waiting for part II.

Slashdot Top Deals

"I am, therefore I am." -- Akira

Close