Develop Reference

JVM Frameworks, which one?

I don't have much experience in frameworks or languages, so i need your help.
Here's what i've done so far so you can understand where i'm coming from.
I've developed a web app using Java/Spring MVC/Hibernate. on the front end i've got some jquery datatables doing ajax calls to a db, another pages executes a stored prod and thats about it.
Now i got fed up with all the configuration, beans, hibernate mapppings, spring mappings, apache tiles, and the list goes on.
I had a play with Groovy/Grails and that seems so much easier, but that means i need to learn groovy and i've heard about it's performance weakness.
So i ran into Play Framework, can someone tell me if Play would make my life easier with the above scenario or should i just go into Groovy/Grails or even scala/lift.
I don't have too much time on my hands to pick up another language so if i can stay with core Java and use Play that would be great.
So is my described headache the reason why there's RoR/python-django, grails ect,ect? or is it something else?
thanks,
glenn.

I can tell you from the perspective of a 10 year J2EE developer who went from JSP/servlet to Grails to Play. 6 years ago I discovered groovy and I liked it very much, I've been using groovy and it's GSP templates in my other projects for code generation. I really love groovy syntax. Because you can do a lot in a single line of code ;) Because of groovy I tried Grails. But, besides the use of the language to code something in perhaps some 20% of the project time, you are 80% dealing with Grails conventions. How do they map this and that and to the persistence layer (which is JPA underneath the surface). So you're browsing the docs most of the time.
Then I found play. It really felt natural. Everything is so quick with it. Everything is direct, it is 80% undisturbed, productive coding, only 20% reading the docs. The code completion of any Java IDE is literally sufficient support. In Grails you either need a Grails IDE or you find yourself frequently browsing the docs.
The biggest attractor of Play to me is the hot code swap feature, which nearly completely eliminates the build phase. Play's class enhancers give you enough comfort to get over the loss of those dynamic finders in Grails. In the meantime, I even write my own enhancers to get even more comfort.
In a real project, the strongly typed Java language is a huge benefit to all developers. You just can't break it so easily as you can with groovy.
Also, if you look at the Play package, you always get reasonable defaults. Things that all developers like. jQuery based CRUD, beautiful code samples, good visual experience. And it's all as minimalistic as possible. Which means, you can always go to the play framework source itself and read the code to understand play's behavior.
So to sum up, after 10 year of Java and J2EE frustration and almost giving up on Java I switched back to it as implemented by Play, because in Play it is so much fun and I now love it again. I recommended play to 2 other developer friends and they love it too. It feels like the Java that it should have been in the first place. Fast, clean, secure & a lot of fun. I will never use something else based on Java, not even for a simple main() ;)

Play!
After 6 or 7 years of Spring/Hibernate, a couple of more with JSP/EJB I was done with the Java world, looking for other alternatives like Scala, Node.js, Rails, etc. Play Framework has made me fall in love with Java all over again, even though I do recommend Scala.
I have lots of information about Play on my blog http://geeks.aretotally.in and http://playframework.info.
It's super easy to pick up, it's crazy productive and you will have lots of fun!

If you ask a Play framework guy, he will tell you to use Play. If you ask a Scala/Lift guy, he will tell you to use Scala/Lift.
Ideally you'd like to find someone who has used Groovy/Grails, Scala/Lift, and Play, but unfortunately there are not too many of those around.
FWIW, I use Groovy and Grails, and like it a lot. If you already know Java, Spring, and Hibernate you already know most of what you need to be productive with Groovy/Grails.
If you don't want to spend a lot of time learning a new language, I'd stay away from Scala, as it's a very different language to Java, whereas Groovy is almost a superset of Java, and with a familiar syntax.
I know virtually nothing about Play, but I'd be concerned about the size of the community - check the number of Play and Grails questions on stackoverflow for a rough comparison.

Grails 2.0 performance will be pretty much on par with the static typed languages out there.
Based on your current architecture, Grails would be the most natural fit - you can re-use all existing classes and code without an issue, and have it directly picked up. You can freely use #Autowired and other Spring annotations, java code, and Grails picks it up - because Grails is Spring under the covers. The only part that might need a little tweaking are JSPs, but I was able to get existing JSPs and custom taglibs working without an issue. Grails uses SiteMesh to compose it's Groovy Server Pages (think JSP groovy-ized, and removing some of the JSP restriction gotchas).
Nothing against Play, Lift, Clojure's web framework, SEAM, or any of the other frameworks out there -- but if you want a simple transition from what you have to something a little more productive, then Grails would be the closest fit.
Of course these days, just about every one of those frameworks supports polyglot programming - you use Scala for something, Groovy for something else, and Java all around - compilers, build environments, and tools are all addressing polyglot development.
Long story short, it comes down to requirements and risk management - do you need functional programming, dynamic typing, re-use of your Spring controllers, or just some simplification and productivity boosts?
Even a simple Spring 3.1 upgrade may eliminate some of your XML files for annotations and solve most of your problems.
Happy Hunting!

Which is the easy way to build login/registration/admin area type website in java

I am php programmer but i am learning java now. i have finished the core java and build small projects using jdbc , mysql gui etc.
Now my boss wants to build the website where user will collect points and they can shop based upon points left.
But the initial phase will be only the logs/registration/admin area etc.
Now i have two options
1)Do in php
2)DO in java
I really want to do in java thats why i was learning it. Now now the project came early.
I wanted to learn spring , spring mvc , hibernate etc , design patterns but now i can't spend time first to learn.
i want to ask that what will be good solution to go at it. Initially was thinking of doing the website in JSP.Is that ok
O i am thinking of using Wicket and not using hibernate, is wicket enough to build ecommerce site. or i need anything else as well
I know only core java , what should i do

PHP development is very action/template-oriented, AFAIK. Wicket is a component-based framework, that heavily applies object-orientation concepts, and that may take some time to grasp. If you don't have much experience with OO, and your deadlines are tight, maybe you'll prefer an action-framework (Struts2, SpringMVC), which is far better than raw JSP. But, if you have some time to spend, and the will to learn, Wicket is definitely a great framework!
Spring is also nice, and while dependency injection is not something you see often in PHP, it's simple enough (Spring is well documented, its reference doc is actually useful, and you'll find many tutorials and examples on the Internet), and it's definitely worth learning.
Hibernate is a very good framework for persistence, but if all you know is plain SQL/JDBC, it takes some time to master it to the point that you don't get frustrated with mapping, and lazy-loading errors. Again, try it if you have some time to spare and the will to learn.
Wicket+Spring+Hibernate is a really nice combo, I use them a lot. It may or may not be the best stack for your case. As everything in IT, it depends on the context. But I think they are very sound technologies, individually or combined.

Consider Struts 2. It is both effective and there is a good size community here if you have any questions. I don't know wicket, but any web framework is better than straight JSP.
Hibernate is nice but since you have a lot on your plate you should probably stick with straight JDBC for now. Spring is also very nice, it is easy to integrate spring DI with struts2 (so easy as a matter of fact I would recommend you just start that way).

One of the fastest ways to get a Java webapp up and running is to use Play Framework.

How to improve productivity when developing Java EE based web applications

I'd like to know how you address the seemingly low productivity of Java EE-based web application development compared to other technology stacks (Seaside, Ruby on Rails, etc).
The constraints are:
The finished web application must be deployable on Java EE compliant application containers
If possible, previous investment in Java-based solution should be preserved, i.e. native interoperability with Java-based systems and libraries should be possible
Due to team structure, Java as implementation language is preferred, although less exotic JVM-based languages (i.e. Groovy) might be acceptable as well
The resulting system needs to be architecturally sound
The resulting system needs to be extensible and maintainable
To not let this dwindle into a philosophical discussion, I'm only interested in suggestions that are based on practical experience. Possible examples include domain specific languages, frameworks and MDSD.
If you point to an abstract class of solutions (like MDA / MDSD), please provide details on how you implemented it as well as information about common pitfalls and best practices.
If you disagree on the assumption that Java EE-based web application development implies inferior productivity, I'd like to hear your reasoning as well.
EDIT:
As there are a lot less answers than I expected, I'll accept accounts of abortive attempts as well, basically extending the question to "How (not) to improve productivity when developing Java EE based web applications?".

I believe the Java EE Java stack is actually very good. There are a few reasons explaining the low productivity of Java EE:
Being “the enterprise stack”, it is often used to create boring, ugly, “good enough” applications and, in general, enterprises tend not to attract great developers who love programming, and think and care about what they do. The quality of software in the enterprise world is not great.
Being the enterprise stack where the money is, software vendors try to sell something to them. They create huge, complex and expensive solutions not because they are good, but simply because they could sell them to enterprises.
Enterprises are often very risk averse and everything they do better be “standardized”. Standards are created either after some technology proved to be successful or before. In both cases, it’s bad for enterprises (and Java). Enterprises end up using either good technology too late or a downright failed technology. The latter case is also very dangerous because it creates a false perception that a technology (otherwise a complete failure) must be good if it is standardized and everyone is using it.
Historically, Java EE platform seemed to have attracted a lot of architecture astronauts and developers in big companies promoted to architects whose only purpose was to create more layers, more frameworks, more abstractions and more complexity.
It’s not that there are no good Java tools and frameworks; it’s that there are too many bad ones, too many over-engineered ones, too many bureaucratic processes and methodologies, too many useless standards.
In such a messy world it’s not just the particular selection of tools you choose that affects your productivity. It’s mainly about you, about your values, about how you can reject the majority of solutions proposed to you by the community, vendors, co-workers and managers. It’s about you going against the current, about your common sense, about you questioning every mainstream belief and “best practice”.
That said, tools alone are not going to change your productivity much, and conversely, the right people can be productive with inferior tools too.
My advice:
Don’t use a technology only because it’s standard, because everyone uses it, or because it’s officially recommended by Sun. Use a technology only if you personally think it’s the best tool for your job. This way you may find yourself rejecting technologies such as JSF, JSP, Web services, JMS, EJB, JTA, OSGi, MDA.
Keep it simple, use your common sense, question everything. Do you really need to publish your objects for remote access? Do you really need to create another abstraction layer so that you can switch from Hibernate to TopLink? Do you really need to convert your data to/from XML ten times every time you need them? Do you really need XML schema? Do you really need everything to be configurable are interchangeable? At runtime? By non-developers?
Keep the process simple. Be agile. Do you really need that documentation? Do you really need to describe every screen in a huge table, have it approved, type it in to some home-made tool and then generate JSP? Do you have competent programmers or you design everything first and programmers only “translate” to Java?
WYSIWYG design of HTML doesn’t work.
Graphical programming in general doesn’t work. This includes UML as blueprint and UML as programming language, MDA, drawing page flow diagrams. Code generation is bad.
Never design a framework prior to using it, always harvest a framework.
Prefer frameworks that have only little XML configuration.
Strive for low LOC count. Look at actual characters in your code. Is every character important? Think. What can you do to make your code smaller? Do you need that class? What does it do? Why do you need to do that?
Testing is not sacred cow; you don’t need 100 % test coverage. Test only what makes sense. If it’s difficult to test, make it simpler; or don’t test it at all. Don’t test visual appearance.
And finally, some concrete Java recommendations:
For presentation layer try Tapestry. Why do I love it? Because with Tapestry you can create beautiful code. It’s designed specifically for that, so that your code can be beautiful. Your code. By beautiful I mean everything that matters – it’s short, easy to change, easy to read, easy to create your abstractions, and still flexible, it doesn’t try to hide the fact that you are developing for the web. Of course, it’s still you who makes your code beautiful.
Feel free to use Hibernate, especially for CRUD and large apps. Don’t bother with JPA. It’s not a silver bullet though, with ORM you are always going to trade one set of problems with another.
Only a little Spring, you shouldn’t need much since you’ve carefully avoided all the Java EE traps. Use dependency injection sparingly.
After all of that, you may find the Java language too verbose and not very helpful when abstracting away you copy/pasted code. If you want to experiment, try Scala. The problem is that the main selling point of Scala is that you get all the benefits of modern languages while still keeping type safety, and at the same time, there is no solid IDE support. Being used to super-cool Java IDEs, it doesn’t make much sense to switch to Scala unless there’s an IDE support that is stable and reliable. Stable enough is not enough.

Frameworks like Spring, Hibernate, Wicket certainly help to simplify and accelerate web development as they provide a high degree of testability and integrate very well. But it's not enough to reach RoR productivity, even if you have a good set of development practices. There is still too much technical stuff and plumbing required.
Grails is maybe the missing piece in this picture to get closer to RoR. It's my next experimentation.
BTW, my MDA experiences are the contrary of a productivity improvement so I won't mention them (actually, MDA was killing our productivity).

Javarebel can greatly reduce time spent during web development using Java.
Let me quote here the official website:
JavaRebel is a JVM plugin (-javaagent) that enables you to see changes to your code immediately, without the need to redeploy an application or perform a container restart. If you're tired of watching the logs roll by, and want to see your changes so that you can keep going - JavaRebel is your new best friend.

One important point when discussing Java EE productivity: you should be using Java EE 5 and EJB3.x since they provide for new level of productivity (and functionality) compared to previous releases.
Staying within standard Java EE specs is absolutely important, e.g. using Hibernate instead of JPA is not beneficial to productivity. There is no limitation to fall back to Hibernate features when using JPA, but by using Hibernate instead of JPA you are locked in into single persistence provider with no cheap way out. The whole idea behind using standards is the same: conceptual flexibility (by plugging in different implementations) with available extensibility (by using proprietary extensions if absolutely necessary). Java EE 5 and EJB3 are huge steps in this direction. Of course, you want to minimize any proprietary features but if some seem absolutely necessary it's a good sign that they will be part of spec in next release...
Main obstacles to Java EE productivity are in its enterprise focus (offers a lot more than than needed for majority of projects) and in its legacy (backward compatibility). There is also a lot more to be done in presentation tier with JSF and state management - watch for JSR-299 to address these among other improvements.

Grails is a Java webapp framework very much modelled after Ruby on Rails, with similar principles (DRY, CoC) and productivity gains, but based on existing Java frameworks (Spring, Hibernate, several others).
I've been working on an exploratory project using Grails for a few weeks now (no previous experience in Grails or Groovy), and I'm quite impressed. There are a few rough edges - it's not as mature as RoR, but you can get results quickly and there's never the feeling that the framework is getting in your way.
Maybe it's best illustrated by this concrete example: I wanted to edit a 2D array of domain objects in a grid on a single webpage and found that the automatic mapping of the resulting HTML request data to the domain objects (provided by Spring MVC, I believe) had a bug that caused some data to be mapped to the wrong objects. I looked around on the web for an hour, but apparently nobody had encountered or solved the problem. Eventually I decided to forego the automatic mapping and do it "manually" - and then found that it took me no more than about 10 lines of code...

It's often cited that RoR and similar frameworks based on dynamic languages are more productive environments, but I am really interested to know if there are hard data to back this up. This wouldn't be easy, as one should be made certain that she is not comparing apples with oranges. Things like type of project (web 2.0, enterprise application) and team size should be taken into consideration. However, for small projects it is more than evident that such frameworks are indeed far more productive than Java EE. So this is a short list of arguments used to support this and what you can do for them in the Java world.
Ruby is a more intuitive and concise language. You can do the same thing with much less code.
I don't think you can have the same thing in Java, unless of course you use a dynamic language that runs in the JVM (JRuby, Scala, Groovy). Otherwise, your IDE can help. In Jave an IDE is an essential tool and it will pay you back if you learn to use it well (code generation, snippets, refactoring). In fact there are many things you can do with a Java IDE that are simply impossible to do with a Ruby or Python IDE. Plus you have the benefits of a static typed language. It may take more time to type, but it helps you avoid common mistakes.
Ruby is much more fun to use. Makes the developer happier and more productive.
Same as above. Highly subjective argument in my opinion though.
Convention over configuration makes things faster
A dependency injection framework like Spring or Guice can help
Scaffolding, MVC already there for you.
Again Java MVC frameworks can help
Databases made easy. Load database items as objects. Can change the database on the fly.
Hibernate, iBatis or another ORM framework can help. With Hibernate Tools you can achieve similar functionality with what you have in RoR with yml files
Load new modules instantly
Maven or Ant Ivy can help
Easy deployment for testing
Your IDE or Jetty can help. In fact debugging is easier with Java
Testing integrated with the framework. Use of mock objects facilitate testing
A dependency injection framework can help with mock objects. JUnit was a pioneer of unit frameworks. I don't think that Java is less easy to test.

I would definitely go for Spring together with Hibernate for persistency related stuff.
Why Spring?
The advantage of using Spring instead of another framework is that Springs philosophy is to be "non-invasive". Usually when you're using a framework most probably you'll start to depend on that framework which can be a bad issue if the application is considered to run for a longer time where you then have also to do maintenance etc. Spring uses the so-called "Inversion of Control" (IoC) pattern. Basically your code doesn't (it can but it doesn't have to) call Spring, but Spring will call you (Hollywood principle: "don't call me, I'll call you"). So for instance you can use normal POJOs (Plain Old Java Objects) and you don't have to inherit from any framework-related classes/interfaces.
Another big problem (if not the biggest) in Software Engineering are dependencies. You'll fight for reducing them as much as possible since they will make your life harder (especially in maintenance later on). Spring reduces dependencies among your components drammatically by managing the instantiation of components through configuration files and the dependency injection pattern. I wouldn't want to go on, the best thing is that you start reading some tutorials at the official Spring website. Initially it may need some time in the understanding but once you got it you'll earn a lot of benefits.

Since Jython 2.5 you can use django to satisfy the requirements you listed. It's pretty easy to generate war files from django projects and deploy them on J2EE application servers.

Just wanted to pitch in another idea... you can actually use JRuby and Rails (similar to the previous comment about Django and Jython).
If you use JRuby with Rails and JRuby Rack (and maybe some other utilities... I wasn't the one to actually get the integration going initially), you can deploy JRuby Rails additions to an existing Java web app. We have a legacy JSP application deployed with Tomcat, and are now starting to add new pages using Rails with just that setup (in addition to extending the JSP side when necessary). So far it has been quite successful, though we don't have any of the major high traffic pages implemented in Rails, so I don't know how well it will scale.
We have full access to the session, and have even set up mechanisms to invoke JSPs from Rails pages (such as existing header and footer type JSP includes). It takes some effort and trial and error to fully integrate the 2, but if Rails and JRuby is an option, I highly recommend it (as a personal fan of Ruby).
A colleague has dabbled in JBoss Seam, which is a framework by Gavin King (the guy who brought us Hibernate), which was meant to emulate Rails. Having seen both, I feel Rails is a lot easier to develop with.

Use AOP (Aspect Oriented Programming) for cross cutting aspects like logging, authorization etc. You can either use Spring AOP or AspectJ. It makes code clutter free and maintainable.

I've used Jboss Seam for the past couple of years and find it to be very productive way to develop in Java EE (utilising EJB3, Hibernate, Facelets). I also do the odd bit of PHP coding on the side and can honestly say that I'm more productive with Seam (although that's probably also an indication of my PHP skills.)
For me a couple of the highlights would be:
Hot deploy of code (an absolute must-have)
DRY with Facelets
Annotation based configuration
Extensive drop-in components (especially ajax4jsf)
IDE Support from Jboss Tools
There are tools in the IDE and from the command line to build skeleton code in a similar way to RoR.

Well, I'm not really a Java guy, so I can't say much, except for... JSF
We tried to use it for some time and it was a disaster. Almots all basics steps had to be passed with lots of pain, no documentation, no examples, no community knowledge. We used then one plugin for Eclipse (Exadel Studio), we had a look at a few other JSF frameworks, they were all incompatible and poorly documented. As a matter of fact, of all those we tried, only Sun framework (forgot its name, based on NetBeans) could create a new JSF project even compilable out of the box. The rest required many days of configuration of apache and other things, which for an unexperienced person is a real challenge (though I managed it).
Our team spent a few months on something which was done later in just a few weeks with ASP.NET. People were both inexperienced in JSF and ASP.NET.
If JSF ecosystem is still that bad as it was in 2007, I would recommend avoiding it altogether, productivity is out of the question anyway. Maybe stick with JSP or something that is time-proved and well developed?

I would go with the Lift framework written in Scala. You will see a great productivity boost just by switching to Scala. Scala is also very stable and it's extremely easy to call Java code from your Scala code. Not only that but it's quite similar to Java but with some added features. For some examples you should refer to 5 Things a Java developer needs to know about Scala. Twitter will move part of it's codebase to Scala.
You will never "get stuck" on a piece of code because you can just think about how you would do it in Java and write similar code. First class functions and actors will give you an even greater productivity boost and are both in Scala. Scala is of course statically typed and has a performance that is similar to Java.
I will quote the author of the Lift framework for an description of it:
Lift borrows from the best of existing
frameworks, providing
Seaside's highly granular sessions and security Rails fast flash-to-bang
Django's "more than just CRUD is included"
Wicket's designer-friendly templating style (see Lift View
First)
And because Lift applications are
written in Scala, an elegant new JVM
language, you can still use your
favorite Java libraries and deploy to
your favorite Servlet Container. Use
the code you've already written and
deploy to the container you've already
configured!

Some basic rules:
Kick out the appserver - a HUGE win in turnaround and quality. Keep a web container if you have to, but configure everything in Spring and/or Hibernate so the web.xml is minimal.
Test everything, which you can now do because of step 1 (no deploy-time XMLs or code generation needed: everything is configured in the development already).
Use Wicket to implement your web tier - nobody needs JSP any more; Wicket is 10 times more productive plus easy to test (see step 2).
Use SCRUM and agile development methodologies
The result is Java productivity as high as 4GLs allow - we at Atomikos have several migration projects we did like this. Because we migrated from 4GL platforms to Java/Java EE, we could compare the estimates in both.
Also see this blog post: http://blog.atomikos.com/?p=87
HTH
Guy

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.

What are the pros and cons of the assorted Java web frameworks? [closed]

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