Develop Reference

When to use a web framework?

we need to code an online web journal management system in Java. It's not an Amazon, but also more than a Hello World.
Should we use a framework? If yes, why? What are some good Java Web frameworks out there that are simple?

Yes.
A Web framework should be used for all applications which are more complex than "Hello, World!". There's no need to reinvent the wheel. Web frameworks contain many useful tested components which you will almost certainly need on your site. They also help organize your code, often into an MVC or similar paradigm, which will make your code more maintainable.
Some Java Web Frameworks (in no particular order):
JavaServer Faces
Grails
Struts
Tapestry
Spring MVC
Apache Wicket
Play Framework
Stripes

Start developing without any framework and you will definitely notice yourself if you need one or not. Once more than half of your code is infrastructure for your web components, this can be a clue you should have chosen a framework rather than develop one yourself.
As a better example, use System.out.println() for logging, enhance that with some specialised package that also provides functionality like writing to a file, then add formatting to log messages and when you realise you spent half a year to develop your own poor home-made version of log4j (or whatever), someone will complain and say you should have chosen a logging framework from the very beginning and spend one or two weeks to learn how to use it.
Don't get me wrong, sometimes a mere System.out.println() wrapper is enough and a framework only adds overhead. Unfortunately, that scenario is a rarity these days...
EDIT: I am (or used to be) an anti-framework type of developer at the core so I've learned all the above "the hard way".
For a web framework suggestion: Apache Wicket

You should use a framework when you want to create something real and spend most of your time solving the problem at hand and not dealing with the underlying technology so much (e.g peristence, templating, infrastructure etc).
A good all around framework which provides tons of integration with other frameworks is Spring Framework.

A simple web framework is the play framework. Watch the screen cast on the playframework.org homepage. I am sure you will be convinced.

As #cherouvim mentioned, it's worth using a framework if you anticipate the need for "commodity technologies" like persistence, templating, routing, etc. That is, if you think your website will require non-trivial use of a database or complicated layouts and views (which are almost always present in a web application).
Check out Grails, it's based on the Spring framework but far easier to learn, manage, and use, in my opinion. Plus it's comparable to Ruby on Rails, which is another popular web application framework worth considering.

Stripes, Spring, Play (or ?) : which high performance Java framework to use?

We are beginning to build out a webapp which will probably see a lot of traffic. We dont have a lot of money, so we want to reduce hardware cost.
More or less, I think that means we will try to be as stateless as possible (as the Wicket way suggests - have bookmarkable URLs, etc. etc.)
The other problem is that we are gonna be hiring contractors (think oDesk or elance) for chunks of work - so there is the question of finding talent.
I have looked at Tapestry and seen a lot of API instability ( see: Why did you stop using Tapestry? ) which makes me reluctant to use it.
Seam and Wicket are highly stateful - not something I care for.
Grails looks to be very interesting. I know that there is a performance hit as compared to pure Java, but it might be worthwhile.
Stripes looks good, but I cant find examples of websites that have been built using Stripes
Which Java framework do you recommend for performance and simplicity ?

I would highly recommend Play! framework.
Java-based, Rails-like, easy to learn, highly productive, more and more real projects based on it, full stack, fast in coding and fast in production, active community...

The best performance is to be found with the action based frameworks (no paradigm mismatch as the component based frameworks have). My Shortlist would be Stripes first and Spring second.
Stripes Framework (Pro):
Fast
SEO friendly links
Elegant easy to understand code (1 thread per action).
Low learning curve, any Java web developer can quickly learn it.
100% open source, no chance of future license changes.
Focused and small integrates with any stack.
Stripes Framework (Against):
Less well known
Not full stack
Spring MVC (Pro):
Fast
SEO friendly links
Lots of developers have worked with Spring (but less with Spring MVC).
Full stack, part of Spring framework.
Spring MVC (Against):
Higher learning curve
More complex code: because beans need to be programmed tread safe, result is procedural code.
You might need to buy licenses from VM Ware in the future if you want to get all latest patches.
License terms can and have changed for future versions.
Full stack, you might get more than you need.

Spring-mvc with jsp's.
Spring is lightweight, everybody knows it, a lot of documentation for it and it's really simple to start developping if you use spring-mvc (specially if you use the mvc-annotations).
If you want some nice effects, you can combine it with JQuery (also for easy-AJAX).

Spring MVC and Stripes would be on my short list.
Both are light and easy and gives you more flexibility of the web application.
You might also considering looking at AJAX functionality; which parts of the pages could be simplified/smaller due to the usage of AJAX.

Check out the StripesFramework.org Stripes around the web page for a listing of websites built with Stripes. Some commerical sites include http://www.temprotect.com

Spring Roo (integrating Spring MVC) could be a good solution for you: this is pure java (easy to find freelancers), performant and easy to use with principles applied like Convention Over configuration;
Grails is also a good solution but you will need more hadware capabilities than Spring Roo and freelancers will be more difficult to find.

Is it possible to use a web framework but not be dependant on that framework?

I am investigating the use of web frameworks with my Java web-app. My basic requirements are pretty much easy maintainability, testability and no repetition.
I have explored writing my own MVC-type app using some sort of front controller pattern and JSP's for the views. The benefit of this is that I have complete control of all aspects of my web-app and if I design it properly it should not be hard to move it over to a more tested framework in the future if I so choose. However, the con is that I have to reinvent the wheel so to speak.
I hear good things about the currently available web frameworks. Some technologies that I have been looking at are Spring, Wicket, Struts, Guice, Hibernate and Tapestry.
I am a bit wary of Tapestry and Wicket. I dont know TOO much about them but they seem to deviate from the servlet->model jsp->view formula. I am not sure if I am comfortable with that. Although, I hear that Wicket is actually the best fit with Guice and is extremely testable.
Spring seems like it could be a nice fit, but I am very wary of frameworks which attempt to do everything. I would love to use spring-MVC, but can I swap in other components? Can I for example use Guice as my DI engine while using Spring-MVC as my framework?
I have briefly looked at Struts but it seems overly complex for my needs and again seems to be a complete package.
I've never used Hibernate, but it seems to be the standard for ORM and if it's anything like ActiveRecord (which I have only been exposed to a little bit) I am sure it fits my needs.
I also have never really used Guice but people really seem to like it, and I am a fan of DI in general even though I am not sure how it is used in an actual application.
Basically, I am only really confident with writing Servlets / JSP's. I am not opposed to learning alternate technologies but I am looking for advice as to which ones would REALLY benefit me.
If I can make an MVC app using Servlets and JSP's is it worth it to incorporate Spring? Or should I just use Servlets / JSP's and incorporate a DI engine like Guice?
I am pretty sure I would like to use Hibernate for ORM, but I hear it can be pretty complex. All I am really looking for is a way to map my POJO's to a database, so if there is something better/easier to use I am willing to look it up.
I am feeling lost and am looking for a bit of direction from people knowledgable in the area, any opinions on any of these issues would be hugely appreciated. Thanks!

"Spring seems like it could be a nice fit, but I am very wary of frameworks which attempt to do everything. I would love to use spring-MVC, but can I swap in other components? Can I for example use Guice as my DI engine while using Spring-MVC as my framework?"
Agreed Spring provides a lot of stuff, but it's totally modular. You can use DI with or without AOP and so forth. And yes you can use Spring MVC and Guice for DI together.
"I have briefly looked at Struts but it seems overly complex for my needs and again seems to be a complete package."
I have used Struts for quite some time now, but even when I started using it, I found it easy as a breeze. The controller might seem overwhelming at first, but you will have real fun when you get the hang of it. The best way would be taking a look at some real world examples using Struts.
"I've never used Hibernate, but it seems to be the standard for ORM and if it's anything like ActiveRecord (which I have only been exposed to a little bit) I am sure it fits my needs."
Oh then if you found Struts to tough, Hibernate is huge. It requires a big learning curve. It pays at the end, but if you know ActiveRecord, I will suggest you to stick to it before you get a good amount of knowledge of Hibernate.
"I am pretty sure I would like to use Hibernate for ORM, but I hear it can be pretty complex."
IMHO, very true...at least for beginners. (Anyone suggesting a change here?)
"If I can make an MVC app using Servlets and JSP's is it worth it to incorporate Spring?"
You mean without Struts or any other framework? How?
Seems like you are trying to take on too much too fast. Try considering one thing at a time. DI itself is a tricky thing to implement in real world. Oh yes conceptually it's great, but what I mean is you need to first get a hang of things one by one.

Very simply, if you are comfortable with JSPs and Servlets, then if you want to save some of the drudgery of web programming, I would look at Stripes or Struts 2.
I am very familiar with Stripes, and only am aware that Struts 2 is similar, so I will focus this entry on Stripes.
As an aside, Struts 1 is worthless. It offers no value (frankly).
Stripes has several features, but I will focus on only a few.
The primary value of Stripes, and if this were it's only feature it would still be very valuable, is its binding framework.
Binding is the process of converting the requests string values in to the actions values. Stripes does this amazingly well. Specifically, Stripes binding does very well on nested and indexed parameters, as well as type conversions. You can easily have a form field named "currentDate" and then have a "Date currentDate" in your Action, and Stripes will "do the right thing".
If you have a form field named "mainMap['bob'].listOfThings[3].customer.birthDate", Stripes will make the map, create the list, create the customer, convert the string to a date, populate the birthDate, put the customer in the 3 slot of the list, and put that list in the 'bob' spot of the map. (I do stuff like this all the time.)
The binding of requests to Action variables is just wonderful.
On top of that you get, if you use their form tags, you get nice behaviors when, for example, they put "Fred" in your date field. You easily get the form back, with Fred in the field, and a nice error message.
Finally, I really like their Resolutions as a result from their Actions. For example, a ForwardResolution to forward to a page, RedirectResolution to redirect to a page, StreamingResolution if you want to pump data down the socket, etc. It's a very elegant feature.
Stripes has all sorts of power and does all sorts of things, but those 3 pieces are what make it best for me, and what I use 99% of the time.
Simply, it really stays out of the way and readily handles the "plumbing" without completely obscuring the HTTP request nature of the system.
For someone who is content with JSP/Servlets, Stripes I think is an excellent step up as it adds good, solid value with very little cost (it's simple to set up) and without having to toss out everything you already know, since it works just great with JSPs and JSTL. Learn the simple mechanism it uses to map Actions to URLs, and how simple it is to map requests to your actions, and you'll be flying in no time.
Works great with Ajax and the like as well.

The question illustrates some confusion. I think the definitive answer is "no, it is not possible to use a web framework but not be dependent on it".
But your instinct is good. You want to maximize the general benefit a framework provides by helping to properly layer and modularize your code and minimize its invasiveness.
With that said, I think Spring is the winner on both counts.
If you follow the Spring idiom, the structure of your code will be better by the use of interfaces, layering, and aspects. Some of the attention they pay to design is bound to rub off on you. That's as helpful as the good plumbing code they provide.
Your code base does not have to be 100% Spring. I've seen Spring used in enhancements to legacy Java apps that weren't rewritten from front to back.
Struts tends to not be a good choice because it is JUST a web framework. It encourages you to put all your processing in Action subclasses, never to come out. Spring injects the idea of a service interface that decouples the web tier from the back end. It's easier to swap out web tiers and expose the service as SOAP, RMI, EJB, or remote HTTP call.
Hibernate is far more complex than Struts. If you choose Spring, use persistence interfaces and start with Spring JDBC. When you're ready for Hibernate, you can always write a new implementation and simply inject it into the place where your JDBC version used to be.

Selecting a good Framework for web-development

Based the accepted answer to this question I've setup a NetBeans/tomcat environment.
In testing this setup I'm trying to create a Java Web/Web application, but is stumped by the a choice of frameworks for this test-app.
The choices are:
Spring Web MVC 2.5
JavaServer Faces
Struts 1.3.8
Hibernate 3.2.5
In my reading-up (googling & SO) and fairly quickly got lost in the woods, so I am considering just picking one and if it doesn't pan out, to later switch/migrate to a different one. Would such an approach be feasible?
Background on the project
(Must be Java-based due to legacy code)
It uses a self-signed applet to do client-side rendering & interaction;
Servlets retrieve data-sets requested from the client;
Database may be on some remote server, so I intend to use JDBC for accessing it;
The legacy system was CORBA (ACE/TAO) based with lots of C++ modules that need to be translated to Java, and the existing Java-modules (fortunately few) that make CORBA-calls need to be changed to use the newly translated Java-modules.
If you can come up with better approach to handle this project, please tell me.
(This project has all the hallmarks of what I like: it is interesting, challenging, and I learn something new)

Well first of all it can't hurt to take a close look at the whole Spring Framework in general. The documentation is quite good starting at the very basic module working it's way up to the web MVC layer (where you can decide if you want to use it, e.g. Struts Integration is possible, too - but I found Struts always to be a hassle anyway). Hibernate is the probably most popular Object Relation Mapper framework. It is used to store, query and retrieve you Domain Model Objects (everything that you want to store in the database) but doesn't have anything to do with the web layer.
I personally don't like JSF (another specification monster that takes way more time to get into it than it needs to). If you favour a widget based approach (putting you page together with componentes instead of outputting plain old HTML) you might want to have a look at Google Web Toolkit.
Another Spring sollution is GRails. It is really fun to use and even if you have to learn another (scripting) language (called Groovy) you can still use all your Java legacy classe in the Framework because Groovy classes are compatible with Java classes (and vice versa).
And btw. I thought that CORBA is a technology / protocol / standard that especially allows you to access methods and objects independently of the language. Wikipedia:
The Common Object Request Broker
Architecture (CORBA) is a standard
defined by the Object Management Group
(OMG) that enables software components
written in multiple computer languages
and running on multiple computers to
work together, i.e. it supports
multiple platforms.
So why do you have to translate the C++ modules to talk to Java?

First of all, cross Hibernate off your list - while you'd be advised to use it if you've got an ORM requirement it's not related to the web-tier.
Then I think you've two choices:
Spring MVC and JSF
Struts
Heading down either route is going to commit you to that/those API(s) and a switch at a later date is never going to be painless.
My advice would be:
use Spring MVC - you'll likely be using Spring anyway and so it's a natural choice.
ignore JSF, write the HTML yourself, using JSTL to render beans.
use JQuery/JavaScript to enrich the user experience.
use Hibernate for object persistence.

I think it is a good idea to just pick up the minimum, and add as needed. Chances are that you gain simplicity that way.
An idea could be to start with Spring as your "grand scheme of things", and integration technology. Then add complements as needed:
persistence : Hibernate
javaScript : pick a js library that goes well with the Spring MVC module you're using

Practical Experience using Stripes?

I am coming from an Enterprise Java background which involves a fairly heavyweight software stack, and have recently discovered the
Stripes framework; my initial impression is that this seems to do a good job of minimising the unpleasant parts of building a web application in Java.
Has anyone used Stripes for a project that has gone live? And can you share your experiences from the project? Also, did you consider any other technologies and (if so) why did you chose Stripes?

We've been using Stripes for about 4 years now. Our stack is Stripes/EJB3/JPA.
Many use Stripes plus Stripernate as a single, full stack solution. We don't because we want our business logic within the EJB tier, so we simply rely on JPA Entities as combined Model and DTO.
Stripes does the binding to our Entities/DTO and we shove them back in to the EJB tier for work. For most of our CRUD stuff this is very thing and straightforward, making our 80% use case trivial to work with. Yet we have the flexibility to do whatever we want for the edge cases that always come up with complicate applications.
We have a very large base Action Bean which encapsulates the bulk of our CRUD operations that makes call backs in to the individual subclasses specific to the entities and forms.
We also have a large internal tag file library to manage our pages, security, navigation, tasks, etc. A simple CRUD edit form is little more than a list of field names, and we get all of the chrome and menus and access controls "for free".
The beauty of this is that we get to keep the HTTP request based metaphor that we like and we get to choose the individual parts of the system rather than use one fat stack. The Stripes layer is lean and mean, and never gets in our way.
We have a bunch of Ajax integrating YUI and JQuery, all working against our Stripes and EJB stack painlessly.
I also ported a lighter version of the stack to GAE for a sample project, basically having to do minor work to our EJB tier. So, the entire stack is very nimble and amicable to change. Stripes is a big factor of that since we let it do the few things that it does, and does very well. Then delegate the rest to other parts of the stack.
As always there are parts folks would rather have different at times, but Stripes would be the last part to go in our stack, frankly. It could be better at supporting the full HTTP verb set, but I'd rather fix Stripes to do that better than switch over to something else.

We use stripes now on all our production sites, and have been for about a year now. It is an awesome product compared to struts, which we used to use before that. Just the fact that there are literally no XML config files and that you can set it all up with a minimal amount of classes and annotations is awesome.
In terms of scaling & speed it actually seems to be better than struts, and my guess would be because there are less layers involved. The code you end up with is a lot cleaner as well, because you don't have to go off to seperate XML files to find out where redirects are going.
We use it with an EJB3 backend, and the two seem to work really well together, because you can use your EJB POJO inside your actionBean object, without needing a form object like in struts.
In our evaluation we considered an alpha version of struts (that supported annotations) and a lot of other frameworks, but stripes won because of it's superior documentation, stability and clean-ness.
Couldn't figure out how to leave a comment: so to answer your second question we haven't encountered a single bug in Stripes that I know of. This is quite impressive for an open source framework. I haven't tried the latest version (1.5) yet, but 1.4.x is very stable.

We converted a home-grown web framework to stripes in about a week. We're using it in production at this time and it's a great framework. The community is extremely helpful, and the framework doesn't get in your way. It can be extended in many places to change the behavior as you see fit. The url binding feature is awesome as well. We implemented a robust security framework using annotations and interceptors. We're using spring for dependency injection and stripes has excellent support for that.
I'd definitely use the new 1.5 release if you're going to use it.
I'm a huge fan of the framework. I came from a struts background and it's the exact framework I was looking for. The other developers on our team really enjoy using the stripes framework.
I just bought the stripes beta book from the pragmatic programmer's site. It's a great resource on Stripes 1.5.

We have now used Stripes in multiple production projects and so far the experience has been great. Setup time is low and the configuration management issues seem to be fewer. We have webapps running with Stripes/Dojo/Hibernate and others with a mix of Stripes/Spring/JSP/Jquery etc. Adding Stripes to our existing projects was fairly simple thanks to their support for integrating existing Spring configurations. Using Stripes with JSP is fun although sometimes you do feel the need to code in Java and not have to use the JSTL so much.
Note:
This is an old question, but given that it pops up pretty fast when you search for Stripes usage, I am adding a response to it.

I also came from a Struts and JSF background into Stripes. I went from a large enterprise environment that used mostly struts and JSF on newer projects, to a smaller environment that did all their J2EE in Stripes.
Seems like Stripes gives you what you want in a Web Framework without getting in the way too much. Not much configuration is necessary, as others have already mentioned. Very quick development and allows you to focus on presentation etc. instead of hassling with the framework.
If I had to start a fresh new project and I had my say, I would choose either Stripes or JSF. I might have been scared away from Stripes if I had to make the decision to switch to it, because it kind of looks/feels like a sourceforge basement project instead of a enterprise-grade framework, but it seems to be fairly solid. We use Stripernate for easy ORM.
However, it reminds me of Fruit Stripe gum, which lost its flavor WAY TOO FAST.

Stripes is yesterdays technology, if you can pick something a little more modern like GWT.