Rapid J2EE Development 146
| Rapid J2EE Development: An Adaptive Foundation for Enterprise Applications | |
| author | Alan Monnox |
| pages | 395 |
| publisher | Prentice Hall PTR |
| rating | 8 |
| reviewer | Pankaj Kumar |
| ISBN | 0131472208 |
| summary | A telescopic view of tools, techniques and processes for boosting Java software development productivity |
"Using a Hole-Hawg for the job of a homeowners drill can have deleterious effect on productivity by causing serious harm to the health of the inexperienced operator." Just identifying a tool for a task is not enough. You should also be able to match the demands of the task to the characteristics of the tool and your ability to handle the tool. The good news is that this book passes even this stringent test, suggesting very practical and hands-on approach for choosing the tool with right characteristics for the specific demands of the task.
The ever-growing body of literature on development best practices, the burgeoning ranks of supporting tools and the accompanying debates on their relative merits can easily overwhelm most practitioners. Worst, a large chunk of the developer community may never spend the time and effort and miss the opportunity to take advantage of them altogether. Rapid J2EE Development offers an easy path to such Java developers by bringing together a number development techniques, best practices and description of supporting open source tools in a single book.
Whether you are a confused Java developer, overwhelmed project leader or plain lost manager, this book has something for you. Wondering about how to design complicated class hierarchies to encapsulate the ever-changing business rules? Worry not, follow the advice of Chapter 10, "Working to Rule" and use Jess, an open-source Expert System Shell. Don't have the time or motivation to download and play with it? No problem. The coverage includes not only an overview and discussion on when and where to use it but also presents a sample session and illustrative code snippets.
If you're confused with all the hype around AOP (Aspect Oriented Programming) and uncertain about where to start, start with the chapter "Aspect Oriented Programming," which introduces the notion of crosscutting concerns in any large software project, presents the AOP terminology to nail down these concerns and associated actions, and covers AspectJ and AspectWerkz to apply AOP to your projects. The brief description of these tools may not answer each and every question, but the example- and code-driven approach will certainly make you feel a lot more comfortable and motivate to explore further.
Not able to decide whether to use XP (Extreme Programming) or RUP (Rational Unified Process) for your next project involving four different development teams in three different continents interacting with as many customer groups? The Chapter "Embracing Adaptive Methods" outlines an approach to making such methodology decisions, though it is not very obvious from the chapter title. (Of course, you will have to read the sections that talk about when XP works best and when the rigors of RUP start paying off to make your decision.) And although there is not much discussion around mixing elements of development methodologies or adapting them in the middle of an ongoing project, the author's account of a real case study does exactly this.
These are just a few examples. Other topics covered include use of UML for modeling, code generators, Model-Driven Architectures, Java-based scripting languages, Object Relational mapping, build and test automation, and use of the right IDE plug-ins for J2EE projects. Among the development tools, all the usual suspects are there: Apache Ant, Eclipse, Jython, JUnit, HttpUnit, JMeter. In fact, I also found description of tools that were somewhat new to me: MyEclipse, AndroMDA, Middlegen and few others.
I found the book to be highly readable, insightful and loaded with the right kind of details. For example, the information on debugging with Eclipse explains how to configure a J2EE program for remote debugging, and how to debug a Web application using JSPs, something that is quite hard to do without the right tools and the right methods. Even the UML primer, with its well-chosen examples, is a good refresher.
It is easy to get superficial when covering a lot of ground: a common pitfall for authors of books on new technologies is that they themselves get caught up in the hype and lose perspective, but Alan somehow manages to keep the extraneous stuff out and deliver what a hands-on professional looks for. He tempers his zeal with practical realities and conveys the same to the reader with anecdotes and discussions with colorful stories such as the Cargo Cult Software trap and Christmas Puppy Syndrome.
The book manages to introduce a number of the very best open source Java tools available to boost productivity in a very natural manner and with the appropriate context, and it succeeds in giving a "feel" for the tool by presenting hands-on sessions. Most other such efforts that I am aware of usually end up being a drab list of tools with descriptions taken from home pages.
Given the number of topics and tools covered, it would be unrealistic to expect in-depth coverage of everything. What this book does is to create the right context, introduce the appropriate topics, and generate sufficient motivation to explore further. Fair enough. In fact, I believe this is the best approach for any book in this "Google era" -- the book should tell what you should look for and let Google do the rest.
So, is there anything not to be liked about the book? Well, I was a little disappointed to not find my favorite BeanShell among various Java scripting alternatives. Another thing I noticed is that the coverage of system manageability issues, especially in a book with J2EE in its title, was quite conspicuous by its absence. Also, some of the points, especially those around use of best practices and development techniques, could be made more emphatically with help of focused and concrete anecdotes.
Of course, no book can cover everything, especially on topics that are open-ended by nature. Overall, I think it does justice to the subject matter and is worth reading by anyone even remotely connected to the business of creating, maintaining or operating Java/J2EE software.
You can purchase Rapid J2EE Development from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I'm confused (Score:3, Interesting)
Rapid is a a bit of a misnomer innit (Score:3, Interesting)
Re:I'm confused (Score:3, Interesting)
ColdFusion? (Score:5, Interesting)
Using CF, you can develop quick & dirty web apps & webservices, talk directly to Java objects, and (starting in CF7) make your own EAR package and deploy it under any J2EE compliant server.
CF can run under most J2EE servers and as such supports advanced clustering, load balancing and the like.
Again, i know CF isn't for everyone, but I've found a real use for it at our shop. It's possible to deploy quickly, perform quick maintenance, etc.
NO, I do not work for Macromedia nor am I a fanboy. I'm just touting.
Gentlemen, start your flame engines.
Re:Rapid J2EE development? Oxymoron? (Score:2, Interesting)
For example, a lot of n00bs think that any enterprise app should be using EJBs. The fekn reality is, most enterprise apps are 2-tier screaming out for POJOs and O_R Mapping tools.
So - it goes back to the quote - right tool for the right job.
Re:The most important J2EE Bean of all (Score:3, Interesting)
Re:ColdFusion? (Score:2, Interesting)
try.
please.
To hell with J2EE (Score:5, Interesting)
Let's look at persistence:
Once upon a time there was EJB 1.0 and 1.1, and every change required touching about a dozen files. Along came EJBDoclet (later XDoclet). EJBDoclet helped the world deal with EJBs, reducing the number of files you had to touch to 1. As such, the tool was invaluable. It also teaches a lesson: anytime you come up with an API that requires a new tool to make using that API bearable, your API sucks.
Sun saw that EJB 1.1 sucked rocks. Along comes EJB 2.0, in which they don't fix the configuration nightmare and introduce a half-assed query language to supplement the collosal folly that was the ejb finder method. With 2.0, EJBs were still fucking slow, CMP still didn't work right, and peopl had had enough. It didn't help that EJB 2.0 was about 2 years late.
New persistence tools started to gain traction, such as JDO and Hibernate. JDO was a bit too close to home for Sun though, and it got shit on. Miraculously, Hibernate held on and became bearable.
Now the best-practice persistence mechanism isn't part of the J2EE spec. So much for EJB and JDO. Some crazies (me) still argue that filling out reams of XML config files to create your O/R mapping is bloddy stupid and almost as bad as writing SQL to do the work, and therefore something should come along that hides the entire fucking database from the developer, bullshit or mapping files and all. But that's just me. (Yes, that's not always feasible for attaching to legacy databases. Eat a dick).
Ok, so we're satisfied that the J2EE persistence story is a fucking mess. Next up: UIs.
JSP. Let's embed Java into the HTML. Now the developers and the web weenies can shit all over each other's work. While we're at it, let's not include any way to do common things like pagination, alternating background colors in table rows, etc.
Enter taglibs, which attempt to solve these problems at the cost of having to write zillions of little snippets, put them some place, compile them into the JSP at runtime, and hope your web developer didn't fuck over the page again. Hmmm, no go. Did I mention JSP is slow?
Approximately 92 million tools of one sort of another sprang up to supplement or replace JSP. Most of them sucked, and some of the worst (I'm talking about YOU, Struts) rose to the top to become de-facto standards. So now we have servlets - which work pretty well, thankyouverymuch - mutated into some sort of bastard offspring of Swing that try to and succeed in getting in your way whenever possible. Now the best practice is - no joke - to do everything in servlets, which is the way it should have been done in the first place.
So that's the UI side of things. Notice there's no J2EE solution for thick clients, because God forbid someone want to cache something on the client. Plus Sun knows what a fucking piece of shit Swing is. And I'm not going to mention portlets.
That leaves us with JMS, which works primarily because the architecture + implementation were copied from existing messaging systems. JNDI, which annoys everyone anytime they go near it. JCA, which kind of works assuming the AS/400 is in a good mood that day. Probably a few other minor bits + pieces too. The core of J2EE was EJB though, and that was the fuckup to end all fuckups. You're much better off doing shit on your own, and not listening to Sun.
Re:What's that humming? (Score:5, Interesting)
Where I currently work, EBJ was attempted and 6 months later completely gutted and removed, the performance, complexity, tediousness in deployment, and lack of people who know it well were the biggest problems (and this is a place with almost 1000 java developers). At first it seemed like it would work well, allow separation of business and presentation and allow persistence; that's what you get on paper, in real life it is too cumbersome to work with.
I think EJB is going to go the way of CORBA (into the great code graveyard), nice in concept but not very useful when you take your idea from the lab to the real world.
Re:What's that humming? (Score:3, Interesting)
JSPs are servlets really. All your servlet engine does with them is compile them for you.
3-tier setups work really well for separation of concern. You can clearly do that without EJBs of course. But, if you put the effort into them, you can make them really useful as well. It's just a pain in the ass, especially when you try to use them with WebLogic or Websphere right out of the box.