We are a London Startup, mainly building products off the back of web crawling & data mining, using Java for all our development, whether web or server-side. As our web framework we use Tapestry5, which is a great framework, with fast development times & minimal coding (Howard Lewis Ship has really put a lot of thought into the development of the T5 framework). Server side our crawl infrastructure, and other application processes are all Java. We use hundreds of Java open source libraries, including HBase, Lucene & OpenJPA. Addressing your issues
1) Lack of hosting support - we hire VPS, cloud or dedicated server infra on which we can deploy whatever we want - I don't see how this could be an issue. Even a cheap $10/month VPS gives you root these days 2) Performance issues? I won't get into a performance discussion but unless you've got google levels of traffic it's not worth worrying too much whatever platform/language you choose, a bigger challenge early on is attracting customers ;-) I used to work in banking & Java was performant enough for our high frequency trading infrastructure, where performance really does matter. 3) We have been going 2.5 years now, a lot of what we do is server-side processing and data munching and the open source Java libraries we leveraged along the way really helped us get going, things like HBase, Lucence, Bdb, Natural Language Processing (OpenNLP), Neural Nets (Encog), Stats packages, HTML processing (Jericho, JTidy). I know there are API's and ports of these in other languages, but the Java open source community is enormous, just because it's been around for so long, so it's always easy to find someone who'se done it before.
EDIT (Summary): We knew Java well early on and so used it to prove a market, leveraging open source libraries along the way. Do I think Java the language was a particular competitive advantage to us? No. But do I think any of PHP, Ruby or Python would have been either? No. (Lisp - probably yes! but we don't know it well enough to use professionally). To be honest, our main concern early on is to release early and prove the market, with whatever tools we can use.
Funny that you mention Tapestry 5 and Howard Lewis Ship. I was recently looking for a fast, stateless, Java based web framework (I liked Stripes, but eventually had to settle for Spring). I came across this SO question: http://stackoverflow.com/questions/1303438/why-did-you-stop-...
Why did you stop using Tapestry?Because Howard Lewis Ship is a liar. Lots of reasons but the main one was breaking compatibility between v3 and v4. Just when we solved all those issues v5 came out and broke backwards compatibility again! Just couldn't go through that again.
Ideally, I would like to have a lean version of maven+jetty+spring to implement a web framework.. which should also be deployable to more heavyweight containers like JBoss. I havent figured this part out. Maybe Stripes is the way.
Yes, I am explicitly talking about T5. The SO post refers to T4 and below, although I gather the upgrade path 3 -> 4 -> 5 was non-existant and so pissed some people off (understandably). I guess Howard was trying to just create something better...
I've done apps both in php and in Java and if the app is small it's much more difficult to deploy a Java application than php application.
Most Java deployments are persistent (there is an application in memory which answers requests) and it is prone to memory (or other resource) leaks, while php is widely adopted in shared hosting environment because of its statelessness, even if there is a possible memory leak - in most cases it's not important, only long processing queries might bring it up in php, and it is solved by hosting providers with putting limits to http time.
EDIT (Summary): We knew Java well early on and so used it to prove a market, leveraging open source libraries along the way. Do I think Java the language was a particular competitive advantage to us? No. But do I think any of PHP, Ruby or Python would have been either? No. (Lisp - probably yes! but we don't know it well enough to use professionally). To be honest, our main concern early on is to release early and prove the market, with whatever tools we can use.