Related
I was wondering if someone who was experienced in both technologies could give an objective comparison between the two, assuming you were building a complex web application that would be both very rich in on the server and in the browser.
One problem with the older paradigm, for me, is testability of the Spring MVC layer. I find that there's a lot of bugs that can creep into your application due to untestable annotations. This model also slows development cycles because you have to restart the server to make changes to the annotations/controller code... which is something I personally find very annoying.
I also don't want to deal with the complexity of javascript. Working with and testing an application all in Java sounds appealing to me. I don't really want to master another language, and learn all of its quirks, weird design decisions, idiosyncracies and the full history of browser incompatibilities.
So for a complex application, would GWT offer a superior approach? Are there any serious limitations to this approach over Spring MVC, which would probably be more flexible although harder to work with? Are there any gotchas and road blocks that are common for building complex applications?
I would really appreciate a comparison between the two. Please keep in mind that I have no experience with GWT, but about 10+ years experience with Spring. Thank you!
The truth is that also GWT has a learning curve and also at least at the time I looked at it, two years ago, you're not doing much with the basic controls, you need external libraries and that means more learning.
After trying to learn GWT without much success, I opted for a webservice plus either jQuery or ExtJS, which also gives a very clean separation of the roles. I sat down and learnt JavaScript, it wasn't easy but it was immensely more fun than using GWT.
As for browser compatibility, once you use a modern library, you'll have very few of them. My code works in all browsers without too many problems, including IE 6. Also when I am too busy, I write the services only and outsource the JavaScript interface part, which allows increased productivity.
Anyway, this is fairly subjective, another person fluent with GWT, can have an opposite point of view of mine. I will anyway reject the following reasons:
ease of debugging. Not true anymore: it's very easy to debug JavaScript with FireBug, plus there won't be any business logic in JavaScript, only services call and display.
browser compatibility. There are very few quirks to remember, the most common one is that IE doesn't accept trailing commas in lists, which is anyway not in the standard, but Firefox tolerates them. Any modern JavaScript library will take care of compatibility for you.
Speed. To start with I will state that JavaScript is very fast for any reasonable computation within the browser. What is slower is DOM manipulation and of course anything involving the network, like AJAX calls. Your page will perform just right if you don't do design mistakes, like stuffing too many things or other problems that can arise when adding many elements directly to the DOM, instead of building your structure and then attaching it all at once.
As far as I can think now, the only valid reason is, I already know Java, I don't want to study another language.
As for your comment on Spring MVC. I am using Spring MVC and I don't feel the pain of restarting the server. The whole point of Spring is that everything should be easy to work with outside the container! In the Spring controllers I've very minimal code that just call the underlying services. What I need to unit test well are the services.
The controllers have very few code to test, I could just call them and test them within JUnit, but, at least for now, my approach is having a simple external test done through a web page with jQuery calls that check their response (it's not unit test, it's an integration test, but I feel there is a very little value to unit test a controller, if it's written properly).
I am using GWT for more than a year now in a complex project (200 KLOC for the whole project), and I recommend you to give GWT a try.
In my opinion GWT is quite easy to learn, there are really good tutorials about how one should use this technology.
The advantage of using GWT is that one can build nice, fast, maintainable web apps, without knowing very little about browsers or javascript. You can also debug your client side code with a Java debugger and in complex apps this is huge.
Although GWT offers the possibility to properly unit test the client side code, this requires a good understanding of GWT's MVP paradigm and careful planning. If you mess up your code (which is not that hard, because GWT gives you total freedom) then you are going to end up losing this feature, but this is your fault, not GWT's.
It took me a couple of months to learn Spring well enough to create fairly basice MVC apps. It took me about a month to master GWT. (It could be that it was easier because I had already worked with Android for three years and it works similar. It even has the exact same unobvious solutions to some of its problems.) So for me, GWT was definitely much easier to learn than Spring.
I'm a full time Java developer of around 4 years, professionally. I'm a GWT fanatic. I love Java. Here's the problem: In my free time I often fall victim to the verbosity of my favorite tools for doing "heavy" development. I also often fall into the trap of obsessively engineering my software. I'll end up with the most beautiful unfinished implementation, ever.
So, here's what I normally work with.
GWT - I use this for dynamic UI and web layout. I love the ease of re-use and it has taught me to absolutely hate javascript. I really can't even bring myself to do much HTML/JS anymore.
Hibernate - POJO to Database, easy-peasy. What i really need from this other than the mapping is that it allows me to have an application that works across multiple databases.
Spring - Mostly security. I've written my own custom LDAP bits for a project.
XML - I've used dom4j and other implementations, including xstreamer. I'd like to use JiBX for XML transport. The problem with this is that I need XML messages that conform to a specific standard rather than being autogenerated. Object->XML->Object are also common enough that it can be a performance bottleneck with large messages (250KB+).
I tried Lombok for a little while and liked it but had occasional issues with it and then I blew up a partition and lost all that work. I don't really feel like doing the same thing again (half the fun was in learning how to do it, now that I know... meh). This taught me why other people want to reduce the explicit code and replace it with an implicit system.
I've been looking into Grails but that runs me into the JavaScript problem (you know, that I don't like it) pretty quickly. I could use GWT with Grails on the back end but I get back into the problem of getting deep in the weeds with GWT. It has also occurred to me that there might be a way to have Grails tags in GSP that are made up of GWT widgets. I'm not really sure how I feel about that.
Another problem I have with Grails is that validation logic before form submission is separated from validation constraints after submission. I don't see how they can be unified (yet) to produce "pretty" front-end validation. I went out of my way to start a JSR-303 compliant validation project for GWT to help solve some of this problem for GWT and really liked the results. It isn't finished but I still find it useful.
So, help me find a better way!
TL;DR - I want to have a Database (and Database-Independent) to GUI solution that allows for dynamic web programming all in one language. Failing that, as close to one language as possible.
TL;DR is TL;DR - I hate JavaScript now, help.
EDIT: I know that it is techincally impossible to do "Web 2.0" development without JavaScript. I'm just trying to not be the guy who has to write it. (Getting a tool such as GWT to do it for me from a language I do like, for example.)
Just learn JavaScript.
Resistance is Futile
...and you will be assimilated.
PD: I'm an ex JavaScript enemy. Now it's my favourite language.
You can certainly develop an entire Web 2.0 project without coding Javascript using GWT (we have), but at the end of the day you still have to know HTML/CSS & Javascript.
This might sound like a stupid statement, but it's not once you consider that GWT is not a perfect abstraction, nor is it designed to be. It wasn't written in Java so that you didn't have to ever code in Javascript again, instead they did it because Java has better IDE's, is statically typed and makes maintenance a hell of a lot easier.
So yes, by all means go with GWT (and check out the new OOPHM, because it's AWESOME) but don't forget that you'll always need an understanding of the underlying frameworks of the web, if you want to develop for the web.
Have you heard of Echo?
It doesn't provide the database part of the problem, but it would work well with any database that you can work well with.
Echo is a platform for building
web-based applications that approach
the capabilities of rich clients. The
applications are developed using a
component-oriented and event-driven
API, eliminating the need to deal with
the "page-based" nature of browsers.
To the developer, Echo works just like
a user interface toolkit.
The latest iteration, Echo3, features
the ability to write applications in
either server-side Java or client-side
JavaScript. Server-side applications
run in any Java Servlet Container and
do not require developer knowledge of
HTML, HTTP, or JavaScript.
You might want to take a look at some of the AJAX powered JSF libraries. IceFaces and RichFaces are both solid.
Been there, done that. I was a GWT developer for 3 years... I started using it in v1.1! GWT is fantastic, and works really well for small applications. But the development comes to a crawl once you it a moderate application size, even if you divide your application in sub-modules.
It is also quite ironic that a UI framework has such limited UI creation tools. :)
Personally I bit the bullet and learned javascript. It isn't as bad as I thought. Especially with jQuery. :)
Obviously there is no perfect framework. But just the fact that GWT has been out for 3.5 years now, and it still largerly ignored in the Java world should tell you something. Since you're doing this on your free time, I would recommend learning the most popular framework: Struts. You'll see its limitation, and also why it is so popular. Of course, you'll need jQuery for that 2.0 functionalities. :)
Take a look at JRapid, a rapid development platform for Java developers. It generates very powerful Ajax enabled UI without the need of coding.
Not sure if you would like this , but have you heard about Haxe?
You might not like it but its AIO (all in one) solution (sort of).
I can understand your dislike of JavaScript and it certainly has its problems but I think your fighting nature at this point.
Web 2.0 is strongly based on JavaScript for a good reason as it provides the ability to perform tasks on the client machine without requiring page loads.
I'm sure there are alternatives but if you want the look and feel of Web 2.0, you will end up doing a lot more work with little reward. JavaScript is the accepted and functional tool for the job.
I'd say stick with GWT and just drink more of the Koolaid. It's a completely awesome development model that seems to be lost on those who haven't tried it.
If you want to improve your GWT experience, jump to the bleeding edge (I work off trunk, it's quite stable) and use the other Google originated projects like GIN, gwt-incubator and Guice. Especially watch Ray Ryan's GWT best-practices Google I/O talk: http://www.youtube.com/watch?v=PDuhR18-EdM
As for the "framework" part: forget 'em. Just use normal servlets and let GWT take care of the RPC for you. Servlets are a pain when you have to deal with JSP and you're own AJAX calls, but when they're only implementing asynchronous app logic, it's not that bad at all. Guice Servlet makes it all quite easy. You can still use a JVM hosted language to write your servlets if you want.
GWT has an incredible advantage over other JavaScript frameworks in that the layer of abstraction it provides allows for major future advances without any changes to your code. If the GWT compiler and browser detection scripts can take advantage of new browser features then you benefit from a simple recompile.
The big annoyance I see in your requirements in XML... hopefully that's just for integration with a 3rd party service and your client-server communication can just be GWT-RPC.
I don't use javascript or ajax, in medium-large application they create a lot of problem with compatibility, because moving some part of code inside client, create security breaches and problem with different browser.
I use only HTML(5) and CSS2/CSS3, and I have a lot successes.
I use this 2 ways:
using "puzzle-techinque". Write a lot of small and simple template (or tiles) to create the big page. I use only JSTL and Spring tag, with Rich/Prime/Ice-faces I encountered a lot of problem with rendering, page building and flow controller, so I discarded them.
using my custom library to parse HTML pages. I create template with my custom grammar, put inside the parser and write on output stream. This is the best way.
If you say me your preferred language and context, I can help you to perform JS-free.
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.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am considering creating my own website using Java and am trying to decide what framework to use. However, doing a quick search for Java frameworks returns more than 50 to choose from!
My website is just going to be for my own enjoyment of building it in the beginning, but if it becomes popular, it would be good for it to have some scalability, or to at least be able to redesign for that.
What are the main differences between the more popular frameworks? Are there instances where one significantly outperforms the others? For example, high-traffic enterprise applications versus low-traffic small applications. I'm also wondering if some are much easier to learn and use than others.
Is there anyone who has experience with some of these frameworks and can make a recommendation? Does the sheer number of choices just serve as an early warning to avoid Java-based web development where possible?
I've used Tapestry 3, Wicket, Echo, and JSF fairly extensively. I'd really recommend you look those over and pick the one that appears the easiest for you, and to most closely fit the way you prefer to work.
Of them, the most comfortable for me to work with was Wicket, due to the lightweight nature of component building and simplicity of page templating. That goes doubly so if you are using your own db code instead of Hibernate or some other framework (I was never completely happy with Wicket Hibernate or Spring Integration).
Echo is great if you don't mind writing all of your layout in Java. I know that is different now, but I still think that product serves a fairly narrow niche. They change the development model with every major release as well it seems.
Tapestry is a great product, but it is obviously very different from the others in terms of development model as it is led mainly by one dude. Howard Lewis Ship is no doubt quite smart, but I am disappointed with their decision to basically forget backwards compatibility with each release. Again, though, for your needs this may not matter, and I've always found the Tapestry products pleasurable to work against.
JSF has been out for years, and still feels like something that a Struts guy built to fix all of the problems of Struts. Without really understanding all of the problems with Struts. It still has an unfinished feel to it, although the product is obviously very flexible. I use it and have some fondness for it, with great hopes for its future. I think the next release (2.0) to be delivered in JEE6 will really bring it into its own, with a new template syntax (similar to Facelets) and a simplified component model (custom components in only 1 file... finally).
And, of course, there are a million smaller frameworks and tools that get their own following (Velocity for basic needs, raw JSPs, Struts, etc). I generally prefer component oriented frameworks myself, though.
In the end, I'd recommend just taking a look at Tapestry, Wicket, and JSF and just picking the one that feels the best to you. You'll probably find one that just fits the way you like to work very quickly.
My favorite is the Spring Framework. With 2.5 Spring MVC is soooo kick ass, with new annotations, convention over configuration features, etc.
If you're just doing something super simple you could also just try using the regular Servlet API and not bother with a framework.
I recommend the component oriented Wicket framework. It allows you to write your web application in plain old Java code, you can use POJOs as the model for all components and don't need to mess around with huge XML configuration files.
I had successfully developed an online banking application with Struts when I discovered Wicket and saw how easy web application development can be!
I've recently started using the Stripes Framework. If you're looking for a request based framework that's really easy to use, but doesn't impose any limits on what you are doing I'd highly recommend it.
It's similar to struts, but it goes way beyond it. There are even some plugin projects that enable you to do use hibernate or jpa with very little configuration.
There are a lot of good frameworks out there though I've heard wicket is a good one as well, but I haven't used it.
Haven't tried it myself, but I think
http://www.playframework.org/
has a lot of potential...
coming from php and classic asp, it's the first java web framework that sound promising to me....
UPDATE: Tapestry 5.2 is out, so it's not abandoned, as it previously appeared to be. My experience is with Tapestry 4, not 5, so your mileage may vary. My opinion of Tapestry has changed over the years; I have modified this post to reflect it.
I can no longer recommend Tapestry as I did previously. Tapestry 5 appears to be a significant improvement, but my main issue with Tapestry is not with platform itself; it's with the people behind it.
Historically, every major version update of Tapestry has broken backwards compatibility with extreme prejudice, far more than one might expect. This seems to be due to the incorporation of new coding techniques or technologies that require significant rewrites.
Howard Lewis Ship (the principal author of Tapestry) is certainly a brilliant developer, but I can't say I care for his management of the Tapestry project. Development of Tapestry 5 began almost immediately after Tapestry 4 shipped. From what I can tell, Ship pretty much devoted himself to that, leaving Tapestry 4 in the hands of other contributors, who I feel are not nearly as capable as Ship. After having made the painful switch from Tapestry 3 to Tapestry 4, I felt that I had been abandoned almost immediately.
Of course, with the release of Tapestry 5, Tapestry 4 became a legacy product. I wouldn't have a problem with this if the upgrade path wasn't so brutal again. So now our development team is in the rather unenviable position: We could continue to use an essentially abandoned web platform (Tapestry 4), make the heinous upgrade to Tapestry 5, or give up on Tapestry entirely and rewrite our application using another platform. None of these options is very attractive.
Tapestry 5 is supposedly written so as to reduce the likelihood of update breakage from this point forward. A good example is in the page classes: in previous incarnations, page classes descended from a base class provided by Tapestry; incompatible API changes in this class were the cause of a large number of backward compatibility problems. In Tapestry 5, pages are POJOs which are enhanced at runtime with the "magic Tapestry fairy dust" via annotations. So as long as the contract for the annotations is maintained, changes to Tapestry won't affect your page classes.
If this is right, then writing a new application using Tapestry 5 could turn out well. But personally, I don't feel like putting my hand on the burner again.
Disclamer: I work at Vaadin (previously IT Mill)
If you are doing something RIAish, you might want to take look at Vaadin. It's an open source UI-oriented AJAX framework that, to me, is nice to use (I come from a PHP background myself).
There's a case study that compares doing the same application (i.e. two applications with the same set of features) in Icefaces and Vaadin. In a nutshell, it states that the UI development was considerably faster.
Even though the study is hosted at the company's wiki, I can assure that it's objective, genuine and truthful, although I can't force you in believing me.
After a long while of testing various solutions, for me it turned out to be:
Spring MVC for the presentation and
controller layer (NO Spring Webflow though,
because my flows are based on ajax)
jQuery for all the client side stuff
Spring Security for the, well, security aspect
Hibernate / JPA2
Jetty for the sake of continuations (comet)
One month of an extraordinarily steep learning curve, but now I am happy.
I would also like to mention that I was just a little step away from skipping all that Java stuff and learing Scala/LIFT instead. As far as I am concerned, everything in Java that is related with cutting edge web development (comet, async communication, security (yes, even with Spring Security!)) still is a bit of a hack (proove me wrong by evidence, pleeease!). To me, Scala/LIFT seems to be a more out-of-the-box and all-in-one solution.
The reason why I finally decided not to go with Scala is
as a project leader I must consider human resources and Java developers are much easier to find than Scala developers
for most developers in my team, Scala's funcional concept, as excellent as it is, is hard to understand
Cheers
Er
I've heard good things about the Spring Framework too. In general, though, I've been underwhelmed by most Java web frameworks I've looked at (esp Struts).
For a simple app I'd definitely consider using "raw" servlets and JSPs and not worry about adopting a framework. If the servlets are well written, it should be straightforward in the future to port to a framework if necessary when the app grows in complexity.
My pick is Wicket!!
All of them - that's the problem ;-)
I think for your modest requirements, you just need to code up servlets or simple jsp pages that you can serve from Tomcat server. I dont think you need any kind of web-framework (like struts) for personal web-site data
Saying "use JSF" is a little to simple. When you decide to use JSF, you have to choose a component library on top of it. Will you use MyFaces Tomahawk, Trinidad, Tobago (http://myfaces.apache.org/)? Or maybe ICEfaces (http://www.icefaces.org/)? Oh, and if you use ICEfaces, will you use JSPs or Facelets for your views?
In my opinion it is to hard to tell. Nobody has the time to evaluate all the promising alternatives, at least in the projects I work on, because they are not big enough to do three month evaluation phases. However, you should look around for some that has a big and active community and isn't gone in a year. JSF is around for some time, and since it gets pushed by sun, it will be around for some more. I can't say if it's the best choice, but it will be a good one.
http://zkoss.org - the good one
For high traffic sites I'd use a framework that doesn't manage client state on the server - Wicket, JSF and Tapestry are managing client state on the server. I'd only use those frameworks (Wicket is my favourite) if the application should be more like a desktop application. But I'd try to use a more scalable and simple REST+AJAX approach though.
Spring MVC would be a candidate, but since Spring MVC 3 it has a strange annotation overloaded programming model which doesn't use the benefits of static typing. There ore other ugly things like output parameters in methods combined with a usual return, so there are two output channels of one method. Spring MVC also tends to reeinvent the wheel and you'll have more to configure compared to other frameworks. I cannot really recommend Spring MVC though it has some nice ideas.
Grails is a convenient way to use Spring MVC and other established frameworks like Hibernate. Coding is fun and you'll quickly see results.
And don't forget that the Servlet API with a few little helpers like FreeMarker for templating is very powerful.
I have evaluated quite a few frameworks and Vaadin (http://vaadin.com/home) has percolated all the way to the top.
You should at least give it a short evaluation.
Cheers!
My pick would be Wicket (for large projects and a predictable user base), GWT (for large projects that are mostly public facing) or just a service framework (like Jersey/ JAXRS) together with a JavaScript toolkit (for small to medium projects).
I recommend Seam, especially if you need persistence.
See a few comments on some Java application Frameworks (second paragraph):
http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html
For quick and fancy GUI you can use JSF with Richfaces library.
Richfaces UI components are easy to use and handy references available with code demonstration in the demo site. Probably later when your site has more data to handle and lot of information has to be transacted in database you can plug any database access framework (ORM) with it.
Can't believe no one has mentioned GWT
My favorite way to go for really simple apps is Apache VelocityTools (VelocityLayoutServlet) with Velosurf (http://velosurf.sourceforge.net).
For more complex apps, Spring MVC or Struts 2.
Try HybridJava - that is much simpler than anything else.
I would say vaadin or wicket