Java web frameworks

I was looking around to see if there is an equivalent to django/RoR in java.

I found:

• Play Framework
• Grails

Does anyone have eve开发者_如何学运维r tried those frameworks, or do you know any other? Are they faster than django/RoR?

I discovered Grails about a year ago, and haven't looked back. It takes a lot of ideas from Ruby on Rails (original it was named Groovy on Rails), and has a rich ecosystems of plugins / extensions. Grails, and underlying Grails language (superset of Java) make it a joy to program - you can really focus on the essentials. Its GORM functionality (a layer on top of hibernate) is also very powerful, and in addition to the plugin system, is one of two huge reasons to check it out (you can use it in your java apps as well).

With version 1.2 about to come out, I feel it's feature-rich and mature enough to be something that any developer should have in their toolbelt.

As far as performance, it's definitely less than that of pure Java, but you have everything from spring / hibernate / J2EE available to you to optimize, and you can always drop into pure java for some critical pieces of code. There have been some recent experiments with allowing to run part of the Groovy code using static method resolution, which, coupled with invokedynamic support, should provide huge performance boosts.

Other ones to check out in Java are Spring Roo, and AribaWeb.

Update Based on Additional Qualifications

Scalability, Productivity, Documentation, and decent Resources consumption

• Scalability - you get the proven Java / Spring / Hibernate stack, though I can't say Grails provides much itself.
• Productivity - this is the main reason to use Grails. You do have a performance overhead, but Grails is what you use when development time / productivity is more important.
• Documentation - the grails docs are great, and there are at least three good books written on Grails alone. The community is thriving and very helpful.
• Resources Consumption - that is the one tradeoff. Grails (partially because of the underlying java stack) is resource-intensive. If I was building something like Google, Grails would not be the choice. However, in any web app of any sophistication, you'd do well for a caching solution, so same applies here.

Stripes seems to be quite lightweight and embraces Convention over Configuration.

Having used struts, wicket, rails & Tapestry, I recommend you look into Tapestry 5.

It supports

• in container class reloading (so you dont have to restart your webapp each time you make a change)
• fast development time & increased productivity - it uses a component based model, with declarative wiring
• minimal configuration, which is mostly in code anyway, convention over config - etc..
• No base classes to extend
• An expression language for use in template files
• good ajax support
• excellent debugging support, both client and server side
• good data access integration
• an active community
• written from the ground up with performance in mind. e.g. page pooling (to minimise resource usage), page compression, whitespace elimination, all dynamic code is compiled to native.
• good bean and form support - making common tasks simple. A sortable database backed drid can be coded with just one line of template code, and a minimal skeleton server backend.

the only downside is the documentation, which, is good, but a little terse, although the user groups/mailing lists are very active and most questions are answered well & eagerly.

(Also, be sure to only look at T5 - and not T4,3,2,1..... as these are very different to the current version)

More on why here.

Consider trying Lift Framework. It`s really great.

Anytime you are contemplating an application stack (language, framework, etc...) you also need to consider what are you trying to solve for and what kind of programming skills do you have at your disposal. I've found that more experienced Java programmers have been very productive with the Groovy and Grails stack when compared to more junior programmers.

You mention the following as areas of concern:

• Scalability: in terms of what exactly? (page views/second, # transactions/second, etc...) In general, Groovy & Grails will scale when it comes to rendering pages, however as with any application stack using ORM (in the case of Grails you have GORM) there is some overhead to consider.
• Productivity: one of the primary advantages here - quick prototyping, rapid development is a breeze with Groovy & Grails, though it helps to have folks on staff that have developed in Java or Ruby to understand what the Grails framework is actually doing "under the hood". There are tons of plug-ins for the UI that help with creating web 2.0-like pages very quickly.
• Documentation: there is an increasing number of quality reference books being written for Groovy & Grails. Both are maturing very nicely over the last 2 years. Things are certainly not very well documented with respect to much of the inner working of the Grails framework when errors/issues are encountered (much of the output from the framework is obscure or non-existent at best when an error is faced). If you are willing to roll up your sleeves and be resourceful in walking through the inner workings, then you won't be disappointed with this stack. Again, experienced programmers will find this as second nature while more junior folks may throw up their hands in frustration at times.
• Resource Consumption: there is overhead, however with most of the hardware found today (local or in a cloud) I wouldn't worry too much about physical resource consumption for a given application instance.

Hope this helps.

I don't know about the Play Framework, but to answer the second question, we are doing some projects with Google's Webtoolkit. Could be worth checking out.
Good luck!

How about JRoR

Haven't tried it myself, but colleges of mine enjoy using stripes

There's a book and everything.

Spring Roo claims to be a solution.

I've done a project with grails and i've found it really fast for some tasks, but it does many "magic" behind the scenes that makes it difficult when debugging.

Also I found myself reading over and over the documentation because I didn't feel it natural. A simple example is the controller where the action's are defined as fields (It's natural for me to think of an action as a method...). I can say something about GORM where you need to know some special words that when put in static fields does some magic like making a field transient... No annotations, no autocompletition... only the manual.

As for Play! I found it amazingly simple and fast for developing, easy to learn and to remember. The community seems smaller than Grail's but it's more active and faster to answer. The only disadvantage is that it does not rely on servlet's api so some 3rd party filters or other stuff is difficult to integrate but not impossible. It's important to note that you can deploy a Play application in any traditional web server packagin it as a war.

In my opinion Grails is great but you need to have a lot of experience with it to be productive, otherwise you'll lose a lot of time with the manuals. So if that is not your case I should recommend Play! Specially if you are not familiar with Groovy

I don't know about Play Framework, but Spring MVC or Struts together will Hibernate will offer similar functionality.

There are many other options available. Basically you need an MVC framework (Spring MVC, Struts, Wicket) and an ORM tool (Hibernate, iBatis). Of course you would need to integrate the needed components yourself, but this has been done already many times and you will be able to find plenty of information.

I'm not sure if Spring MVC and Hibernate provides the same ease of use that Ruby on Rails provides (actually, I'm sure it is much more complicated...). Play Framework is much more like Ruby on Rails I think, however I didn't us it myself and only watched the screencast and read some documentation on it, so if you want to have a similar experience to developing using RoR, I think you can better try something like Play instead of Spring MVC with Hibernate. The advantage of the latter is that it is very powerful and is able to adapt to an existing datamodel for example (from what I know on RoR, that is not very trivial in RoR). Another framework you could consider is Groovy on Grails. While it doesn't use Java (it uses Groovy), it is very RoR-like. It uses Spring and Hibernate under the hood (if I'm correct) and the advantage of Groovy is that you don't have the strict static typing of Java. Ruby on Rails and Django benefit heavily from the dynamic nature of the language in which it is implemented, a feature Java misses because of its static typing.

Edit: ah, you mentioned Grails already in your question...

if grails is an option (which is actually not a java but a groovy framework) then the Scala-based Lift framework would be an option, too.

Another option is RIFE, which tries to have the minimal configuration of RoR while still being in Java. On your list, only Play Framework has that feature, the others are on the JVM, but are not Java (if that is important to you at all).

What about VRaptor? - it uses Spring as DI Container and a Controller/View engine similar to Rails Action-Pack.

AribaWeb also supports Groovy. Check out our other features at http://aribaweb.org/ and find out our approach to making web development productive.

We use Stripes framework extensively and it works really great. It's really lightweight and it directs you towards a clean design of your applications. It basically just hides the boring parts of development from you, so you can focus on the fun stuff (One such example are the indexed properties).

I have been using http://www.ninjaframework.org/ for micro-services and it is very close to most mvc paradigms,if you used rails, asp.net mvc, or nancyfx, you are good to go. It is very close to that philosophy and really awesome and easy to test. Only down-side there isn't much documentation, but it follows mvc pattern pretty closely. It uses nothing proprietary in the framework so it is a pure java based solution. So this makes up for the lack of documentation.