About Java, closures and attracting new developers, part II

(Warning: A web developers perspective.) I've been thinking of this since I wrote the post: About Java, closures and attracting new developers, where I tried to prove that the problem with Java is not related to the lack of closures. At the risk of offending the rest of you, here comes my explanation of why I don't use Java for my spare time projects, even if I like it.

• The web server (I mostly use tomcat 6 at work) takes to long time to restart, so long time that it quickly becomes painful, especially when you add to this that:
• you have to restart it every time you've changed a class.
• The recommended web framework, JSF (JavaServer Faces) doesn't care about URLs. By default it will show the URL from the last page you visited.
• JSF has a really unnecessarily complicated template language. I mean, I can't see the reason for having to use <h:panelgrid> when what you wanted is just <table>. Not to mention that there is no <div> tag in the default component set. Of course, you can just use a component set that has one, (or make your own if you have a couple of hours to spend,) but I guess you see my point.
• JSF messes around with my id's, even if I've not asked it to do that. To get around that limitation you once again has to use a different component set (tomahawk comes to mind).
• You don't have access to the javascript that is used. Of course this is touted as a benefit of using JSF, but in my opinion it's just a horrible violation of the rule about separation of concerns. What happens is that you can't just include that standard well-tested javascript library you want, which means you have to use jsf components again. And guess what: Those components are broken, and it always ends up with a lot of extra work for the designer.
• And of course: JSF isn't the only problem with Java. Take something as simple as how to print a line of text to the console: "System.out.println()", or think about trying to open a file for reading. With execuse to every swede who reads this, we have a childish joke here in Norway that goes like this "How many swedes do you need to change a light bulb?" The answer is 1000, one to hold the bulb, and 999 to turn the house around. Same goes for Java, - how many objects do you need to read a file line by line? Or to resize a picture? (Yes, I know Fabrizio Giudici has tried to defend it, but I do not agree. Often, the Java API's seems way to low level, and my feelig is that sometimes you have to use one factory class on top of another. Also see next point on why this is more of a problem than it could have been.)
• The documentation is also painfully unbalanced: There is a lot of javadoc generated API documentation everywhere, but I can't think of a single place to find something like askeet, -a well thought out demonstration of how to use the api or framework your're providing. (OK. I can remember to have seen som interesting blog posts over at http://weblogs.java.net. Example.)

But yes, I still use Java at work. And I still think Java is a great language, and a great platform. It just lacks a good, full stack web framework with great documentation, running on a fast server that doesn't need to be restarted many times an hour. (Edited: 2008-09-30)

Updated 2008-12-14: Symfony has done it again! More documentation available here: http://www.symfony-project.org/jobeet/1_2/Propel/en/