"For folks outside of Google, there's really no compelling argument to drop Apache Tomcat/Jetty, etc. in favor of OpenGSE's reference servlet engine, but anyone interested in servlet engine and servlet spec compliance would have a fantastic learning resource available to them"
Java the language is ok, but I the culture is dangerous.
There is no single Java culture.
Here's a completely unscientific comparison:
Java: http://www.google.com/codesearch?hl=en&lr=&q=Factory...
Python: http://www.google.com/codesearch?hl=en&lr=&q=Factory...
BTW, I'm not just randomly bashing Java. I've actually been using it since 1995, worked briefly at Sun/Javasoft, started one of the largest Java projects at Google, and used to like programming in it. However, the trend that I've noticed is that I like Java less and less because the culture has fallen into a degenerate process of building towering abstractions. Put simply, their metric of "good" seems to be very different from mine.
It's not my choice "as a language": I can't stand using Java with just a text editor whereas that's very nice with Python for example. I'm talking more about the platform. Spring (the small focused parts of it like IoC and AOP), Hibernate, Terracotta, Lucene, Jetty, YourKit, Clover, and many of the OSGI/JMX deployment solutions are all just polished, productive and out of the way to me with very nice integrations into my IDE. Yeah, IntelliJ -- that's probably a big part of my ability to like Java, to be honest.
I'm with you on the abstractions thing, I've avoided J2EE etc.
Same here and imho that's quite an alarming indicator for the "towering abstractions" that paul mentioned. When you can't realistically navigate a significant codebase without tool support anymore then many of the components just aren't "out of the way" as much as they used to be or should be. Personally I jumped ship when java went through the heights of its XML disease which is apparently cooling down nowadays. The available toolchain (part of which you mentioned) is mighty impressive, no question. But it's the amount of boilerplate- and meta-code required to glue the stuff together that's driving many of us away.
The number of abstractions/libraries seems irrelevant to the discussion if they can indeed be out of your way (you're saying because of all the boilerplate etc. that they aren't, so I guess we're talking about different things). If they're powerful and there's a small surface error for dealing with them then great, that's a high return on investment situation.
Getting to that small surface error takes an IDE sometimes which is unfortunate on some level but I don't find anything fundamentally wrong with it.
Personally, I can't stand even simple programs in Java with a text editor because of the amount of subdirectories you need to suddenly be aware of... org/blah/blah/blah/blah/blah (this is how I learned it originally).
Maybe things have bettered since then but from what I see at least the maven disease seems to still be all over the place. I'm not saying that all these things are necessarily bad. I just grew really tired of juggling monstrous xml blobs around while still being forced to write (or generate) metric tons of boilerplate code.
As far as Python (and dynamic languages in general) goes, I haven't heard any good responses to Ted Dziuba's blog post: http://teddziuba.com/2008/12/python-makes-me-nervous.html I can see that a startup would prefer Python/Ruby to Java, but what about bigger projects?
What definition of "work" are we using?
He also write "As a programmer in a team, you need rules. You need structure. You need order."
Some of us think that the rules matter, that it's not just having rules, but having the right rules.
Ted Dziuba's argument doesn't seem to be Java vs. Python for large projects - it's more statically typed vs. dynamically typed languages and checked vs. run-time exceptions - or compile-time error checking vs. run-time error checking.
There are several large companies that use Python for X and Java for Y. I don't think either language has significant advantages for large projects that the other doesn't have, assuming that developers can utilize the strengths of the language. I was working with someone who wanted to implement a prepaid card application (the ultimate enterprisy app) and his biggest objection to using Python was the inability to find Python developers in India. He was going to pay the bills, and I didn't have a counter-argument.