Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Java Frameworks and Components

timothy posted more than 10 years ago | from the tying-things-together dept.


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.


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?


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 Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×


Sorry! There are no comments related to the filter you selected.

No more low-level code ? Hum... (0, Insightful)

zeux (129034) | more than 10 years ago | (#7560048)

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... (3, Insightful)

wembley (81899) | more than 10 years ago | (#7560096)

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

Re:No more low-level code ? Hum... (1)

Brians256 (562930) | more than 10 years ago | (#7560274)

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... (2, Informative)

Elwood P Dowd (16933) | more than 10 years ago | (#7560118)

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... (4, Insightful)

captain_craptacular (580116) | more than 10 years ago | (#7560134)

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.

No more low-level code ? Hum...Servers. (0)

Anonymous Coward | more than 10 years ago | (#7560141)

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.

Re:No more low-level code ? Hum... (2, Insightful)

Brians256 (562930) | more than 10 years ago | (#7560177)

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

Not Perl (3, Informative)

jonathan_ingram (30440) | more than 10 years ago | (#7560404)

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 (1)

Brians256 (562930) | more than 10 years ago | (#7560570)

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 (1)

magnum3065 (410727) | more than 10 years ago | (#7561095)

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:No more low-level code ? Hum... (1)

magnum3065 (410727) | more than 10 years ago | (#7560784)

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

Brians256 (562930) | more than 10 years ago | (#7561148)

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.

Join us in Jihad (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7560201)

Tired of Slashdot's
subversive []
abuse by the editorial staff?

Bored with
mindless []
groupthink [] ?

Had enough with Slashdot's
unethical []
support for advertisers?

If so, we invite you to join the jihad against Slashdot at [] . We demand a full
acknowledgment and apology from the editorial staff for their crimes
against the community. Until then, we will take whatever action is
necessary to discredit Slashdot as a reputable geek news site.

Our tools:

  • Database Tool [] -
    A huge searchable database of old Score:4 and Score:5 posts ready for
    reposting. Gain karma at your will. Then, use your mod points and karma
    bonus to cause mayhem.

  • Browsing Tool [] -
    Browse Slashdot through our special tool to alert other brothers in Jihad
    to subversive posts worthy of moderation. Also integrates with the
    database tool for quick karma whoring.

  • Mail Tool [] - create
    fake email accounts for creating new Slashdot accounts for jihad
    operations with ease.

  • Bait and Switch Mirror []
    Tool - Use this to mirror a Slashdotted site. After a certain amount
    of time (to let the mods push it up to Score:5), it switches to displaying or your favorite disgusting image.

Join the jihad today!

Not just little devices (4, Insightful)

Oestergaard (3005) | more than 10 years ago | (#7560239)

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.

Not just little devices-Dark Ages. (1, Insightful)

Anonymous Coward | more than 10 years ago | (#7560392)

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. (4, Insightful)

Waffle Iron (339739) | more than 10 years ago | (#7560645)

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.

Re:Not just little devices (1)

IWorkForMorons (679120) | more than 10 years ago | (#7560518)

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 (1)

Capt_Troy (60831) | more than 10 years ago | (#7560819)

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 (1)

Saeger (456549) | more than 10 years ago | (#7561682)

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


who wants a body massage? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7560055)

body massage.

Re:who wants a body massage? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7560104)

Mmmm-mmmm-mmmm-mm-mmm-mmm, mmmm-mmmmmmm-mmm-m-mmm-mmm-mmm-mmm. Naw I'm just messin with ya kid. *FART*

Early post! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7560069)


Java sucks (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7560332)

So does The Who!

Jihad components (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7560070)

Tired of Slashdot's
subversive []
abuse by the editorial staff?

Bored with
mindless []
groupthink [] ?

Had enough with Slashdot's
unethical []
support for advertisers?

If so, we invite you to join the jihad against Slashdot at [] . We demand a full
acknowledgment and apology from the editorial staff for their crimes
against the community. Until then, we will take whatever action is
necessary to discredit Slashdot as a reputable geek news site.

Our tools:

  • Database Tool [] -
    A huge searchable database of old Score:4 and Score:5 posts ready for
    reposting. Gain karma at your will. Then, use your mod points and karma
    bonus to cause mayhem.

  • Browsing Tool [] -
    Browse Slashdot through our special tool to alert other brothers in Jihad
    to subversive posts worthy of moderation. Also integrates with the
    database tool for quick karma whoring.

  • Mail Tool [] - create
    fake email accounts for creating new Slashdot accounts for jihad
    operations with ease.

  • Bait and Switch Mirror []
    Tool - Use this to mirror a Slashdotted site. After a certain amount
    of time (to let the mods push it up to Score:5), it switches to displaying or your favorite disgusting image.

Join the jihad today!

Re:Jihad components (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7560556)

I'd like to join the jihad, but I'm not a camel jockey, sand-nigger, or a towel head.

Maybe you could call it a "crusade" instead?

fp (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7560077)


Re:fp (-1, Redundant)

happyfrogcow (708359) | more than 10 years ago | (#7560132)


Atleast have a little confidence in yourself. Openly announce your slashdot geekieness for all to see. Proclaim, "FP!" with all your lame might!

Case Studies (5, Insightful)

krulgar (250929) | more than 10 years ago | (#7560093)

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.

CPAN (-1)

Anonymous Coward | more than 10 years ago | (#7560107)

I have yet to see an organized repository for any language that contains even 20% of the code in CPAN. Who cares about the syntax, if you want to solve real problems you can't beat CPAN (although many lamely try).

aren't? (3, Interesting)

dance2die (596340) | more than 10 years ago | (#7560120)

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

if it's not firmly packed FUDge, it's just mud? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7560121),15114,548785 ,00.html?cnn=yes

geezers take it in the .asp, again, also?

mynuts won: don't even think about it/them?

Comin at cha (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7560137)

cha cha cha

FP in the hizzouse, byatch.

WTF is "infrastructure code"? (2, Interesting)

heironymouscoward (683461) | more than 10 years ago | (#7560142)

(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"? (4, Informative)

nehril (115874) | more than 10 years ago | (#7560486)

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"? (2)

pmz (462998) | more than 10 years ago | (#7561283)

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.

issue with java (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7560147)

The issue with java is that its multi-platform, but slow as a slow motion porn with double penetration. Sun needs to work on more efficient coding to make java take off. Just look at their operating system. Slower than a wigger pulling out of a 14 year old girl and getting her pregnant.

No more low-level code? (1, Funny)

duffbeer703 (177751) | more than 10 years ago | (#7560154)

Who writes the frameworks? HAL 9000? Nanomachines?

Re:No more low-level code? (1, Funny)

Anonymous Coward | more than 10 years ago | (#7560338)

Who writes the frameworks? HAL 9000?

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

Re:No more low-level code? (2, Insightful)

Krach42 (227798) | more than 10 years ago | (#7560753)

Some poor guy in India.

Who are you? (4, Interesting)

Sean80 (567340) | more than 10 years ago | (#7560156)

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? (0)

Anonymous Coward | more than 10 years ago | (#7560226)

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? (1)

Sean80 (567340) | more than 10 years ago | (#7560310)

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? (0, Flamebait)

Anonymous Coward | more than 10 years ago | (#7560294)

Simon P. Chappell
Java Programming Specialist
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?

Why not write your own Framework? (5, Interesting)

Guru1 (521726) | more than 10 years ago | (#7560164)

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? (1)

cjustus (601772) | more than 10 years ago | (#7560232)

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

Why not write your own Framework?-OSS Perils. (0)

Anonymous Coward | more than 10 years ago | (#7560315)

"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. (2, Interesting)

cjustus (601772) | more than 10 years ago | (#7560534)

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

Re:Why not write your own Framework? (-1)

Anonymous Coward | more than 10 years ago | (#7560351)

You have no clue about professional software development and have probably never utilized an open source framework. Pls STFU.

Why not write your own Framework?-Portals. (0)

Anonymous Coward | more than 10 years ago | (#7560255)

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.

Re:Why not write your own Framework? (1)

galacticdruid (569137) | more than 10 years ago | (#7560367)

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? (2, Interesting)

Anonymous Coward | more than 10 years ago | (#7560387)

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.

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? (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7560421)

Your group is full of idiots, sir. You rewrote a framework that was knowingly already written. If your developers mocked Struts in a week, then they took some severe shortcuts.

Re:Why not write your own Framework? (2, Informative)

scumbucket (680352) | more than 10 years ago | (#7560428)

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 -

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? (1)

spludge (99050) | more than 10 years ago | (#7560496)

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? (4, Interesting)

enjo13 (444114) | more than 10 years ago | (#7560558)

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? (1)

msuzio (3104) | more than 10 years ago | (#7560977)

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? (1)

pmz (462998) | more than 10 years ago | (#7561348)

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? (1)

sfjoe (470510) | more than 10 years ago | (#7561467)

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? (1)

msuzio (3104) | more than 10 years ago | (#7560567)

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? (1)

Baki (72515) | more than 10 years ago | (#7560680)

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.

So many genius programmers here at slashdot (0, Troll)

persson (691660) | more than 10 years ago | (#7561102)

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.


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?

Re:Why not write your own Framework? (3, Informative)

MSBob (307239) | more than 10 years ago | (#7561103)

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? (1)

fishbot (301821) | more than 10 years ago | (#7561316)

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.

Rolling my own... (1, Interesting)

Anonymous Coward | more than 10 years ago | (#7560207)

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... (1, Funny)

Anonymous Coward | more than 10 years ago | (#7560595)

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... (0)

Anonymous Coward | more than 10 years ago | (#7560902)

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

vmfedor (586158) | more than 10 years ago | (#7560732)

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

Did you actually read the book? (4, Insightful)

ViolentGreen (704134) | more than 10 years ago | (#7560217)

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

That being said. Java's frameworks tend to be very high quality and easy to work with in my experience.

Useless (5, Interesting)

blamanj (253811) | more than 10 years ago | (#7560228)

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 (1)

piobair (586119) | more than 10 years ago | (#7560302)

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

Re:Useless (0)

Anonymous Coward | more than 10 years ago | (#7561454)

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.

Frameworks are for wimps (0)

Anonymous Coward | more than 10 years ago | (#7560253)

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.

framework, insfrastructure and other buzz words (3, Insightful)

GillBates0 (664202) | more than 10 years ago | (#7560352)

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.

Growing up is hard to do. (0)

Anonymous Coward | more than 10 years ago | (#7560566)

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.

language bigotry ahead (0, Flamebait)

Valar (167606) | more than 10 years ago | (#7560366)

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 (4, Insightful)

Timesprout (579035) | more than 10 years ago | (#7560385)

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 (1)

Capt_Troy (60831) | more than 10 years ago | (#7560729)

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.

Standard frameworks not always the answer... (1, Interesting)

Anonymous Coward | more than 10 years ago | (#7560460)

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

Beautiful scene in Black Hawk Down (-1)

Anonymous Coward | more than 10 years ago | (#7560466)

I still get shivers going down my spine when I repeatedly watch hordes of blackies mowed down by our gunships in Black Hawk Down...

Mow down Tikrit already.

Mow down Baghdad already.

Show the ragheads that we mean business!

One man's framework is another's prison (1)

kpharmer (452893) | more than 10 years ago | (#7560467)

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

Low Level Java (5, Funny)

jetkust (596906) | more than 10 years ago | (#7560574)

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 (1)

pmz (462998) | more than 10 years ago | (#7561375)

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 (0)

Anonymous Coward | more than 10 years ago | (#7561598)

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

Yeah Frameworks are Great (2, Insightful)

Greyfox (87712) | more than 10 years ago | (#7560687)

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 (1)

blamanj (253811) | more than 10 years ago | (#7561006)

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 (2, Insightful)

nate1138 (325593) | more than 10 years ago | (#7561260)

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 (0)

Anonymous Coward | more than 10 years ago | (#7561422)

"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 (2, Insightful)

Greyfox (87712) | more than 10 years ago | (#7561484)

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 (1)

rob2lehigh (682737) | more than 10 years ago | (#7561573)

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.

turbine (2, Interesting)

Leonig Mig (695104) | more than 10 years ago | (#7560913)

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.


Re:turbine (1)

bmj (230572) | more than 10 years ago | (#7561564)

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 (1)

keester (646050) | more than 10 years ago | (#7561652)

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

Sample chapter (4, Informative)

akuzi (583164) | more than 10 years ago | (#7560957)

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 (5, Interesting)

smagoun (546733) | more than 10 years ago | (#7561026)

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 (1)

ChannelX (89676) | more than 10 years ago | (#7561623)

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

So which Framework won? (1)

iion_tichy (643234) | more than 10 years ago | (#7561035)

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.

frameworks rule (1)

BigGerman (541312) | more than 10 years ago | (#7561072)

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.

Not To Be Offensive, But... (0)

DoctorScooby (669432) | more than 10 years ago | (#7561326)

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 (1)

almax (604943) | more than 10 years ago | (#7561427)

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!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>