Reviews by real users

Just finished a project using open source libraries and have fresh impressions?

Write a review to share your experiences with open source!

On DevRates we focus on reviews by developers using libraries on their daily work.

Technology radar

Launching a start-up or commercial project using open-source libraries? No time to evaluate various technology stacks?

Interested in the latest trends and top-rated open source projects for all layers of your application?

DevRates contains projects reviews of most popular tagged categories and programming languages.

Build your skill profile

Join DevRates and build your public profile from libraries you know and experience positions from projects you've been involved in.

Follow projects and don't miss any news from blogs and twitter on your wall.

Your company is looking for talented developers? Register on DevRates and show your technology stack on your company profile.



No description

User experience

Used technologies not defined

User reviews


The most well known and most frequently used servlet container. Works pretty well for what it does (a pure servlet container), but few, very few people would use this as-is. As a rule of thumb people add tons of libraries to Tomcat (like JSF, JPA, CDI, etc). At some you'll be better off installing a readily made full stack, like the Tomcat based TomEE.

One thing that I really dislike about Tomcat is that it copies the context.xml from a war when it first encounters a particular war and stores it internally. If you deploy a new war with a new context.xml, Tomcat will continue using the old one. The Tomcat developers are a HUGE fan of this feature, but I just don't see the point. Why would one ever want to keep the first version of context.xml encountered and silently ignore newer versions?

Nevertheless, this is -the- hallmark for Java based servers, and every Java professional should have Tomcat experience under his belt.

full review »
Sign in to vote for review score: 2


The only well known and active alternative implementation of JSF is not just an alternative, but a very competitive offering.

In the JSF 1.x days, this used to be the only viable solution (the reference implementation, RI, was terrible and bug ridden back then). With 2.x the situation has improved for the RI (now called Mojarra), but MyFaces still holds its own in a couple of areas.

For instance, dynamic component tree manipulation just doesn't work correctly on Mojarra. On MyFaces it works flawless.

Performance is another big topic. In some versions Myfaces is faster, in some other versions Mojarra. There doesn't seem to be a definite winner here.

An important difference between MyFaces and Mojarra is that MyFaces by default serializes the so-called view state when that is kept on the server. This can become a serious performance bottleneck, but there's an option to switch it off. Incidentally, Mojarra has an option to turn it on.

full review »
Sign in to vote for review score: 2

Really good component library. This one has existed for quite some time and suffers from some minor legacy issues, but nothing really serious. Could be a tad more innovative, that's why I gave it a 9 and not a 10, but still a very good project.

full review »
Sign in to vote for review score: 2


This framework has inspired many other frameworks and is one of the leading contributors of the convention over configuration idea.

Finally tried it out, but I can't really say it's my thing. Too slow (thanks to Ruby) and a bit too magical. Now all (web) frameworks need a touch of magic or else we'll all just be beter of hitting that low-level CGI thing, but in RoR it shifts a little bit too much to the magic side. Thinks like mass-assignment in particular may see great for ease of use and to reduce boilerplate code, but it's a step too far.

full review »
Sign in to vote for review score: 1
Scroll to top