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

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.

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.

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

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.

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?

[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

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?

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

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

[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: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!

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.

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

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

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.

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.

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

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

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

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

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

[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

[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

[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:No more low-level code?

[Krach42]

Some poor guy in India.

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.

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

[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

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