"1. Recompile the Java code. 2. Stop your web server. 3. Redeploy the changes to your web server. 4. Start your web server.
...
Unfortunately, hot deployment has never been 100 percent reliable, and the web server often still has to perform expensive recompilation of code."
- Last I checked
i) the hot deployment in Tomcat/Jetty/SBT/etc is pretty solid, especially if we are talking development.
ii) Java supports incremental compilation which means you only need to compile what has been changed, especially if we are still taking development phase again. Unless you compile after making changes to 100+ files, I don't see how expensive this step can be.
"Generally speaking, Java-based web frameworks don’t reliably allow you to have a fast turnaround time for your changes. But that isn’t the only concern with Java-based web frameworks. Another factor that slows down rapid web development is the flexibility of the language, and this is where static typing can be a drawback."
- This argument about dynamic typing faster/better than static typing is just BS. Each offers it's own advantages and can be better/faster depending on where/when/how you apply it and how good a developer are you at actually using their power. Your first example of changing number value to have decimal precision can be achieved in static typing languages like Java/C# just as fast and reliably when one uses refactoring. Your second example of changing list of Book objects to a list of BookOrToy objects, could have been avoided all together by coding to interfaces and not concrete objects. If that has failed, refactoring again solves this.
Not only does hot deployment work almost always, so does in-place compilation of modified code within deployed modules while connected to a remote application server in debug mode.
To both of these points, you still have classloader issues which cannot be resolved (App/Web server vs application classloading). This is one of the reasons that Java 8 is going down the modular Jigsaw route (taking ideas from OSGi along the way). Some web/app servers have put together clever tricks over the years and JRebel also helps, but it's certainly not foolproof.
I'll concede that the static vs dynamic language gap is narrowing in terms of flexibility (and yes BookAndToy is a _very_ contrived example), but dynamic language fans love the fact that you don't have to refactor at all.
FWIW, we've had some problems with hot deployment and Tomcat. After a few of them the VM OOMs. Probably we are doing something wrong or triggering some Tomcat bug, haven't dug deep enough yet.
- Last I checked i) the hot deployment in Tomcat/Jetty/SBT/etc is pretty solid, especially if we are talking development. ii) Java supports incremental compilation which means you only need to compile what has been changed, especially if we are still taking development phase again. Unless you compile after making changes to 100+ files, I don't see how expensive this step can be.
"Generally speaking, Java-based web frameworks don’t reliably allow you to have a fast turnaround time for your changes. But that isn’t the only concern with Java-based web frameworks. Another factor that slows down rapid web development is the flexibility of the language, and this is where static typing can be a drawback."
- This argument about dynamic typing faster/better than static typing is just BS. Each offers it's own advantages and can be better/faster depending on where/when/how you apply it and how good a developer are you at actually using their power. Your first example of changing number value to have decimal precision can be achieved in static typing languages like Java/C# just as fast and reliably when one uses refactoring. Your second example of changing list of Book objects to a list of BookOrToy objects, could have been avoided all together by coding to interfaces and not concrete objects. If that has failed, refactoring again solves this.