Java Frameworks and Components

Simon P. Chappell writes "Life is busy enough without writing your own infrastructure code. With all of the high-quality frameworks available today, it's no longer necessary to even think about writing low-level code (except as a technical exercise, or to express your inner geek :-) Our problem today, is to review and select the best available framework for our needs. This is a non-trivial task, but help is at hand with Java Frameworks and Components by Michael Nash." Read on for the rest of Chappell's review. Java Frameworks and Components: Accelerate Your Web Application Development author Michael Nash pages 477 (14 page index) publisher Cambridge University Press rating 9 reviewer Simon P. Chappell ISBN 0521520592 summary A tour de force! With only one quibble, this is the definitive work on Web Application Frameworks. Overview This book is a superb exploration of the current state of the web application development framework market. Both commercial and open-source/free frameworks are examined in detail.

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 Consider

After 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?

Summary

A tour de force! With only one quibble, this is the definitive work on Web application frameworks.

Table Of Contents

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

Comments

No more low-level code ? Hum...

[zeux]

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

Re:No more low-level code ? Hum...

[wembley]

Except for the fact that this is about web frameworks, e.g. high-level code.

Re:No more low-level code ? Hum...

[Elwood P Dowd]

Java. He's talking about Java programs. It's no longer necessary to even think about writing low-level code like widgets. He's clearly not talking about embedded systems.

Re:No more low-level code ? Hum...

[captain_craptacular]

This book is a superb exploration of the current state of the web application development framework market.

Please please tell me you aren't writing web application frameworks to be served from your handheld devices.

Obviously, the guy that submitted this story doesn't know about handheld devices and embedded software.

The poster didn't imply that no-one will ever have to write low level code again. He said that you shouldn't have to in this specific context, which is web application frameworks. Of course there will be other areas where low level code is still quite neccesary, no-one said otherwise.

Re:No more low-level code ? Hum...

[Brians256]

Low-level code is not only for handheld devices and embedded software. Sometimes the existing framework just plain doesn't cut it.

It seems there is a huge blind spot concerning "the rest of the code". Not everyone is coding web pages and Java/.NET commerce systems! What about the applications like MS-Word, Mathcad, Compilers, or BitTorrent. OK, the last example is written in Perl which is not really a low-level language but it is certainly not a framework like .NET, but it COULD be written in a low-level language.

Or, how about stuff like what we do at http://www.cmicro.com for probing semiconductor wafers (hardware control/IO/mathematical analysis of signals, etc...). We use a standard PC to do things with a (unfortunately) Windows OS as a base, but we HAVE to do low-level code. The existing frameworks of .NET and MFC simply are not sophisticated enough to do the UI we need, and it does not allow access to hardware that we need. Re-inventing the wheel? I wish I didn't have to!

Dangit! Not everything is the Web!

Re:No more low-level code ? Hum...

[Brians256]

The book is about web frameworks. The short blurb at the top is not. It irritates me that snobs always pop up saying that this 4GL or that 5GL (or even TK/TCL, LISP, Smalltalk, Java, Eiffel, etc...) will "solve all your problems" and make low-level coding obsolete. The intro text made it seem like this was another one of those misguided zealots.

So, yeah. It's a hot button. But the leader text was misleading. Many journalists do it, but that doesn't make it OK.

Re:No more low-level code ? Hum...

[magnum3065]

Ok, first BitTorrent is written in Python, not Perl and yes it COULD be written in a low level language, but so could every program that runs on your computer. That doesn't mean that it's a good idea.

And, while this book is about frameworks, not languages, your concept of "low-level languages" seems a bit confused. Your example applications could all be written in Java or some other high-level language of your choice. Take a look at the Eclipse Java IDE which is written entirely in Java (minus the backend of the SWT toolkit it uses for the GUI). Writing lower level code is usually about optimizing for speed or memory constraints, not lack of functionality.

Just because you need low-level access to the hardware doesn't mean you can't use C# to write the GUI for your program. Using TCP/IP requires access to your networking hardware, there just happens to be a set of libraries that extracts away the details, but gives your higher level components what they need. If you need to write some assembly routines to do your hardware access, do it and then wrap it in an API that will let your .NET GUI access it. Just because your program needs some low-level code doesn't mean you have to write it all low-level.

Re:No more low-level code ? Hum...

[Brians256]

Our newest project is (partially) written in C#, thank you. It is, however, an awkward blend. Using heterogenous environments for development brings it's own problems as you probably know.

The intent I was trying to communicate was that the existing framework is not always sufficient and that working around the limitations may cost just as much or more than the savings gotten by using the framework. I was using the term "low-level" to denote programming environments with less of a predefined support structure and more primitive (and more flexible) primitives.

For instance, in .NET you cannot easily implement COM Automation servers. This happens to be because of a Microsoft choice to lessen the complications of mapping CLR executables into normal EXE memory space, but it is still annoying. We have to implement a proxy in another language and communicate with another interprocess protocol. It takes time to implement this and other workarounds.

Also, the .NET framework (and most others) is written very well to support a certain class of applications. When doing other kinds of applications, you end up with nearly the same lack of support you would have gotten in plain C++ with (insert your favorite UI library). String processing actually seems WORSE (to me) than C++.

Finally, I have to say that I actually like C# and Java. I just don't think they are some sort of God-send that will make my life peaches-and-cream. My point is to stop the hype, not ignore the benefits. I really LOVE having built-in garbage collection, stronger type checking, better IDE for UI creation, and memory corruption checking.

Re:No more low-level code ? Hum...

[Anonymous Coward]

I understood it given that he expressly mentions web work. I think your a bit over sensitive aobut the work you do, my friend.

Re:No more low-level code ? Hum...

[Anonymous Coward]

Not talking about embedded systems? It wasn't that long ago there was zero(!) web-related programming done in Java and a ton of embedded programming done with Java. That was the purpose of the language. That was how Sun sold it originally. Have people so forgotten Java's goals that they're so cavalierly disregarded now?

Re:No more low-level code ? Hum...

[Paradise Pete]

will "solve all your problems" and make low-level coding obsolete. The intro text made it seem like this was another one of those misguided zealots. So, yeah. It's a hot button.

Hey, we could write a program that would check for stories like that and have it automatically respond. If we did it right it would make all this low-level posting obsolete.

Re:No more low-level code ? Hum...

[Brians256]

Ha! You actually made me smile before the caffiene kicked in, which is nigh amazing. :-)

Case Studies

[krulgar]

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.

aren't?

[dance2die]

Arent' there as many frameworks as there are coffee types in Starbucks? I wonder which java framework i woudl like to choose.. IT's a daunting task for me already to pick a right flavor @ coffee shop... :)

Re:aren't?

[javaman235]

I was just reading about that dillemma here:

http://otn.oracle.com/oramag/oracle/02-nov/o62odev _java.html

If you ask me, the whole thing is retarded. Whenever you get these high level abstract frameworks, they imply limitation and slowness, both in running and writing. (Examine Zope as a perfect non-java example.) People forget that learning new frameworks takes lots of time, time that could have been spent just writing code. They also limit what you can do for everything they give half the time.
I used to use j2ee on tomcat, but I found that for many projects the faster to write faster to run solution was via fastcgi.
http://www.fastcgi.com
The principle in my sig seems to hold true the better I get.

No more low-level code ? Hum...Servers.

[Anonymous Coward]

True, but most frameworks are used on the server-side were slow, bulky, and buggy can be dealt with, and the client is were the low-level code is being used.

WTF is "infrastructure code"?

[heironymouscoward]

(Raises hand)

I think I understand the term, but does that mean it's a given that any application is built around a "framework"?

All well-constructed software is sliced into coherently-discrete layers that are solved as individual problems, but I believe the "framework" concept is largely a commercial concept designed by certain vendors to enable them to sell large, complex toolkits.

Are we not in danger of taking this commercial model and turning it into dogma, in which your application shall be built around a framework and the only choice is "which one?"

Re:WTF is "infrastructure code"?

[nehril]

all applications use frameworks. the only question is where do you get your framework: do you code it yourself or use someone elses?

lots of apps need to validate form input, connect to a database, retrieve data and save settings. these are generic "framework" tasks that apply across a wide range of applications. You start with these base foundations (either you roll your own or use someone elses), and decorate it with your particular business needs.

Frameworks like Struts for web apps include much of the stuff you would do yourself anyway: authentication, validation, form repopulation, session management. since lots of geeks/nerds get together to create these frameworks they are often more complete than something you would whip up yourself.

Since they do stuff you were going to do anyway, they can save tons of development time. that's why it's an important topic to be educated about. they are not just "make money commercial concepts."

Re:WTF is "infrastructure code"?

[pmz]

Since they do stuff you were going to do anyway, they can save tons of development time.

This is the ideal, but it doesn't always work out in practice. From what I've seen in the real world, a common thing is to adopt a framework, like Struts or J2EE, then think it isn't necessary to really study it and learn its nuances, then look confused when the application breaks and is very hard to debug due to the two or three extra layers of software. The result is a bunch of programmers pointing fingers until enough time passes for the issue to more or less become forgotten until the next breakage reminds everyone creating a new round of finger pointing and forgetfulness. There seems to be a desire among programmers to adopt a framework because it feels like a good thing to do, even if their appliction would be perfectly suited by a "primitive" or "obselete" CGI program in perl or C or even just using JSPs without all the baggage of servlets and beans.

Re:WTF is "infrastructure code"?

[whereiswaldo]

Those "extra" layers of software are arguably layers that you should create yourself anyway, just to separate out presentation logic, business logic, etc. If it breaks, ideally you will have the source code, so no big deal. Either way, you should have support in the form of a community or a business. Had you rolled it all yourself, you'd be on your own.
Personally, I'd rather see someone I put to task working on solving the problem than writing and debugging new wrappers for everything they way they think it should be done, then watching the project go over budget and down the crapper. Don't reinvent the wheel unless there's a good reason for it.

Re:WTF is "infrastructure code"?

[pmz]

Don't reinvent the wheel unless there's a good reason for it.

I agree, but the problem I saw was basically a project buying a new wheel, ignoring the user's manual (or just reading chapter 1), and then being clueless and defensive when they got a flat. Sadly, I think this is pretty common in software projects.

Another problem I've run into is when complex frameworks are adopted and then the project can't keep up with the evolution of those frameworks. When the project can't afford more than a couple developers, having the OS, some primary applications, and a couple frameworks all go through two or three major revisions during development, when they want to be able to sell a fairly modern package, can become unbearable. Salespeople feel awkward pitching a two or three year old platform. Clearly, this project is underfunded for its complexity, but I feel that taking a slightly more home-grown approach initially would have mitigated a lot of the uncontrolled obselesence.

Re:WTF is "infrastructure code"?

[scann]

Lets face it the technology moves quickly. So one way or the other if the code isn't updated to be current with these standards it is outdated anyway. These technology evolution is a large part of the reason frameworks evolve quickly too. At a recent Gartner IT/Symposium, they said frameworks are 90% iterative.

So yes they do move quickly. And without them you'd be doing it youself. And what you can't replicate is the 1000s of developers using it in real environments and it evolving based on what works and what doesn't. You are going to find out the hard way.

Why Use frameworks? J2EE frameworks enable a level of abstraction from the business logic. This clear separation enables the features of the application to evolve separately from the framework. You get to focus on your application instead! And once you have developed more than one application the benefits of a common framework across your applications is much greater.

Most people who develop their own end up with emeshed architecture code in their business logic which results in higher maintenance burden!

Gartner says frameworks are part of the productivity layer and recommend their client to use frameworks. As frameworks offer tighter integration with IDEs, code generators, wizards and the like you will find their adoption widespread. Have a look at www.mvc2frameworks.org for more information about mvc based frameworks and a comparison spreadsheet.

IMO being Struts based for example is a good sense for sales since it has become a defacto standard.

No more low-level code?

[duffbeer703]

Who writes the frameworks? HAL 9000? Nanomachines?

Re:No more low-level code?

[Anonymous Coward]

Who writes the frameworks? HAL 9000?

I'm afraid I can't do that Dave.

Re:No more low-level code?

[Krach42]

Some poor guy in India.

Who are you?

[Sean80]

I've said it once, and I'll say it again. Who are you, reviewer? Are you connected to the author or the publisher? Do you have any financial interest in this review?

At least try to provide a disclaimer. Otherwise, an excellent review of a technical book published on probably the largest technical web site on the internet. Smells like fish, tastes like fish to me.

My 2c.

Re:Who are you?

[Anonymous Coward]

consider the possibility that there are some people spend all their time doing nothing but /. book reviews. treat it as their contribution to the open source world, particularly for those who have clauses in their terms of employment that prohibit them from participating in OSS projects.

Re:Who are you?

[Anonymous Coward]

Simon P. Chappell
simon.chappell@landsend.com
Java Programming Specialist
www.landsend.com
Lands' End, Inc.
(608) 935-4526

It appears that he's not connected with the author. Here's his resume. And also of note is that this is his personal website, "Simon Peter Ministries." He calls himself a "recycled atheist." He's also involved with the United Pentecostal Church, whose members are known to beat their children. His wife looks a little too young to be married to him but, as people know, UPC members often enter arranged marriages at a young age. Also, his head is very square.

Was there anything else you wanted to know about Simon? For some reason this post has a lot of junk characters according to Slashdot's poor filter. Perhaps they should ask Microsoft for a closed source solution so that I can post useful information without having to put filler like this in?

Re:Who are you?

[Sean80]

And I'm absolutely cool with that, but I think it at least needs to be said. Without that, who knows?

In some respects, I think the editors at Slashdot need to understand their power a little better. This is a popular site, and a lot of people read the articles here. With that popularity - even though Slashdot might not be considered "official" media - comes a certain level of responsibility. I believe that part of that responsibility is demanding that submitters, when there is the possibility of a conflict of interest, disclaim that conflict of interest. Yes, they may be lying, but that ball is in their court.

Re:Who are you?

[wideBlueSkies]

>>I've said it once, and I'll say it again. Who are you, reviewer?

He's some dude who works for Land's End.

wbs.

Re:Who are you?

[The Masked Rat Fink]

Good question.

I am the author and I appologise for forgetting to put a little something about me in the review. My excuse is that I'm too humble, but who knows if you'll buy that? ;-)

I am a Java developer with Lands' End. In fact, I was the first Java developer that LE hired, and I've been with the company five years now. I have worked with Java since version 1.0 and was also responsible for the first Java program written at my previous employer (CUNA Mutual Group ... Go Credit Unions! :-)

I have a slight relationship with the publishing houses, in so far as they send me books. I have no connection to the authors. I get to keep the book, but there is no payment for these reviews. I am highly opinionated, so if I say that I like a book, then that's the straight dope. Check out my personal website if you want proof of my willingness to express opinions (http://www.simonpeter.com/)

Hope this helps, and I'll put in a bio next time.

Simon

Re:Who are you?

[Anonymous Coward]

You're not that guy that used to work at John O' Goats are you?

Re:Who are you?

[The Masked Rat Fink]

You found me out! :-)

Actually, Lands' End (the company) is named after Land's End, the most south-west tip of the United Kingdom. The founder of the company was a transatlantic racing sailor, and Land's End is the start or finish point (depending upon direction) for most transatlantic races.

Re:Who are you?

[easter1916]

John O'Groats, I think. Not Goats.

Why not write your own Framework?

[Guru1]

Simply put, our group wrote our own struts type framework. This was around 4 years ago when struts wasn't quite as hyped, and we wanted something that did exactly what we wanted, without extra baggage or cost. Four members in our group, it took us around a week to write the basic components.

Other groups (sitting a few feet away from us), have gone through a couple framework tools, ending up with struts.

I really don't see a difference in either approach. So many times writing your own tools is frowned upon, but when you're talking about small scale projects, why not? Do you really need every feature of struts to display a fairly simple website? A few forms, polls, etc.. why install such a massive package?

For my home machine, I wanted a couple forms, a photo album, and fairly simple navigation. I wrote it in a night. It would have taken me just as long to download the tools, install them, and set them up.

I think the problem is that it's a very "in thing" to use the latest tools. The technology lead for the other team was pushing for one open source solution before, then was pushing for struts, now is pushing for some other "cool" tool. I would rather focus on writing for what is needed, rather than for what is a cool solution.

Re:Why not write your own Framework?

[cjustus]

I completely agree... Many frameworks are totally bloated and/or buggy... An inhouse framework will meet needs more closely, and will always be more efficient than a generic framework... When performance is important, and full control desired, an inhouse framework is the way to go...

You'll hear people argue that using an open source framework (and most are) will allow you to modify the code, but once you down the path of making changes, forget about upgrading as new versions are released...

My 2 cents

Re:Why not write your own Framework?

[galacticdruid]

right - get the job done and get it done right. However, a framework is really useful on very large projects, when you can override classes and make good use of code reuse. This is helpful when you have your more skilled developers doing a lot of the interaction between the framework and the customizations to it to fit your specific needs. Then the more junior programmers can simply tie everything together at that point.

Re:Why not write your own Framework?

[Anonymous Coward]

In general it is a best practice within all of engineering to reuse what is already there. It takes time to design, develop, test, and maintain a custom framework. It may start out as simple but over time the chances are that it will grow. As it grows the upkeep will grow. By using a framework that is already highly regarded by the industry you save yourself all of those costs as well as benefit from using a proven technology. I am not talking about bleeding edge frameworks that are not standardized like JSF or Portlets but standardized technologies like struts.

DISCLAIMER:
There is little doubt in my mind that JSF and Portlets will become major players in the framework arena but for now they are the equivalent of beta software.

Re:Why not write your own Framework?

[scumbucket]

I used PHP extensively for a number of years and finally wrote my own framework. In the end it turned out to be very much like some of the Java frameworks out there.

IMHO the good parts about PHP are also the bad parts. ie, * you don't have to say what type a variable is, but that means you can't specify a type of parameter to a function. * you don't have to specify scope, but then you can't protect functions that should be private etc.

I looked at a lot of Java code for ideas on what I could do with PHP to clean it up . The main things that I did were: set up a 3 or 4 tier architecture.

* database abstraction layer
* business layer
* presentation layer (preferably using templates)

(I modeled a lot of this on Enhydra - www.enhydra.org)

never use globals. Wrap up the HTTP_GET_VARS, HTTP_POST_VARS etc in a class (ie Request). Create classes to wrap the server vars and whatever else.

Use classes for everything. This gives you a reasonable amount of namespace control.

Never access variables directly in classes. Create accessor methods for them.

I think that if you are feeling the need to structure your PHP, you will probably need to move towards Java or some other more structured language. It can definitely be more challenging to write, but as your applications get bigger, the compiler-enforced type checking, programatticaly enforced/supported interfaces etc will save you a lot of time in the long run.

Re:Why not write your own Framework?

[spludge]

I wonder about this sort of a solution in the long term though? The team that I work for wrote their own framework a while back and since that time has grown and had signficant turnover. Sure everything is fine when the original members of the team are there that have inside out knowledge of the framework that they wrote, but when they leave then you tend to lose a lot of that knowledge. This can be solved by good documentation, but at least in our project that didn't happen and I can't see it happening in many other projects either.

One of the benefits of going with a well known framework like struts is that there is a lot of documentation and knowledge out there about it. Lots of books, user groups and other people that have a lot of knowledge about it. This sort of common experience with a framework makes it easier to grow a project and to bring new people on.

Re:Why not write your own Framework?

[enjo13]

While you qualify this 'especially for small projects', I feel that all projects (big or small) benefit from standard underpinnings when they are available. One of the absolute BIGGEST reasons to standardize on a open and free framework like Struts is a business buzzword known as 'knowledge management.'

It is MUCH easier to find a programmer familiar with Struts than it is to find one familiar with your framework. When you leave the company, move onto other projects, or (god/allah/diety of your choice forbid) are hit by a bus your proprietary framework now must be maintained by someone else. If you had used a standard framework to do the same thing, then you can easily go out and find a programmer who can more easily step in and fill that role.

There are, of course, lots of other benefits. When your framework has a bug, it requires your time to find and fix it. One open, free frameworks it's often fixed before you even know about it. When you have lots of developers working together on a mission critical piece (the framework), then your application benefits with only a small effort from you. The whole is MUCH greater than the sum of it's parts in this case.

The only caveat to this is knowing when a tool TRULY meets your needs. I'm a PalmOS C++ programmer (a rare beast:) ) and while there are a couple of nice C++ frameworks out there, neither begins to address the level of abstraction that I desired. I could have used them, but would have spent more time fighting the framework than I would from enjoying it's benefits. So I rolled my own. If there was a framework that truly met the needs of my application, I would have used it in a heartbeat. It sounds like the problem for your 'other groups' isn't the frameworks, but their inability to accurately understand how the framework fits into their product.

Re:Why not write your own Framework?

[msuzio]

I have also written my own framework. Actually, I've "written" it at least 3 times -- once in Perl, once in Java, once (again) in Java once I understood tag libraries and JSP's better. It was an evolution of concepts and best practices in Web programming borne out of my experience in the field (I think I wrote my first web app in 1995?).

I wrote my framework because at the time, there wasn't anything out there that was decent and fit my thoughts and opinions about "how it should be done". So far, it's worked out well. I can train a good programmer to use my framework in about 2-3 days if they already know basically how servlets and JSPs work. They usually really "know" it after a couple months working with it... about typical for a good framework, I think. I suspect my framework is more efficient than most of the "general" frameworks out there like Struts, because I built it to fit the needs and the programming model unique to my group(s), and my situation.

Even given how far Struts et al have come, I still prefer what I cooked up. I plan to do another rewrite of my framework in Ruby soon, both to learn the language and to have another possible platform I can deploy my own MVC concepts onto... it's my baby, and I like it :-).

Re:Why not write your own Framework?

[Baki]

I agree fully, I've done the same though I prefer to call it a "library". A framework sounds so pretentious.

Our library (it was "mine" once but now it is a shared effort of about 4 developers in a group of 30) does about the same as struts, and also contains custom tags. It is not configured by ugly xml files though, but 100% based and focussed on JDBC.

The library itself was a relatively small effort, and it pays back because it is totally tailored to our needs. The project is large enough to justify the effort by far, and fitting our needs so perfectly it has paid of many many times already.

I truely have my doubts on high level all encompassing frameworks such as struts. Basic technologies, such as the JDK class library itself, or JSP and servlet API's, or corba or whatever for interprocess communication, of course provide a great benefit and cannot be done without. But above that level, any project of decent size is better of writing their own environment.

Re:Why not write your own Framework?

[msuzio]

I agree that writing your own framework severely decreases the "truck number" of the project. My current project is pretty much screwed if I get hit by a bus. Right now, I consider the benefits we're getting out of having 'rolled our own' to outweigh that risk. I do have the best of intentions of putting more effort towards documentation, commenting, etc to try to make the framework survive my tenure here...

I think the risk of established frameworks, the trade-off, is that they are not going to be optimized for your needs and your practices. For me, using something like Struts would be a pain in some ways only because the way it is set up is far more generalized than what I need. I had the same problem with Tomcat too... it was almost too configurable (I actually fell back to using Resin as our servlet engine partially because I found it easier to use and administrate).

Re:Why not write your own Framework?

[MSBob]

Our company did the same thing. They wrote their own frameworks to replace struts and their own O/R mapping layer.

It was one of the overlooked disasters.

Things looked pretty good for the first year or so when the requirements were straightforward and the persistence mapping quite simple. As the product grew the frameworks we built got very complicated very quickly and everything we built was in some form available in other products. Maybe there wasn't a one for one feature match but I think the small discrepancies absolutely did not justify the effort spent on building your own application framework.

Why anyone would build a persistence layer when Toplink and Hibernate are both excellent tools which will almost certainly outperform homegrown solutions.

Same with struts. We built our own struts-like framework with our own tag libraries and our own templating engine. Now we have to have people dedicated to maintaining that stuff all the time and at least keeping pace with the popular frameworks.

Re:Why not write your own Framework?

[fishbot]

On the one hand, depending of course on the project, I am all for writing a framework to support the application structure required.

On the other hand, it can have MAJOR downsides. If the technology choice is wrong, or if the dvelopers are not quite up to the task (despite protestations to the contrary), things can go quite horrible.

At the company I work for, a couple of guys were given the job of building a development framework for building ALL internal infrastructure applications on. For some, utterly utterly bizarre, reason they built the whole thing in PHP4. This in itself has caused major headaches.

Then, out of the blue, the main developer and owner of all knowledge of the framework left for another company. While I wish him all the best (and I really do) it has left the rest of us with a complete waste of time. Nobody knows the framework, and it wasn't complete on handover. Deadlines are too tight to complete the code. The whole project is screwed.

It goes live tomorrow.

Oh dear.

Re:Why not write your own Framework?

[pmz]

One open, free frameworks it's often fixed before you even know about it.

It should be stressed that frameworks are most helpful when they are open-sourced. Fixing the bug first and, then, notifying the maintainers later is something that really saved my ass once.

Re:Why not write your own Framework?

[sfjoe]

One open, free frameworks it's often fixed before you even know about it.

Only if you're willing to stay on the bleeding edge.

I am a developer at one of the web's busiest sites. If we were to incorporate a framework, it wouldn't be very long before our unique requirements (some legacy-driven, some traffic-driven) would require a code fork.
There are many reasons why a framework is a useful addition to the codebase and just as many reasons why it is not.

Re:Why not write your own Framework?

[ShinmaWa]

I do have the best of intentions of putting more effort towards documentation, commenting, etc

How's that road to hell coming?

Re:Why not write your own Framework?

[rollingcalf]

I agree. Sometimes it takes more time to study the ins and outs of an existing framework than to write a skinnied-down one for yourself.

Re:Why not write your own Framework?

[hachete]

Because eventually, you create a maintenance nightmare, particularly in companies where the employee turnover is high. I'm sat here faced with several large applications which my group (with and without me) wrote from scratch. Completely. Including a complete cross-platform graphics framework. Without the external objectivity that frameworks offer, they just grew like topsy, with no control. It turns out that there's nobody left who really understands any of these things, and we're desperately trying to re-factor to java or bought-in apps.

However, it's up to you. If that's your core-business (you write frameworks, say) then, please do write from scratch. However, if it isn't your core-business, then I would suggest it wise to consider a framework.

It occurs that, in the round, both Python (with it's concept of services) and Perl (with CPAN) can be considered frameworks.

h

Re:Why not write your own Framework?

[msuzio]

I find the road to be a pretty slippery slope for the most part :-).

In my defense, I do revisit things pretty much every day and comment out *something* or clarify the code better. In my current situation, that's the appropriate use of time, because I only have 2 other developers relying on this code base, and they already know it pretty well. I try not to envision the "getting hit by a truck scenario", since I'm a firm believer that you always get exactly what your thoughts dwell on (*)

(*) except for the naked women. Batting average is somewhat low on that one.

Re:Why not write your own Framework?

[Anonymous Coward]

Do as I say not as I do!!!

Re:Why not write your own Framework?

[tdanard]

I did write my own Java framework. Why ?

The most popular Java frameworks today are "tags libraries", rely on JSP, or are designed with EJBs in mind.

I don't see much benefit using a tag library when you already know HTML. I have a large experience of development with Oracle Web Application Server. I always found their tag library silly.

In general, JSP is just not my thing. Not only I have more control over the end result using pure servlets, but I am much more comfortable maintaining Java code than maintaining JSP/HTML files.

JSP is quite limiting too. How do you create a database-driven search engine for your web site when the structure of your content is stored in JSP files ? I prefer to store all the information (including the web site content structure) in the database, with everything else, so that I don't have to worry about 500 files. Once the application is deployed, I only worry about the database.

For a regular web application, there is no reason to go the EJB way. Not only EJBs are quite complex to code, but it has performance issues and adds a layer of complexity to the hosting. An overkill for my needs.

I didn't find any 3-tier java web framework meeting my criteria. Maybe you will find that my requirements were misguided but I am quite happy with the end result. An example of web site using my framework is available at: http://www.corendal.com/arttoulouse/home/

Note: I have published my framework online, under GPL license at http://sourceforge.net/projects/corendalfm/

Rolling my own...

[Anonymous Coward]

Am I the only one who thinks that sometimes its simpler, not to mention more fun, to write my own low-level/framework code? Before you flame me, I DO understand the value of using a framework (reuse, time, integration, other developers, blahdiblah). When you write your own framework, you get to be Da Man.

Re:Rolling my own...

[Anonymous Coward]

I prefer to roll my own. Who knows what kind of shit someone else might stick in behind closed dorrs. You don't wnat to get halfway through your joint before realizing it's laced with sawdust. or pcp.

I smoke GNU/Pot that I roll myself.

Re:Rolling my own...

[vmfedor]

If you have the time and interest to do it, it'll always be the better choice. The problem is that generally (unless you're some megacorporation) you don't have the time, manpower, or interest to invest in writing your own framework, at least when you see the amount of existing tools that are out there already. It's also cheaper to user a ready-made one.

So I wouldn't say it was 'simpler,' but definantly more fun. :)

Re:Rolling my own...

[Anonymous Coward]

since my wife and I have had our first kid, I haven't smoked a single joint. i'm planning a trip this spring with the boys, and I'm gonna smoke a GNU joint like it was my job.

book reviews are for sissies.

Re:Rolling my own...

[Garg]

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

Did you actually read the book?

[ViolentGreen]

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.

Useless

[blamanj]

Excuse me, but what frameworks are compared and covered?

Are we talking GUI frameworks, JSP Engines, Web application frameworks, what?

This "review" told me nothing.

Re:Useless

[piobair]

I concur. Is this a book about _how_ to evaluate frameworks, or does it actually evaluate some. The review is sorely lacking.

Re:Useless

[Anonymous Coward]

Um...try reading the VERY FIRST SENTENCE of the Overview.

It's truly unbelievable how quick some people are to insult others when what they really ought to be doing is looking in the mirror.

Re:Useless

[Anonymous Coward]

Um...try reading the VERY FIRST SENTENCE of the Overview.

Um..You mean the part that says "This book is a superb exploration of the current state of the web application development framework market."?

Yeah, that was real helpful. Perhaps you meant the 2nd sentence "Both commercial and open-source/free frameworks are examined in detail.".

That's a bit more helpful, but which commercial/open/free frameworks is he talking about?

To paraphrase your .sig, maybe you should stop looking in the mirror and read what was missing from the review.

Not just little devices

[Oestergaard]

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.

Re:Not just little devices

[IWorkForMorons]

Now go re-invent, please.

Yes, you're right. Frameworks can add complexity and overhead. But they also provide for rapid app development, common functions, and a shorter learning curve. The reason I found it frustrating to work in Java in the beginning was because I had to re-invent the wheel everytime. I use to do the same in other languages, until I got pissed off and began writing my own frameworks. I never got to work in Java enough to do one for it, but anything would have been better then programming my own widgets that never quite come up the way you want. It would have been nice to have something do the low-level repetative stuff for me while I concentrated on solving the real problem.

Frameworks do have their place, especially in businesses that need fast software turnarounds. So please...don't re-invent unless something stops working first.

Re:Not just little devices

[Capt_Troy]

My company reinvented the wheel. In this case we are talking about a webserver. It was done with such ingenuity that it could serve up page after page on a single thread. It also taught users patience as they waited for their GETs to be fuffilled and there was a certian "flow" to the pages as one could watch each graphic pop up one after the other.

I see what you are saying, but sometimes, even a wheel is complex.

Re:Not just little devices

[Saeger]

Wow, a BLOCKING web server. You've got some great coders working at your company!

--

Re:Not just little devices

[Capt_Troy]

Yea, tell me about it. At least it fuels my job searching to an almost frenzied state!

This will really wack your mind...

Early on in my career here (7 months ago) I asked why we would be so bold as to develop our own webserver and not use apache (after all, we aren't in the webserver business) and I actually got yelled at. "It's way more secure if we write it" they screamed. I laughed inside, especially now that I have scene the code.

One guy suggested the use of signal handling in our app. This made our "golden boy" programmer (the one and only developer of the web server) mad and the suggester got fired the next week.

So in closing... anyone need a computer guy?

Re:Not just little devices

[butane_bob2003]

Your're hired! Welcome to StupidTech. We chose you for your burning desire to re-invent the wheel for the purposes of security through obscurity and the belief that your code is better than anyone else's and that code re-use is for morons who can't write their own file load routines. Get cracking! We will be paying you based on how much code you don't re-use!

Why is an ATM vulnerable to an RPC worm? Because the people who made the ATM were dumb enough to run it on Win2k, which was running DCOM _by default_, they did'nt know it was a security problem until it was too late. "Lets just run all our ATMs on Win2k, that should be safe..."
Ximian is using 1.7% memory currently. I've never found it to be a memory hog.. mozilla on the other hand..
The MS ASPX interpreter sucks. No question. PHP has problems, no question. If you are going to insist on using crappy frameworks, then this book is probably not for you. Had your read it, you probably would have found some insight into selecting *good* frameworks, and when/where to use them. For those of us who don't have all the time in the world to write every layer of every application we need to create, frameworks are a necessity.

Re:Not just little devices

[Da VinMan]

Actually, instead of quitting, why don't you posse up a bunch of experienced developers let them have a chat with your organization's management? It's obvious to me that your lead developer is abusing his authority and using the project to do esoteric R&D style development when he should be busy putting together applications.

There are a handful of people in the world who are actually are capable of coding a secure web server and, no offense, but I doubt they work for your employer.

Good luck!

Re:Not just little devices

[Capt_Troy]

You're right, they don't work here. Problem is that our owner is ego is the size of Australia and he believes the "golden one" is the only true programmer left in the world. Any discussion on this topic results in a timely pink slip and 1 weeks pay.

Oh well. Good idea though, it might work were rationality is practiced! :)

Thanks!

Re:Not just little devices

[Anonymous Coward]

Well said!

Have you noticed that the existing
frameworks aren't really "open" or
"extensible"?

Any routine that is virtual, is asking
to be broken, the next release...

Notice how all the string classes everybody
provides are "closed"? That is, you can't
derive a new class from it. That's so the vendor
(Sun, Microsoft, etc) won't be responsible
for breaking ppls code, with the next release...

And if there is a microsoft dll hell, and
a Sun JVM hell, you can image what hell's
will be exposed with those frameworks over
time...

anybody with substantial experience with
projects over 100K source code lines, has
experienced lock-in to a previous version
of 3rd party products. Heck, we've all
experienced nothing working with the
"latest and greatest" simply because the
directories/header files/name spaces
are suddenly different...

Frameworks are for wimps

[Anonymous Coward]

Coming from the Perl world, I've seen too many religious wars over Mason vs. Template Toolkit vs. MVC to take framework debates seriously. You probably don't need a framework, anyway. You just need some reusable code for the more mundane functions (db connections, parameter processing, etc.) The rest is just programming.

Re:Frameworks are for wimps

[butane_bob2003]

In the Perl world, code re-use means 'global function call'. MVC is a Design Pattern, and is more a way of doing things than a framework. There may be a CPAN module called MVC that provides... a bunch of global function calls. Template Toolkit sounds something like my last experience with Perl and the idea of 'templates' in that world. In the Perl world it appeared that a template was a file that you should copy and paste/rename to provide some default functionality for a type of object (object and type having no real meaning here). I was speechless. This is probably not how ALL Perl programmers do things, or I hope not anyway. I'm sure Mason and Template Tookit have their merits, just as Struts does on the Java/JSP side of things. I'm also sure that I would use any of them until I had a good idea of what they are capable of and what limitations they might impose.

Why not write your own Framework?-Portals.

[Anonymous Coward]

That depends. What you described is a basic portal, of which there are plenty in all kinds of languages.

Easier to download a premade one and modify that.
Usually you only have to edit a file or two.

Why not write your own Framework?-OSS Perils.

[Anonymous Coward]

"You'll hear people argue that using an open source framework (and most are) will allow you to modify the code, but once you down the path of making changes, forget about upgrading as new versions are released..."

And how's that argument any different for using the Linux kernel? Or any other Open Source software for that matter? Reality and your argument don't agree.

Re:Why not write your own Framework?-OSS Perils.

[cjustus]

I see where this is leading... Just to nip it in the bud...

I'm not saying the OSS are bad... I'm saying that when a system allows for a user to make changes, and I choose to take advantage of that (as an end user), that I am leaving the path of upgrades, and commiting to sticking with that version for the foresee-able future...

If I go an modify low-level (non-module) linux source code, in a particular distribution of Linux, do not submit by code changes back, then if I want to upgrade to the latest and greatest kernel, it's going to be non-trivial... Check out the struts site... Great, stable, framework... I use it, but find I need to make changes to 1.1 ... Now 2.0 is on the roadmap, and when it comes out, migration will be non-trivial for those that take advantage of internal code, modify the internals, etc... and migration may still be non-trivial even if I haven't made changes...

My point is that choosing to use a public framework, you must consider the path that the code is moving in... In the case of an apache project, it's going to be well-managed, well-defined, and as an open source solution, will be available for all to discuss / contribute...

framework, insfrastructure and other buzz words

[GillBates0]

Somehow, whenever I see a book (or review thereof) with a lot of words like infrastructure, framework,case study, component, in-house,my buzz-word radar goes up. I have given up reading many a book lately, just because I hate the wordiness that goes in to describing the concepts/theory.

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.

Re:framework, insfrastructure and other buzz words

[devonbowen]

Whatever happened to the concise, well-written, to the point books of a few years ago. Kernigan/Ritchie's C book comes to mind

Amen, brother. I spend as much time sifting through useless books as I do reading useful ones these days. K&R was wonderfully direct. Even the nutshell books aren't that direct anymore.

Devon

language bigotry ahead

[Valar]

Life is busy enough without writing your own infrastructure code.

No, life is busy enough without having to learn anything else about java, ever, thanks.

Halfway kidding.

Hard to keep track

[Timesprout]

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.

Re:Hard to keep track

[Capt_Troy]

I agree totally. The java market is littered with frameworks with cool names, but they are all generally overkill that cost a lot of money. You need something to do A, and the product does A, B, C, D, E and a little bit of F. Well, are you going to pay for that, or roll your own to do A and be done with it.

Aside from the app server, we never used all these fancy frameworks.

Re:Hard to keep track

[Paradise Pete]

You need something to do A, and the product does A, B, C, D, E and a little bit of F. Well, are you going to pay for that, or roll your own to do A and be done with it.

Well personally, even when I'm just looking for A or B I could always use a little bit more F.

Not just little devices-Dark Ages.

[Anonymous Coward]

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.

Re:Not just little devices-Dark Ages.

[Waffle Iron]

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.

A standard fastener like a bolt has probably less than a dozen parameters to worry about. Things like length, thread pitch, diameter, head shape, alloy strength, etc.

If instead, each standard bolt was like a software component and had an API with thousands of parameters to worry about, you can bet that the architects would consider having simpler custom designed bolts machined for each project that match the unique requirements of that job.

Not Perl

[jonathan_ingram]

Bittorrent is written in Python. This means that if you download the source code, you'll actually be able to read it -- Python code can be understood by more than the person who originally wrote it.

Re:Not Perl

[Brians256]

Oops. Sorry about the Perl vs. Python mixup.

However... is the number of serious programmers who prefer Python larger than the number of serious programmers who prefer C/C++? By serious, I mean the number of people who would contribute meaningful improvements.

I'm not trying to flame python programmers here. But there seems to be a LOT more C and C++ programmers than Python programmers. After all, most of the software I see on the internet is written in C. BitTorrent is an exception rather than the norm.

Re:Not Perl

[magnum3065]

Well, Python is relatively new, so it has not gotten as widespread of use due to people having more experience with C/C++. Also, Python requires some changes in the way you think about programming. For example C/C++ programmers are used to strong type checking where the compiler tells you if you try to pass an incorrect type to a function. In Python types aren't really important. You write your functions and assume that the parameters given will support the necessary operations, but if they don't you'll just have to catch the exception. As I haven't gotten to really learning Python myself yet, I can't explain this very well, but while it seems strange it works fairly well.

Python use is growing though. Redhat is using it for many of their configuration panels and their package updating programs which you can check out in Fedora. Debian's "reportbug" program uses it. It's also becoming popular for embedding scriptability in programs.

There's also a good article at Gamasutra(registration required) about how kid-oriented adventure game developer Humongous is using Python for their games.

Re:Not Perl

[Letch]

Python code can be understood by more than the person who originally wrote it.

Bollocks Bollocks Bollocks. As someone who has recently started working with a large code base in Python, I can assure you it is possible to write unreadable code in python.

Having Readable code depends entreily on the programmer who wrote the code and very little on the language they use.

Standard frameworks not always the answer...

[Anonymous Coward]

Because you've got to spend a lot of time learning them. We looked at a bunch of frameworks (Avalon, Klim, and some others) and felt the amount of time needed to learn the framework was about the time it would take us to implement our own (we didn't need many features, just component loading and common db and log access).

So we rolled our own. Since java has interfaces, built in rpc, threading, and db-independant DB accesss, and most IDEs support some refactoring, it was pretty easy. Except for that classloader stuff. Ugh.

You probably disagree. Flame away!

-- ac at work

One man's framework is another's prison

[kpharmer]

Traditional frameworks are fine - but the productivity benefits come at a cost - flexibility.

What I've found that often works far better is:

- divide system into major business-oriented (vertical) sub-systems (assemblies, whatever). Examples of these sub-sytems would include 'party', 'inventory', 'order', etc.

- if possible build these sub-systems using highly adaptable code or based upon well-conceived patterns

- glue the assembles together using a highly productive / adaptable language - python, etc.

If I end up using a framework within one of these classic sub-systems, fine. I can always chuck it out the window when we hit its limits...

Growing up is hard to do.

[Anonymous Coward]

Yes there's a bit of corporatespeak in the mix, but CS is growing up. And like all things that growup, it becomes more "complicated". The language is naturally going to evolve to accomodate this growth.

Low Level Java

[jetkust]

With all of the high-quality frameworks available today, it's no longer necessary to even think about writing low-level code.

And all this time i've been writing all my bytecode with a hex editor, like a sucker.

Re:Low Level Java

[pmz]

it's no longer necessary to even think about writing low-level code.

Well, what's even funnier is that this is pretty much the exact same thing people said about Fortran and, then, C.

When people say things like "finally you don't need to write low level code," they are really advertising how ignorant they are about software engineering and history.

Re:Low Level Java

[Anonymous Coward]

You sound like alot like this old mainframer I used to work with. He used to go on and on and on about how "in the old days it was faster to edit the object code on the mainframe than to modify the punch codes, reload the punch cards, and compile".

Wait a minute. Bob... is that you??

Re:Low Level Java

[Qui-Gon]

I can't stand hearing people say this as well...

Inspite of all these great frameworks that are poping up everywhere... You still need to understand how the code works inorder to utilize it properly.

Re:Low Level Java

[pmz]

You still need to understand how the code works inorder to utilize it properly.

And to debug bugs in the inconveniently-opaque-yet-it-felt-so-right framework.

Yeah Frameworks are Great

[Greyfox]

Until you have to do something that the framework assumes you weren't going to do. Something like... adding a netscape-specific form tag element to your struts form to prevent the Netscape password manager from popping up. Then you can fight your way through 5 levels of management buerocracy in order to implement a new tag library just to keep your QA people and your users from getting confused. In other words, what should be a simple one-line change in a text file becomes essentially impossible.

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.

Re:Yeah Frameworks are Great

[blamanj]

Amen, brother.

While I don't quite agree with If your web-app is so complex as to need a framework, your web-app probably sucks, since even a simple bank-balance application can benefit from a good framework.

However, I'm afraid that the backlash may take much longer to arrive (and we'll be stuck coding in the ghastly web-app universe for aome time). The reason is that kludge after kludge will be layered on top of the browser (Sparkle, anyone) as an attempt to "get by".

Re:Yeah Frameworks are Great

[nate1138]

Kay, couple of nits to pick here. First off, I think you meant HTTP protocol, not HTML. HTTP is perfect for what it was designed for. That is shuttling documents back and forth to between clients and a server. It is very simple to understand and implement.

Second, what's wrong with Javascript? It is very useful in a web app. Field validation, UI enhancement, etc.

Third, I think you are ignoring all of the benefits of deploying a web app VS a standalone application. Such as support (much simpler IMHO). It also helps to negate the massive variations in computer hardware/OS that is out there. If I deploy as a web app, and I am careful about coding standards, that app works the same for a Mac, Windows, or Linux system. Lastly, there is nothing to install. Many users freak out whenever they have to install anything at all on their system.

You have some valid points about the difficulty of deploying such an app, and the workarounds that are necessary, but in the end, I think it is worth it.

Re:Yeah Frameworks are Great

[Anonymous Coward]

"Second, what's wrong with Javascript?"

Yea, they pop up ads really well, move windows randomly around... and turn off REAL easily in most browsers! Nuttin' wrong there.

Re:Yeah Frameworks are Great

[Greyfox]

Yeah I meant HTTP, my bad.

JavaScript would be great if you could count on it being implemented correctly on every browser. That goes for a lot of browser features. Browsers were never intended for the UI work they're not being used for. If I have to implement a heaping helping of UI code in JavaScript, why not just go back to C and do it using a protocol where I can actually maintain the state of my application from moment to moment?

I am not ignoring all the benefits of deploying a web app Vs. a standalone application. I've done both. Both require careful planning to implement correctly. Both can be guaranteed not to work the same or correctly on every user's machine. Both will require the same level of support questions and both will require you to tell some users that their platform is not supported. Or do you intend to go around supporting those Netscape 4.79 (or Lynx) users forever? Most people who actually deploy web apps are going in that direction now -- my bank's web app refuses to run except on IE 6 or AOL's version of Netscape (Though it works perfetly in Galeon if I tell Galeon to lie about what it is.)

In the end, all I see webapps saving you is having to install some code on the end user's system, and I personally have never run across a user who had a problem doing that. In fact, most of the users I run across have installed so much crapware on their systems that the poor machines run at 1/3rd the speed they're capable of and are more obnoxious than television commercials whenever you try to do anything on the web. If anything, users are too eager to install stuff on their system.

In my opinion, kludging HTTP to deal with an increasingly complex set of things it wasn't designed to do is not worth it.

Re:Yeah Frameworks are Great

[rob2lehigh]

A very good point. I just want to add one more advantage: data transfer. It is a heck of a lot easier in a lot of cases to deploy an app on a pre-existing web server and have users go to a web page than try to fight your way through a corporate IT department to get ports opened up for a custom app, especially now that everyone is afraid of RPC.

Re:Yeah Frameworks are Great

[nate1138]

Yeah, the javascript support situation blows ass. So does CSS support *cough*IE!!*cough*. And it is true that you will have to set limits on what browsers people can use, but I still think it is easier to deal with the support with a web app. For one thing, all the logs are right in front of me. It's really easy to grep the access logs for the users login name and get any errors associated with them. For another thing, webapps only have to worry about a handful of browsers that matter (IE, Safari, Moz, Konq, Opera), and not the hellishly different evironments you can find on systems in the field.

Both types of apps have their place, we'll just have to agree to disagree ;-)

Re:Yeah Frameworks are Great

[j3110]

We are talking about Java here. I could just use web-start. It's quite nice.

I spent 1 month looking at all the enterprise level technologies out there (You know... anything with distributed transactions, RMI of some sort, and security infrastructure). I spent 3 months learning J2EE. I spent 3 months looking at different frameworks. I eventually decided to go Web-Start. I really really wished there were books that compare the technologies out there based on performance, popularity (increases the number of jobs you can work at and the number of employees you can pick from), and time to completion (ease of use). Java almost has too much choice.

Here are some questions that should make my point.

How do you want to access your data?
JDBC, JDO, Hibernate, CMP, or some weird object-database?

What reporting package do you want to use?
Custom (using iText, FOP, or just plain AWT to the printer?)
JasperReports
JFreeReports
or one of the plethora of commercial packages?

What kind of client do you want?
HTTP, Web-Start, Standalone, or SOAP to Mozilla or .Net or Perl or etc. ?

If you go HTTP, what web framework do you want to use?
JSP/Servlets directly, Struts, WebWork, or some conjured up Velocity template?

If you go Web-Start or Standalon, what GUI TK do you want to use?
SWT, Swing, Thinlet, Luxor, Swixml, AWT (for 1.1 compatibility), etc.

Do you want MiddleWare? What kind?
Session Beans, Message Beans, Message queue's and some custom apps... with or without SOAP? Would you like a nice XML-RPC to go with that? Maybe you want something a bit more network centered like Jini? Maybe you have to work with some old CORBA software.

Oh, BTW, what operating system do you want to run it on? (Linux, Mac, BSD, Unix) What application server? (JBoss, Jonas, Pramati, WebSphere, WebLogic, SunONE, JRun, Resin) What database server? (MySQL, PostgreSQL, Oracle, DB2, McKoi, Hypersonic, Firebird, MS SQL) What JVM? (SUN, IBM, JRocket) Do you need charting for your reports? (JFreeCharts, bah... just search google for java charting)

My head hurts now, and I want to cry. When someone ends the madness, please wake me up and tell me what year it is, and which packages I should use, because if I look at them all, by the time I'm done, I'll have to start all over.

Re:Yeah Frameworks are Great

[Anonymous Coward]

Repeat after me....
"Write once, run anywhere."

JoeR
BTW where the heck is a TFTP library for java?

Re:Yeah Frameworks are Great

[j3110]

Jakarta commons has a TFTP client. There are also TFTP servers out there too.

http://jakarta.apache.org/commons/net/apidocs/in de x.html

Is the documentation.

A peice of advice for anyone that can't find an API that does what they want in Java: Go to jakarta.apache.org. Anything you can think of is there, and it's under the Apache License so you can use it anyhow you want.

Anyone who wants to do full text indexing should try Lucene. It's faster than any other indexer (I've tried them all, even the C coded ones) and it has no false positives. Lucene does more than indexing text too, so check it out if you ever need a library to handle indexing and searching.

turbine

[Leonig Mig]

has anyone tried turbine? i'm just getting the hang of it, as it seems like a more coherent and quicker way of getting going than struts? i quite like it now, wondering if anyone had any reservations who has had an experience with it.

thanks.

Re:turbine

[bmj]

i'm working on a turbine based project right now. the framework has some good concepts (services, user management, security), but the project organization is seriously lacking discipline. things don't always work as advertised, and if you're building a large-scale app, be prepared to dig into the turbine source and do some hacking.

there's also an issue with turbine 2.3's (latest/greatest) choice of build systems. you are required to use maven, a project management tool built on top of ant, and that project is often shakey at best (the product hasn't even hit a 1.0 release, but it's turbine's official build tool). at least turbine 2.2 allows you to use ant.

that said, it's not a bad framework, but you've got to be willing to take the good with the bad. the company's original developers chose it because of the user management features, and we've just stuck with it because we don't have the time to attempt a struts implementation.

Re:turbine

[keester]

Ask this on the turbine mailing list. Or better yet, RTFM!

Sample chapter

[akuzi]

You can read the first chapter here.

Unfortunately, like the 'review' - it doesn't mention which frameworks the book covers though.

Application frameworks vs webapp frameworks

[smagoun]

There are plenty of webapp frameworks out there, but are they really the right way to write an app? Picking a technology (like servlets) and then writing an application based on that technology - or based on a framework that wraps that tech - is fundamentally broken for many apps.*

The problem is that technologies change over time. Tech-oriented frameworks make writing the app easier in the short run, but they don't consider the long-term life of the app. Applications that are tightly coupled to any given tech become a liability as that tech ages, and quite often migration to a new tech involves a ground-up rewrite of the application. Instead of tying the app to a framework like Struts or a tech like EJB, write the app to stand on its own, using interfaces to the various techs it needs. Particular technologies like Struts (for a web UI) or EJB (for persistence) can be swapped in + out of the application as necessary without changing the function of the application itself.

There are a number of benefits to a technology-agnostic approach like this. The technology implementations can be upgraded: find out that EJB is a dud? Switch to Hibernate! Perhaps more interestingly, the technology implementations can be supplemented: Have a web UI, but need to ship a desktop application too? Plug in the desktop app tech implementation and presto! You now have both a web UI and a Swing/SWT/etc UI for the same app. Testing becomes far easier too, because you have clearly defined boundaries between the different components of the app (so it's easy to figure out which part isn't behaving).

There are drawbacks, of course. To work as advertised you need to invest a fair amount of architecture to get such a system off the ground. Someone has to write the tech implementations, as well - an SWT UI for your app won't just fall out of the sky when you want it.

Everyone has their pet project. Mine is Sandboss, an approach to enterprise application development that's application-centric, not technology centric. It concentrates on the app itself - you don't wind up with a "Struts application" or an "EJB app". Instead you wind up with an application that can use Struts and EJB, but can also work with Hibernate and WebWork. It's not for everyone - it requires a fair amount of committment to the methodology - but it works well in practice. The time savings are pretty incredible, and the components really are reusable.

*There are many places where a front end for a database is all you need. Of course, once the requirements for that project start to grow you'll wish you had something more powerful.

Re:Application frameworks vs webapp frameworks

[ChannelX]

Just a nit to pick: Hibernate != EJB. Hibernate is only a replacement for CMP.

Re:Application frameworks vs webapp frameworks

[Anonymous Coward]

Yah, I know. I was playing a little fast + loose with the terms there. I've seen entire apps (business logic + all) stuffed into EJBs, and I've also seen them used strictly for persistence. Hibernate obviously only covers the latter case. Thanks for pointing it out, I hope I didn't confuse anyone.

Re:Application frameworks vs webapp frameworks

[Anonymous Coward]

You could have saved yourself a considerable amount of typing by simply stating, "write to interfaces, not implementations". Of course, most of the Java programmers I've worked with don't understand the difference and view interfaces as extra, unnecessary code that just takes additional time to write.

Re:Application frameworks vs webapp frameworks

[mjglobal]

What your describing sounds a bit like a project I'm involved with, Keel, a "meta-framework" for lack of a better term. Application-logic oriented, framework independant, switchable implementations (we just added an implementation to use Hibernate for one choice as persistence, for example). Quickly looking at the sandbox.org site, it sounds like there might be a lot of synergy between the two. Feel free to drop me an email directly if you want to kick that thought around a bit... Mike

So which Framework won?

[iion_tichy]

Just curious...

Personally I prefer the Framework provided by J2EE. It seems most frameworks just add a redundant layer on top of that, repeating the same functionality.

It's been a while that I took a look at Struts, but what's the main advantage of a Struts Action over a Java Servlet? I think they are actually both meant to do the same thing. As far as I remember, the Struts Actions even get the HttpServletRequest passed as a parameter.

Re:So which Framework won?

[keester]

I'm overwhelmed by your in-depth analysis of the differences between J2EE and Struts. I think there might be a little more to it, though. Consider rechecking your sources.

Re:So which Framework won?

[iion_tichy]

I'm overwhelmed by the depth argumentation. Anything else you might provide in favour of Struts? I just checked the Struts User Guid, but couldn't find anything that made me want to read further. So what's the advantage of using a Struts configuration File rather than web.xml?

Re:So which Framework won?

[keester]

So what's the advantage of using a Struts configuration File rather than web.xml?

I think none, and I'm quite sure it won't work -- you human paraquat!

Re:So which Framework won?

[easter1916]

From minimal exposure to STRUTS, decoupling of navigation logic from JSPs and Servlets, plenty of basic field validation / error message handling goodies, basic enforcement of MVC (of course, you can break that). Not a STRUTS expert though, so if I'm wrong don't be surprised.

frameworks rule

[BigGerman]

I am currently involved with major Java project at big big government agency.
Every new body on the team gets to sit and read the Struts book - it takes govnt weeks to get you a PC and months to hook it up.
But the application they eventually get to work on is a terrible mess of logic-laden JSPs, clueless beans and stored procedures doing String manipulation.

So many genius programmers here at slashdot

[persson]

I am shocked to discover how many truly brilliant programmers there are posting today. I had not idea that it was so easy to write a homegrown framework. It sounds like there are many people who can, at the beginning of a project (with a perfect idea of the requirements and need for future application growth), in a night or a week, code up a high performance bug free foundation upon which they can base their project! Their team members (do such genius programmers even need to work with other people?) must be so happy to have people like this around.

I guess I should give up programming now since I apparently have to compete with such amazing skills. I am still stuck dealing with unrealistic deadlines, shifting requirements, existing systems, temmates with different skill sets, etc.

Maybe if I go back to school, or meditate to find my inner programmer I can learn to right beautiful code which scales well and also extends nicely without the pesky problems of new bugs, regression bugs, the need to refactor, extend, etc. on my first try.

Until then I guess I will just struggle along trying to learn from the experience of others, reuse solutions which are known by a large number of people and are recognized by employers and perrs. For us mere mortals it would seem these frameworks are a necessary evil.

-E

p.s. When are the afore mentioned geniuses going to extoll the virtues of writing your own operating system, text editors and media players? It must be really nice to not have to deal with the complexities and unexpected behaviors of such complicated systems when you can just roll your own! In fact, why should we even bother with web browsers and servers when we can just go the pure path with custom client applications and servers for every conveyor of data on the internet?

Not To Be Offensive, But...

[DoctorScooby]

Slashdot needs a new Java icon. The one they have seems to be a cup of coffee with a piece of poop floating in it -- which, come to think of it, may actually be an accurate depiction of Java. Hmmm... forget I said anything. The icon is fine as it is.

If it doesn't include Open for Business

[almax]

If it doesn't include Open for Business it is already out of date and missing the best piece of code going. The problem with the open source community today is that we don't mind using a few tools like Linux, Apache, etc. but when it comes to doing something that really would make business applications less expensive and of higher quality - like agree to standardize of a select few frameworks - we don't!

Which frameworks are covered

[mjglobal]

The book covers Java frameworks, primarily web-application frameworks, and discusses how to compare in general, and goes into detail on:

Avalon, Cocoon, Expresso, Arch4j,
ArsDigita ACSJ, Turbine,
Wakesoft Architecture Server, Niggle
Systinet's WASP, realMethods, Brazil
OpenSymphony,
JSF (not quite a framework per se, but covered),
Struts, Maverick, Scope, WebMacro,
Velocity, Tapestry, Barracuda, HyperQbs,
Tea, Freemarker, Echo, Xerces, Xalan,
Axis, Slide, Roaming Wireless Framework,
JADE, Openadaptor, JUnit, Anteater,
Jetspeed, OpenPortal, uPortal, Simper,
Object/Relational Bridge, Castor,
jRelational, Batik and Keel,
along with mentioning more briefly a lot of others.

(disclosure: I'm the author - of the book, not the review - so opinions may be biased :-)

Mike

Re:Which frameworks are covered

[blamanj]

Thanks, it would have been nice to see that list in the review.

I'm curious though, why you lump everything together under the word 'framework.' To me, framework implies a particular programming model that must be maintained. So JUnit is indeed a framework, though it doesn't at all compare directly with Struts, a framework with a completely different purpose. When I looked at the table of contents, I expected to see some sort of classification scheme.

And things like Xerces I wouldn't class as a framework at all, more an API.

Re:Which frameworks are covered

[mjglobal]

You're quite right that "framework" is a broad (and sometimes misused) term. I go into that in some detail in the book, and the frameworks reviewed are divided up by category to make it clearer (e.g. whole-application frameworks, persistence frameworks, presentation/UI framworks, etc)

I thought Xerces was just a tool/API as well at first, but with bit of digging I found it actually is more of a framework, with pluggable implementations, a component structure, several different APIs, etc. That's why I thought it made an interesting example on the "border" of what a framework is.

Mike

Re:Which frameworks are covered

[Miqlo]

I too would propose that the term "Framework" pertains to a programming model rather than a toolkit assemblage.

I too would have liked to see a structure built around the different specializations that framworks have been built to address... well, ordered the book anyway :)

As other pet projects have been mentioned here, I submit also mine as an example of a specialized framework, Millstone (www.millstone.org), don't know if it perhaps got mention in the book under the "along with mentioning more briefly a lot of others." -heading ;) (Thanks to parent for the listing!).

Miq

Pasta Sauce Analogy ( and opinion - obviously )

[easyCoder]

Pasta

When I cook pasta, and I am in a hurry, or I don't care if it tastes a little different to how I want it to, I buy a jar of premade pasta sauce.

When I am cooking for a special occasion, I wouldn't even dream of it. I know how to make a killer sauce, so I can make my own from scratch. The taste is always tailored to the occasion when I do so. The only other consideration is that it takes longer.

Curry

On the other hand, I do not know how to make curry from scratch. Thus, no matter what the situation calls for, I must use the premade pastes that come in the jars. However, I have become good at choosing which jar to use for a particular theme, and how to add various ingredients to push the flavour this way and that. It's not perfect, but most of the time it's quite good.

Choice

If you know how to roll your own killer data persistence layer, and you think that for a particular case it is warranted, then why not do it ?

However, if you don't know how to do it, or you need to save time ( other reasons can apply ) or you know that this particular library is just right for the job, then why not use an existing framework ?

I think it's silly to get religious on an issue like choosing the ingredients. It depends on the skill of the developers and the situation they are designing/developing for.

bad review

[linuxislandsucks]

I am sorry but a comparison of frameworks with very rushed case studies means a bad book on frameworks..

Here's a new one

[Anonymous Coward]

WUI or (Web User Interface) is a component based framework for developing complex web user interfaces using a single language: Java. Write web apps with widgets and events, not JSPs. Runs in any servlet 2.3 container. Alternative to Model 2/Struts.

http://sourceforge.net/project/showfiles.php?group _id=89760

unzip, ant -f run.xml, browse port 8080 and you're on your way...

more reviews of this book

[Anonymous Coward]

VeryGeekyBooks has more reviews of this book.

General Frameworks Often Suck

[tjstork]

The problem with general frameworks is that they are often too general. The wave of the future is going to be business specific application / database servers that are stitched together with open messaging schemes.

So, instead of having one general framework with a middle tier in some webish / code combination talking to a SQL server, you'll have a messaging bus that stitches together various domain specific database servers.

JBanana

[Anjo_Malvado]

Everyone should take a look at: http://www.jbanana.org Java Framework better then struts.

stuff

[p-unit*or*die]

i dont like to read. at all. i dont like this site either. at all.