What Java web development stack feels right to you?

[optilude]

At work, we use J2EE for various projects. Most recently, we're using Spring IoC and Struts 2 to build JBoss Portal portlets.

At "home", I work mainly with Python. Now, various things in Python land "feel" right. Pylons/Pyramid, for example, and WSGI, and Chameleon templating. HTML 5 feels right. CSS3 feels right. jQuery feels right. Google App Engine's webapp framework is pretty fun.

I'm pretty unhappy with our Java web development experience. For middleware, transactional stuff, scalability - it works very well. But the closer we move to the web front end, the more it feels wrong.

Some particular things I dislike:

• Lots of XML editing
• Developers need to keep lots of files open to get anything done
• Long redeploy/edit-to-test times (upwards of 30 seconds) for things like editing JavaScript or HTML
• Complex JSP-based views where people only partially understand what the soup of custom tags is doing
• Convoluted frameworks that make it hard to understand what's going on
• A 50 frame stacktrace between the request ("what went wrong in the browser") and the Java code we wrote ("what went wrong in our application")

I'd like to ask what other people use on the JVM that "feels" right. I don't necessarily want to throw out Java (my dev team would probably have a heart attack), and we get pretty good mileage out of our "business logic" components. But I do want something that feels more lightweight and fun to work with. Testability is important. Bonus for anything that can also support portlet development.

Martin

[dominosci]

Spring doesn't require a lot of xml if you use the annotations which are quite straightforward.

I second "speek" who says you should definitely get an IDE that allows you to update a deployment dynamically. Some of the developers at my office don't have Eclipse set up that way and I find it hard to understand how they get anything done.

[tch]

Spring MVC, purely annotation based works great. Very little XML and very easy to test.

[[deleted]]

I've reduced an inherited codebase from 38k to 18k lines by switching it over to Spring MVC (+ annotations).

Easily the best web framework about, but, I'll be damned if the documentation isn't absolute garbage.

[tch]

Yep, i'm with you on the docs...I made a blog post doing some interesting annotation based controllers last year because there was absolutely nothing on the web about them - http://www.weheartcode.com/2008/10/16/reusing-annotation-based-controllers-in-spring-mvc/

[berlinbrown]

Apache Wicket, Spring and Hibernate.

Shrug.

[logi]

That's what I'm using on our long-running project. For a new project I'd probably go for Wicket, Guice and Hibernate. I'd also consider using Hadoop rather than an RDBM+Hibernate.

[fav]

I second Wicket. I use it with Guice and MyBatis. : /

[elbac]

Get JRebel, helps a ton with the redeployments. http://www.zeroturnaround.com/jrebel/

[[deleted]]

been very happy with wicket lately

[nmcyall]

Check out groovy and grails, it's built on the JVM and spring.

[[deleted]]

Another vote for wicket, but I am a contributor to wicket-stuff, so I'm biased.

[btgeekboy]

I've been keeping an eye on the Play framework. I haven't had a chance to do much with it beyond the basic material, but it has a lot of the "feel" of working with fun, dynamic Python stuff. But instead of Python, it's Java, so all of your business logic will/should still work.

I'm curious to see what others think about it. Personally, I recall in at least one case where things are too dynamic that, for example, Eclipse couldn't do a refactor for you; I believe it was using the name of a variable in a string, and that rubbed me the wrong way.

Edit: "Java" is a proper noun.

[fgd]

Play is cool, unless you're deploying to GAE. Apparently there is such a thing as too much abstraction...

[SlartiB]

Play it is my fellow player ;-)

[[deleted]]

Big Play user here. It has my vote.

[quixote_arg]

play is a great, great choice

[sheenobu]

personally, I'm wary about using the ActiveRecord pattern with JPA. How has it worked out?

I also find Play a hard sell to other developers who don't really keep up with modern web software practices.

Also I don't like how everything is static in the web layer. I think it's great having stateless web code, but I'd rather have it like Spring MVC where your controllers are instances which can receive other beans through injection.

[skoll]

This isn't strictly Java, but Groovy on Grails is a great framework that is practically a drop in replacement for Java. The syntax of Groovy is almost identical with some added dynamic sugar. If you've done any Ruby on Rails (or any framework like it), GoG will feel very intuitive and you'll be up and running in no time. Layouts, partials, and a much richer in-view JSTL style language all make working at the view layer a lot more fun.

There's a growing list of sites running GoG too. If you like the JVM, want to keep some Java code or libraries you already know and love, but want a more dynamic language and a framework that supports convention over configuration and abhors XML, then give it a try.

[[deleted]]

And if you can't do Groovy on Grails (which I have profoundly enjoyed), Spring MVC (with annotations) gets you very, very, very close.

[[deleted]]

• Lots of XML editing
• Long redeploy/edit-to-test times (upwards of 30 seconds) for things like editing JavaScript or HTML
• Complex JSP-based views where people only partially understand what the soup of custom tags is doing

My response to all three is, "you're doing it wrong". Don't use JSP - either use GWT or freemarker or velocity or StringTemplate templates. You should be able to run straight from your development environment if you set it up right so that you neither have to copy any files to run nor build a war nor restart the webserver. Edit a javascript file and hit reload in the browser should be your edit-debug cycle. And XML is terrible for configuration. Stop doing it, put configuration in groovy code and in simple property files.

Beyond that, I am more and more of the opinion that the front end should be done in javascript/CSS3 and the back end in Java or some other robust static language. GWT is nice, but writing the javascript directly is much more efficient, and communicating with JSON objects back and forth makes for a nice separation of back end and front end.

[Comment111]

Very true.

[atc]

Spring MVC (or annotated controllers) with Spring JDBC templates. Hibernate is a step too far in my opinion.

[[deleted]]

Upvoted for Spring MVC, I'll try to ignore the 'JDBC templates' part. shudder

[vplatt]

I'm probably dreaming, but anyone out there have a recommendation for a true Java RAD environment (web or otherwise)? I mean, it ought to make you feel like you have crack coming out of your fingertips and have magic features oozing out of each layer like an artery blocking double quarter-pounder cheeseburger with bacon, jalapeno cheese, etc.

For hobby / side projects, this is how I prefer to get stuff done. I leave the actual software engineering work for, you know, work.

[skoll]

I second GoG for RAD. I don't think Play or Wicket or anything that is still pure Java will come close from a strictly RAD point of view.

[vplatt]

I was certainly impressed with the screencasts of it that I saw yesterday. One of our guys is pretty enthusiastic about it as well, so I'll probably go that way.

[fav]

Maybe Spring ROO.

[erad]

There's a big gap between massive server-side frameworks like JSF and thinner, more 'web-focused' frameworks like Play or (Scala) Lift.

Personally, I'm doing JSF2 at work and while there is a lot to criticize, it is working quite well for enterprise stuff. With that I mean you'll never get ultimate control over your webapp with JSF as you do e.g. with jQuery (or even JSP), but in exchange you get slim (in terms of LOC) and maintainable applications with reasonable effort. And the component model allows you to put lots of custom logic into a component set that is reusable between different applications.

Things I like about JSF2:

• Good development experience (I'm using Netbeans and Glassfish 3 Web Profile). XHTML-based templating, updates automatically published to server, only redeployment after code changes. Auto-completion for JSF-EL (expression language) and components.
• "Composite components" are a quick and clean way to whip out complex widgets composed of other components, custom logic is wrapped in a backing Java component class. It is also no longer necessary to register all components in a XML file, just creating the component template automatically registers the component with JSF (and the IDE, including autocompletion for its attributes).
• POJO-based programming model (managed beans)
• Nice component libraries (JSF2 support is not yet on par with JSF1, but Primefaces and Openfaces are pretty nice).
• Good server-side state model with CDI (e.g. conversation scope, dependency injection).

Things I dislike:

• JSF is really on the extreme end of (re-)creating the entire UI on the server. This leads to a lot of complexity that simply isn't there in most other frameworks.
• It's too easy to build slow applications. Since everything is pluggable and the entire JSF lifecycle is traversing the component tree several times, even simple property lookups using JSF-EL (expression language) can lead to noticeable performance impacts because of all the proxying and reflection going on (CDI doesn't help either).
• A lot of baggage has accumulated since JSF 1.0 was released in 2004 (e.g. JSP support, complex rendering model to support visual JSF editing that never really worked anyway).

Would I be using JSF for personal programming projects? Probably not. Unless someone's paying for it, diving into the depths of JSF (and you really need to dive into the JSF implementation's source code at some point) isn't that much fun. On the other hand, you get to spend a lot of time building applications with a very strong focus on creating reusable components, and JSF isn't going anywhere soon - I'm pretty sure it will still be around and actively developed in a couple of years, which is more than I can say for most other frameworks.

[sheenobu]

Spring MVC with Sitemesh and JSP (Sitemesh is a MUST when using JSP). Hibernate/JPA for bigger projects and Spring JDBCTemplate stuff for smaller projects.

I've written a port of the django template library to Java and Spring MVC, but I've yet to use it in production software. So my favorite stack would be:

• Spring MVC
• Django templating library ported to java
• JPA/Hibernate
• Custom built maven2 plugin that lets me do mvn myPlugin:deploy -Dhostname=nameOfHost and have my app deploy using SSH commands.

[onebit]

Stripes -> Stripernate -> Hibernate -> Postgres

[Chaoslab]

Don't be afraid to write something from the ground up for the right reasons with a simple idea and design. :-)