Slashdot Mirror
Java Frameworks and Components
The book works through a logical progression, starting with a discussion of what a framework is (and, of course, what it isn't) before moving on to an examination of the benefits that they bring to development efforts. The meat of the book is in the next couple of chapters where a framework (no pun intended) is explored to select and compare frameworks. A list of current frameworks is given, each being described, with strengths and weaknesses highlighted.
The trailing chapters cover aspects of development that are affected by the use of frameworks, including the obvious ones like IDE support and methodologies.
What's To Like The aspect that most impressed me was the depth of research that has obviously gone into this book. I think most of us know that frameworks are good, and a reasonable number of us could list several reasons why they are good, but I suspect that very few of us could generate such a comprehensive and cogent rationale for using a framework.The information density in this book is quite high. Normally, I read technical books quite quickly, but this one took a while, because every good point prompted much thought and consideration. This was impressive to me after seeing so many books coming to the market that have simplification as their rationale for existence. The selection of an appropriate framework for web application development is not a simple task and this book takes it very seriously.
While non-free frameworks might be a non-issue for some of the Slashdot crowd, those of us working in corporate I.S. have to be very aware of the differences and our local management's attitudes concerning it. The book does come out strongly in favour of open-source and free software, but does not let this bind the discussion in any way. Commercial and free software are judged equally and fairly throughout.
Pragmatic is a much over-used word these days, but I would describe this book as pragmatic. The advice given concerning framework selection, urged people to consider many factors, including existing frameworks used in-house, the type of project, the degree of accordance between the services provided by the framework and the requirements for the system being written. I have seen many a framework selected because it was buzzword compliant, so this advice was a refreshing change.
What's To ConsiderAfter enjoying the book, to reach the case studies and be disappointed was, well, disappointing. The case studies seemed rushed and lacking in substance. The idea of comparing and contrasting the four leading frameworks to solve the same problem was a good one, but somehow it didn't quite come off. The Struts case study got to me the most: I have conniptions everytime I see business logic in actions! Perhaps the case studies could be dropped in a future edition?
SummaryA tour de force! With only one quibble, this is the definitive work on Web application frameworks.
Table Of Contents1. Components and Application Frameworks
2. Components: The Future of Web-Application Development
3. Application Frameworks: What Do They Provide and What Are the Benefits?
4. Choosing an Application Framework
5. A Catalog of Application Frameworks
6. Comparing Frameworks
7. Open Source and Components/Frameworks
8. Development Methodologies and Design Patterns
9. Integrated Development Environments
10. Strategies for Using Frameworks: Best Practices
11. Conclusions: The Future of Frameworks and Components
Appendix. Case Studies
You can purchase Java Frameworks and Components: Accelerate Your Web Application 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.
it's no longer necessary to even think about writing low-level code (except as a technical exercise, or to express your inner geek :-)
Obviously, the guy that submitted this story doesn't know about handheld devices and embedded software. We are still writing A LOT of low-level code on this little planet. And it seems we will still need it for a couple decades.
Frameworks are certainly excellent for high level programming (my end of studies memoir is about them) but they are still way too slow, too bug-gy and too bulky for our little devices... And the thing is that we gonna have more and more little devices in the near future.
Also, your framework works on top of what ? Yes, low-level code...
Iraq: war to save the U
Case Studies (as in this case) always seem to come at the end of the book. If they were really analyzed they'd be earlier. Too often this is the author's response to the publisher's request for 80 more pages.
If so I can't really tell. The review seems pretty empty and doesn't really contain any hard info that couldn't be found on amazon.com.
That being said. Java's frameworks tend to be very high quality and easy to work with in my experience.
Not everything is analogous to cars. Car analogies rarely work.
Avoiding frameworks and middleware can be just as important on much larger systems.
Often these frameworks ("always" in the case of middleware) will add not just overhead (latency or burnt CPU cycles) to your system, it can add complexity. When given the choice of incorporating some already existing framework, or re-inventing the wheel, I often (but not always) choose to re-invent the wheel.
See, I will end up with a wheel that I know. A wheel that spins like it should, and doesn't spontaneously start brewing coffee, because someone thought that would be a great idea.
Some are religiously against re-inventing the wheel. But hey, the wheel is a well known technology, it is not necessarily very difficult to re-invent it. This amount of work, compared to the long-term implications of being dependent on something that you do not "own", make a little re-invention here and there well worth it.
Earlier on slashdot today you saw ATMs being hit by an RPC worm. Why is an ATM vulnerable to an RPC worm? Because it runs RPC. Why does it run RPC? Well, because nobody re-invented the little wheel it would have been to do a simple data transfer over a TCP connection. No, they chose either to use RPC, or to use a significant amount of middleware which did not allow them to disable RPC (otherwise, why would it have been enabled?).
If people feared re-invention a little less, and once in a while re-wrote that darn wheel instead of relying on frameworks and middleware that they cannot possibly hope to fully comprehend, you would not have ATMs being hit by RPC worms. Ximian Evolution would not take up hundreds of megabytes of memory. Web sites would not mysteriously hang if the MS ASPX interpreter got stuck. My PHP sites would not start giving load errors on every 5% of the hits after a bad call to a file load routine half a decade ago.
The world would be a better place.
Now go re-invent, please.
And lately, I have started looking at Java as a corporate-hep buzzword too, not to mention .NET, and a hoarde of other ones.
Whatever happened to the concise, well-written, to the point books of a few years ago. Kernigan/Ritchie's C book comes to mind, though it was a C Reference Manual.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Its almost impossible to keep track of all the frameworks that have sprung up around Java. It seems hardly a day goes by by without someone announcing either a new framework to address issues the rest of us were not aware existed or a new release of release of one of the plethora in existence.
I find myself in a rather ironic position now. A few years ago I was a strong proponent of frameworks. I saw no reason why essentially the same code should be rehashed slightly differently when a framework could be made of the core material and the rest customised as required. Now I have to press the pause button when a framework is put forward to determine if it suits our requirements or is complete overkill for what we need or forces us into an excessively complex architecture to facilitate it.
While still in favour of frameworks I believe you can have too much of a good thing. I think many frameworks available today ignore the "frame" part of the concept and actually try and fill in all the code for you.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Now just think of how far engineering would have advanced if had taken the same path? Don't build using standard girders, and fastners. Re-invent your own kind of girders and fastners.
Computer Science will never mature as a discipline as long as is NIH is so prevalent. It's not a cool, but then building anything has "not cool" elements.
I'll say it again: Web Apps Suck. Since this statement confused some people last time I said it, allow me to clarify. For a blog-type-system like Slashdot, webapps are cool. For a simple log-in to your bank and check your account balance, web apps are cool. In fact, right up until you find yourself implementing kludgy work-arounds to get around limitations in HTML, web-apps are cool. The minute you have to resort to Javascript, 1-pixel spacer GIFs or back-end session management databases to get around the fact that your user could be talking to any machine on your cluster, web-apps are no longer cool.
If your web-app is so complex as to need a framework, your web-app probably sucks. It is probably a bloated, complex, nearly unmanagable piece of code that would have been a lot better off implemented as a stand-alone Java program or a lower-level language portable back-end attached to a UI written in either Java or one of the portable UI libraries that are available. But no, your manager wanted to avoid all that because (pick one) 1) everyone's talking about webapps and he went "ooo" and started drooling or 2) You thought it'd look good on your resume so you suggested generating all your applications from XML files using Java and struts.
I expect to see a backlash soon as more people run up against the limitations and unique problems associated with the crappy HTML protocol. The workarounds will become more and more atrocious until eventually the whole thing implodes. I can't imagine it taking more than 4 or 5 years for this to take place.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Some poor guy in India.
I am unamerican, and proud of it!
Yep, you get to be Da Man, all right.
You get to be Da Man who gets called at 3am when one little thing you forgot brings the whole shebang down. You get to be Da Man who gets to enhance it for every little niggling request from your fellow coders. You get to be Da Man who has fingers pointed at him first, then find out later somebody's app didn't follow your rules. You get to be Da Man who meticulously documents it, so they know those rules.
You get to be Da Man who can't take vacation or call in sick.
I gave up my desire to be Da Man some time ago.
Garg
Garg
Alumnus, Xavier's School for Gifted Youngsters