I sold a Java-based program for about four years and have a previous background in Big Freaking Enterprise Java Web Development.
You can certainly write web applications in Java. They're harder to deploy than PHP but easier to deploy than Rails, in my experience, depending heavily on how experienced you are at administering systems and how much Java enterprise coffee you want to drink.
Java is a mature language. Libraries exist for almost any task you reasonably want to accomplish. There are skilled Java-speaking programmers in your area. Whatever you doing has almost certainly been done in Java already, and it has probably already been documented extensively. Java is an opinionated language: it is of the opinion that your workflow should resemble IBM's more than it does 37Signals', and if that is true, you and Java will get along nicely together.
There, mandatory praise out of the way. Java is horrifically maladapted to certain classes of problems and certain classes of users. One class of problem is expressively operating on strings to produce other strings. One class of users is anybody with a team size less than ten. Many web startups have a small team which is primarily interested in turning strings into other strings: if this is you, Java is going to fight you every step of the way.
99% of web application development for a certain type of business is turning strings into other strings. Many web development languages/frameworks popular with startups give you very expressive options for churning out certain types of strings quickly and with little cognitive load. For example, in Rails, there is very vanishingly little work in taking a bunch of strings from the blog_posts table and turning them into strings which encode a blog post into HTML. And if you want to add special strings that cause comments to be loaded in an AJAXy fashion, that is quick, too. Want to make sure that the strings the user is commenting with include certain strings which look like email addresses? Add one line to your program, and bam, if someone puts in a bad string they get a red string telling them how to make it a good string. It is all string rainbows and string unicorns. If you fat-finger your one line, it is very possible that large portions of your site will instantly break, but that is OK because if you program like everyone else using Rails programs, your magic guardian angel strings will get your attention before you deploy, and after you fix your typo everything is rainbows and unicorns again.
There are many Java frameworks. They can all operate on strings and produce other strings. However, the experience of actually doing this is maddening: pulling off the above you-give-me-bad-strings-I-give-you-red-strings can be a matter of touching six files or more, often written in painstaking configuration formats. The frameworks assume you are guilty of incompetence and force you to repeatedly prove you are otherwise, the better to prevent idiots like you from taking the site down.
This is a problem for startups because web startups are not about turning strings into other strings: that is just what they do. Web startups are about finding a problem people will pay money to solve. That is where they ideally spend most of their efforts. Sometimes, those explorations require code to be written, and when code gets written it should be quick to write, quick to test, quick to deploy, and quick to rip out when you discover your users don't respond the way you thought they would.
Java as it is practiced in the real world looks at that list of requirements and sees Very Scary Things.
They're harder to deploy than PHP but easier to deploy than Rails, in my experience, depending heavily on how experienced you are at administering systems and how much Java enterprise coffee you want to drink.
Have you tried Phusion Passenger (http://www.modrails.com/)? It is trivial to install and makes Rails deployment a snap.
Or you can do what heroku does, and use thin. Just gem install it, and start it. Java has a similar approach with jetty. Both solutions are inadequate, at least standalone, as you get a few more users or require more security/performance. But for starting, it is simple and easy.
I'm curious as to why you would call Java easier to deploy than Rails.
Having developed both Java EE applications and Rails applications, Rails to me was much more easier to deploy, without having to deal with installing Tomcat and going through the extensive server configurations.
Java for most startups won't be Java EE. My best experience with Java recently has been with Jetty as an application server. It's fast and it's lightweight.
I usually run Jetty behind nginx and don't generally need to configure Jetty to do anything.
The whole Tomcat and connectors for apache configuration from a few years ago is well and truly behind me.
I think one major difference/hurdle of java web development and deployment is the fact that you HAVE to setup something like nginx in front of the app server or else you're working on port 8080 for everything. Or you have to know how to configure the app server for port 80 directly and mitigate the security concerns of doing so. By comparison, apache defaults to port 80, no tricks required.
Apache forks a child process with lower rights than root. App servers that run on port 80 do not without a native JNI lancher. The solution is native launcher, a router rule or iptables.
I think the parent is talking about living in a chmod 777 world. Or maybe he is tired of crazy symlink hacks so that sftp becomes an option. Some appservers put class cache in WEB-INF by default, etc.
See my post below: a non-priv'd user can't start the java app server on a port sub-1024 unless you mess with the OS to allow it. I just double checked with my jetty install and I got a "java.net.SocketException: Permission denied".
Actually it isn't trivial for java webservers. Only root processes are allowed to use a port <=1024 by default, so you can't just change a config line in tomcat/jboss/jetty and have it work automatically. You would have to then start/run the app as root, which is a Bad Idea, or mess with getting the OS to allow you to use a lower port. The safest solution then is to have something in front that is allowed on port 80 and setup forwarding to 8080.
Play is seriously, seriously good. We used to build on top of a fairly heavy but powerful stack of Spring, Hibernate and Struts2/Wicket (depending on the app). Although there's a lot of power there there's also a lot of tangled XML and you need to do a fair amount of gymnastics to get through it all. Server restarts are common and painful. Getting exception stacks that run 200 classes deep are IMHO a bad sign.
Play is a total breath of fresh air. REALLY well thought out, clean, simple, fast:
- almost no server restarts needed,
- runs very very quickly in production
- stateless, so zero downtime deployments are trivial
- great community
- extendable with modules
Then there are all the little things. Libraries to do things like encryption and image resizing are built in and just work. Everything just works.
I can't recommend it enough. It really does liberate Java from the Enterprise shackles.
I'm an experienced Java developer, but a bit of a novice when it comes to webapps on Java. I've tried Java EE, Spring, Hibernate, etc and hated all of them with a passion. For writing simple apps it was a mountain of configuration and framework.
I've got to agree that Play is a breath of fresh air. It doesn't hide/automate as much as RoR, which I appreciate. It's really easy to get going with and it's made writing web apps feel quite natural.
It does scale, believe me. In order to scale you have to be able to load balance to accommodate a higher load.
Using exceptions for flow management doesn't prevent you from adding more boxes. If you're thinking it can cause performances problems, I have an app in prod; here are some numbers:
* With a single box, we can do about 500 req/s for a dynamic page, accessing the database
* It appears that the bottleneck is the template engine. If we cache the result (thus serving a "pseudo static" page) the exceptions-based control flow is still there but we serve up to 1000 req/s. (That's more than Apache can do to serve static content on the same machine).
Sort of. I absolutely love Clojure myself and use it anytime I have the slightest excuse to, but I really feel one of its major shortcomings is the lack of a good templating library.
Hiccup is really clean and concise, but it's just not a practical real-world way to handle presentation of a website unless you want everyone writing html to know Clojure.
Enlive and Fleet are other options and I've briefly explored both at certain points, but I personally just found them both unwieldy and unnatural, with other disadvantages as well. I'm sure they suit the needs of some people but I dismissed them before I got past the minimal learning curve.
The same goes for StringTemplate. It seems really cool and everything, but I just don't want to have to learn (and use half the time) a whole new different syntax just to stick dynamic strings in a page.
PHP just makes it so damn easy that it's hard for me to pass up when it comes to churning out webpages.
You can certainly write web applications in Java. They're harder to deploy than PHP but easier to deploy than Rails, in my experience, depending heavily on how experienced you are at administering systems and how much Java enterprise coffee you want to drink.
Java is a mature language. Libraries exist for almost any task you reasonably want to accomplish. There are skilled Java-speaking programmers in your area. Whatever you doing has almost certainly been done in Java already, and it has probably already been documented extensively. Java is an opinionated language: it is of the opinion that your workflow should resemble IBM's more than it does 37Signals', and if that is true, you and Java will get along nicely together.
There, mandatory praise out of the way. Java is horrifically maladapted to certain classes of problems and certain classes of users. One class of problem is expressively operating on strings to produce other strings. One class of users is anybody with a team size less than ten. Many web startups have a small team which is primarily interested in turning strings into other strings: if this is you, Java is going to fight you every step of the way.
99% of web application development for a certain type of business is turning strings into other strings. Many web development languages/frameworks popular with startups give you very expressive options for churning out certain types of strings quickly and with little cognitive load. For example, in Rails, there is very vanishingly little work in taking a bunch of strings from the blog_posts table and turning them into strings which encode a blog post into HTML. And if you want to add special strings that cause comments to be loaded in an AJAXy fashion, that is quick, too. Want to make sure that the strings the user is commenting with include certain strings which look like email addresses? Add one line to your program, and bam, if someone puts in a bad string they get a red string telling them how to make it a good string. It is all string rainbows and string unicorns. If you fat-finger your one line, it is very possible that large portions of your site will instantly break, but that is OK because if you program like everyone else using Rails programs, your magic guardian angel strings will get your attention before you deploy, and after you fix your typo everything is rainbows and unicorns again.
There are many Java frameworks. They can all operate on strings and produce other strings. However, the experience of actually doing this is maddening: pulling off the above you-give-me-bad-strings-I-give-you-red-strings can be a matter of touching six files or more, often written in painstaking configuration formats. The frameworks assume you are guilty of incompetence and force you to repeatedly prove you are otherwise, the better to prevent idiots like you from taking the site down.
This is a problem for startups because web startups are not about turning strings into other strings: that is just what they do. Web startups are about finding a problem people will pay money to solve. That is where they ideally spend most of their efforts. Sometimes, those explorations require code to be written, and when code gets written it should be quick to write, quick to test, quick to deploy, and quick to rip out when you discover your users don't respond the way you thought they would.
Java as it is practiced in the real world looks at that list of requirements and sees Very Scary Things.