Most Java web frameworks try to circumvent Java’s idiosyncrasies (which are painful sometimes).
So your conclusion might be right: Java is the wrong tool for building web apps.

But what if there’s a framework which embraces Java? Does it the Java way?

Hint: Take a look at Wicket.

Here is my response (although posted a month ago) - a blog post that directly discusses the very valid point you raised: many frameworks are built just to improve upon weaknesses in other frameworks.

http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/

Hey Sven. I like the way you’re thinking. The only way to be successful using any tool is to use it for what it was intended, more or less.

The fact I think is that a lot of people are comfortable with Java. Many people also think that writing software for the Web is the way they need to go. So, when the need for a new app comes up, Java’s handy, so they use it.

Java was designed basically to be an easier C++. “Write Once, Run Anywhere” and automatic garbage collection were the two big points.

Java’s still a statically compiled language. It’s still got a relatively slow startup time, which is what necessitates application servers and containers like Tomcat, WebLogic, Jetty etc.

I think that recent developments such as Groovy/Grails, JavaFX and JRuby show the interest in changing the fundamentals of Java. I think Java is moving past cross-platform and automatic garbage collection as its core benefits and really trying to reshape itself from the inside out. I think it’s got to to keep up with all of its competition for building web apps.

The thing to keep in mind is that developers build apps not to serve the language, but to serve a business need. If that need is for a Web-app then you’ve got to look at your situation from that perspective. If you’re focusing on Java as your driving factor then your deliverable and ultimately your business will pay for it, imho.

All that being said, I’m glad you mentioned Apache Wicket. Wicket and JBoss Seam are two of my favorite Java Web-app frameworks. I think they both look at EJB 3.0 as a “reset button” of sorts and are building from that as a baseline. The results are good, moving the framework-space in the right direction.

“The main reason for this is the statically compiled nature of Java. Interpreted languages will give you a much faster and continuous development cycle.”

Not sure what you mean here.
If you are using an IDE, you just run it, you don’t have to compile it.

If you care about quality of the applications you deliver, I don’t see how being able to run an application that doesn’t compile helps.

“I don’t see how being able to run an application that doesn’t compile helps.”

The point isn’t to obviate the need for code to properly compile. The point is that the compilation step slows down the development process. Interpreted languages still require that you code is valid. But the interpretation step is much faster than compiling. Given that the process of tweaking code and reloading a screen to check the changes is something that happens up to a few hundred times a day, this adds up to a significant difference in the overall time to develop an application.

“If you are using an IDE, you just run it, you don’t have to compile it.”

Using an IDE doesn’t mean you don’t have to compile your code. I assume you’re talking about hot-deploying or auto-deploying your code into a servlet container.

True, hot-deploying code speeds up the development cycle in many cases. But it doesn’t always work. For instance, I work on one project with a SOA built using Spring. Spring injects the correct implementation class via a proxy. In this case the usual mechanism that a container such as Tomcat uses to detect and reload a context when classes change fails.

So, in this case:

1. I have to use an IDE (keep in mind that since I write apps in many different languages I need to use different IDEs, which becomes a pain)
2. I suffer the recompile-time penalty no-matter how I slice it, though configuring my servlet container to hot-deploy does help in some cases
3. Integrating certain tools/frameworks into my application can cause this to break, necessitating workarounds and more configuration in order to make everything work together.

The third point is a major point of the thought behind my original post.

And just to be thorough, I do know that Spring can be properly reloaded in a web-app via the refresh() method. There are about 11,000 documents returned by a Google search for “Spring hot-deploy”. I just scanned through the first dozen or so and found a number of posts in which developers struggled to find a workaround to Spring not reloading properly. You could argue that they just didn’t know how to use the tool (Spring) properly in a web app. But that’s part of my point too. With Java so much time is spent figuring out how to make libraries and frameworks work together, or how to tweak them to work the way you need them to in one context or another, that once you’ve figured all that out you’re reluctant to move away from that investment to look for a better tool. The result is an endless series of struggles, searching for just the right set of tweaks and configurations needed to get a Java framework to do what it told you was so easy to do, but failed to do because of the context of your application. I hope that made sense. To put it more simply, building web-applications in Java is just way more complicated than building them in other languages, most notably scripting languages.

One good resource related to this discussion is Sean Kelly’s video comparing Rails, TurboGears, Django, Plone, Java Sevlets/JSP and full fledged J2EE development.

It’s an hour long, and well worth the time spent watching.

Let me just look retrospectively back in time and let you know about my take aways about some of the not really helping web frameworks.

I remember my first big web application was a web based MIS. The technologies and tools we used were JSP, HTML, some java script and java beans. well, the application failed because the UI was so thin and users just didn’t want to replace it with existing keyboard driven rich client applications.
My 2nd big project was an online order processing and inventory management system. For this system struts was there and was really sexy, actually for this project we had a bitter flavor of EJB and struts with OS Workflow for WFM. I had this childish idea that it is going to be the answer for making a richer UI. Well, this time the project didn’t fail but guess what, we ended up with a pile of Java script codes for rich UI components and Struts was like a hurdle each time we wanted to develop something rich. Actually according to Sean’s video that was the first time I realized that there is no quick turn around with J2EE stuff.

Learning from the past experiences for the next big project, that was an ERP, we decided to build up a new framework. The framework ended up to be a master piece using Spring and Hibernate (After retiring CMPs and finally the entire EJBs) Struts, Ajax, DWR, OS Workflow and Velocity for templating. Well, the n-tier architecture was really great so that we could plug in and plug out modules like security, user administration, HR management, Product Management, etc. and reuse them in different projects. Basically, the framework ended up to be a very reconfigurable and extensible service oriented platform. in fact, we reused this framework for two more solutions, a unified messaging system and a multimedia contact center. But still the UI development cycle was the slowest part, even with having so many reusable and reconfigurable ajaxified UI components.

for my last tow projects I have intensively used XML based RESTful API for communicating with the presentation layer. Eventually I have realized that this model has more fun in it than implementing J2ee related stuff in the view layer. Prior to writing this I just watched Sean’s Video, and I do agree with him. But for real complex apps I do not like to go with Python or Zope but rather I would stay with J2EE technologies for the backend but not for the view layer.

To make it more generic, the view layer should be abstract and interoperable with any back-end technology. To rephrase it, the back-end layers must expose their services in such a way to be presentable by scripting languages or according to Sean, by easy to turn around languages.

Happy development and scripting guys,

BTW, you can find me here:
http://loghmani.blogspot.com/