"Does some QA" and "distributing" have been the most innovative contributions from Canonical to the FOSS world and one of the reasons why Linux is reaching the consumer mainstream.
Maintaining support channels, distribution, testing, QA, and infrastructure are very costly and time-consuming things, but they're the sort of stuff that separate enthusiast products from turnkey and consumer products. This distinction is not at all trivial, and I fill is underestimated by most FOSS enthusiasts since, well, they've never been on the other side of the supply chain.
Basically, commercialization, distribution, integration and support are the most costly parts in most products, more costly than actual development. But it's boring tedious, and standardized, so not deemed to be of interest.
In construction, materials are made to withstand their recommended pressures and load values 30% above what the expected usage will be. It doesn't matter for all practical purposes wether it will stand 30% more or 200% more; what matters is that it goes above 20%. Most constructions could stand double the load they have. Well, in AGW, even 10% of the estimated damage is so great that it merits taking care of it.
Engineers frequently make estimation errors in the order of magnitude, using incredibly precise measuremente tools, and nobody complains. Let's not be fools about this either.
The professional grade alternative is that you drop the half the superfluous bullshit J2EE seems to support and build and honest-to-God web architecture like God intended: shared-nothing workers on the web server and scale out on the database, use job queues that go to a compute farm if you need that. A decent web framework has transactions built-in so I don't even have to think about the problem, SSO is handled with a cookie and a generic backend that plugs to whatever you want, you don't need special clustering techniques because there are no hard dependencies between nodes.
Sorry, but J2EE has absolutely nothing a modern Perl/Python/Ruby framework doesn't have today, except mechanism for managing the inherent complexity of a crappy language with a shitty object model that needs overly complex architecture to make up for its fundamental lack of programming constructs.
You're not going to find equivalents to @Stateless beans, Message-driven beans or any of that bullshit because decent frameworks make managing state something absolutely trivial, not an exercise in frustration that requires configuring 5 XML files and implementing two interfaces just to save an object to a database. Nobody cares about RMI or "messages" because you can make a restful web service with 2 regular expressions and a 15-line Ruby file. Nobody cares about monstrous ORMs that can barely handle programmatic queries when SQLAlchemy does that and with a 20-minute tutorial you're already up and running.
Oh, and just for the record, most people dn't even need to check for memory leaks because they use a language VM that consumes at most 20% of your runtime's resources and does the hard work with C plugins.
Let the scourge of J2EE and "entrerprise" frameworks burn in the underworld.
Oh, and as a scripting language, it is one of the fastest dynamically typed languages available, in the same league as SmallTalk and Lua. The fact that Palm developers obviously used the wrong tool for the wrong job does not in any way detract from the qualities of the language.
Does Java have support for closures and first-class functions?
Does Java support prototypical object orientation
Can Java use hashtables as objects?
This is clearly another case of too many mad scientists, and not enough hunchbacks.