> And PHP is not significantly faster or easier to develop in than java...
Yes it is easier and faster to develop in (speaking as someone who has done both commercially). Examples of productivity gains:
1. No need to compile your code. Build cycle vastly improved (no time wasted with Ant/Maven/take your pick).
2. Less verbosity.
3. No need to restart your web server every time you deploy some new feature, just hit F5 on your browser and your done.
4. No classpath/jar file fun to slow your down.
5. You can hack a code fix in situ on a dev/server (or production if your brave/insane, I did say hack!). All you need is SSH.
6. Connecting to a database is trivial, support for most databases build in (no messing about with JDBC).
7. Deployments are a breeze: just drop the source code on your server, and you're done.
I could go on.
> so you are losing execution speed to gain nothing.
I wouldn't call a much faster development cycle "nothing", and if you understand Facebook's culture of "move fast" as laid down by Zuckerburg, they value development time higher than execution time (and rightly so).
> if you've done Java commercially you've used sub-par tools.
I spent 3 years doing Java on large-scale telco projects using IntellJ, I'm not an amateur Java dev. I now code PHP full-time on a social network.
> 1. any decent IDE will compile as you type
Fine, but my original point was about building for a production environment.
> 2. I'll give you this one
Thanks!
> 3. Java supports dynamic class reloading, it works out of the box with jetty.
You using Jetty with dynamic class loading enabled in production?
> 4. you just press "run" in the ide.
Once again, your local dev environment has nothing to do with production servers (where you obviously won't have an IDE).
> 5. same applies to java, just requires you take your (automatically built) .class file
And what if that .class file is buried in a .jar somewhere, which is in turn buried in a .war somewhere else? Not quite as easy as opening a .php file with vi on the terminal, is it?
> 6. I'm not sure how difficult you think JDBC is.. you just give it the connection string and the driver name.
...and the driver has to be on the class path, and the driver might have local binary dependencies (depending on the vendor), and you have to be careful to ensure that you are using the correct driver .jar version for your version of the database, and ensure that it is packaged up will all of your other project dependencies when you build your .war/.ear etc.
> 7. just drop the war into your servlet directory, and you're done
...after you have built the .war using a build technology like Ant or Maven (I refer you back to my original point 1 about the Java build/deploy cycle being more complex).
so the war is just built trivially by the IDE when you use a webapp type project.
no messing around with the classpath as the war contains all dependent jars.
if you want clean builds you set up something like jenkins (with the automatically generated exported build files).
1) and 3) I was referring to development, you can just code away and hit F5 to see your results the same way in Java you can with PHP.
wrt database jars/binaries: a modern IDE does this all for you too, and is all output into the target war.
You could go on? You are at 1/7 so far, perhaps you should quit while you're ahead. How many decades ago were you developing in java professionally? You don't manually build your code, you don't restart your development web server, are you doing your java development in notepad or what? I've been the sysadmin for big java projects, and a developer on them. I've never had any problems with DB access or "classpath/jar file fun" or deployment in either role. I genuinely have no idea what you are even talking about with the "classpath/jar file" thing, it honestly sounds like something someone who has never used java before might make up.
The only valid point you have is that java is slightly more verbose. But of course, it also prevents a number of bugs that slip into PHP code bases, which I find balances it out. And keep in mind, this is coming from someone who finds java offensive, and refuses to use it any more. You're not dealing with someone who is in love with java, but rather someone who thinks java is a terrible language that should never have been made. It is simply not as bad as PHP.
Yes it is easier and faster to develop in (speaking as someone who has done both commercially). Examples of productivity gains:
1. No need to compile your code. Build cycle vastly improved (no time wasted with Ant/Maven/take your pick).
2. Less verbosity.
3. No need to restart your web server every time you deploy some new feature, just hit F5 on your browser and your done.
4. No classpath/jar file fun to slow your down.
5. You can hack a code fix in situ on a dev/server (or production if your brave/insane, I did say hack!). All you need is SSH.
6. Connecting to a database is trivial, support for most databases build in (no messing about with JDBC).
7. Deployments are a breeze: just drop the source code on your server, and you're done.
I could go on.
> so you are losing execution speed to gain nothing.
I wouldn't call a much faster development cycle "nothing", and if you understand Facebook's culture of "move fast" as laid down by Zuckerburg, they value development time higher than execution time (and rightly so).
* Edited to add line returns.