Swing is effectively dead. Oracle will no longer invest in the technology, the preferred way forward is definitely JavaFX (2.0+), it shows a lot of promise for those who still need this type of UI tech.
320 karma · joined May 26, 2011
* Its ability to take advantage of multi-core (good support coming in with Java 8 - 2013) * Its large footprint (to be sorted out in Java 9 - 2015) * Its ability to multi-tenant and have shared memory space etc (for cloud, this improving steadily over time). * Polyglot programming improvements (it's fairly easy to interop with Javascript, Clojure, JRuby, Scala and Groovy today but there are ways to go - chances are Java 9 will bring major improvements here as well).
However, it's got an awful lot going for it so as long as it adjusts to meet the challenges I see it staying as a major VM (if not the dominant one). It's move into the cloud space over 2012 is a clear indicator that it's here to stay.
I'd highly recommend using Matt Raible's JVM web framework evaluation technique and then following up with a prototype in the top two. Time spent up front deciding on the framework that fits you will be time well spent.
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.
---------------------
If you investigate Ola Bini's pyramid where languages fall into static, dynamic and DSL layers you'll see his arguments for what type of programming tasks suite which layers. Java sits firmly in the stable layer, and so do all of its various web frameworks.
As expected for a popular and mature language, Java has a large variety of web frameworks, such as these:
Spring MVC, GWT, Struts 2, Wicket, Tapestry, JSF (and other related “Faces” libraries), Vaadin, Play, Plain old JSP/Servlet
Java has no de facto leader in this space, and this partly stems from Java simply not being an ideal language for rapid web development.
The former leader of the Struts 2 project, a popular Java-based web framework, had this to say on the subject:
"I’ve gone over to the dark side :-) and much prefer to develop in Rails -- for the conciseness mentioned above, but also because I don’t ever have to do a “build” or “deploy” step during my development cycle any more. But you guys and gals need to be reminded that this is the kind of thing you are competing against if you expect to attract Rails developers ... or to avoid even more “previously Java web developer” defectors like me :-). Craig McClanahan, Oct. 23, 2007"(http://markmail.org/thread/qfb5sekad33eobh2)
Java is a compiled language, and as alluded to previously, this means that every time you make a code change to a web application, you have to go through all of these steps:
1. Recompile the Java code. 2. Stop your web server. 3. Redeploy the changes to your web server. 4. Start your web server.
As you can imagine, this wastes an awful lot of time! Especially when you’re making lots of small code changes, such as altering the destinations in a controller or making small changes to the view.
If you’re a seasoned web developer, you’ll know that there are some techniques you can use to try and solve this problem. Most of these approaches rely on some sort of ability to apply code changes without stopping and starting the web server, which is also known as hot deployment. Hot deployment can come in the form of replacing all of the resources (such as an entire WAR file) or just a select few (such as a single JSP page). Unfortunately, hot deployment has never been 100 percent reliable, and the web server often still has to perform expensive recompilation of code.
If you must use a Java-based web framework, I highly recommend products called JRebel and LiveRebel (http://www.zeroturnaround.com/jrebel/). JRebel sits in between your IDE and your web server, and when you make source code changes locally, they’re automatically applied to your running web server through some genuinely impressive JVM trickery (LiveRebel is used for production deploys). It’s basically hot deployment done right, and these tools are seen as industry standards for solving the hot deployment problem.
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.
In the early stages of developing a new product or feature, it’s often wise to keep an open-ended design (with regards to typing) of the user presentation layer. It’s all too easy for a user to demand that a numeric value have decimal precision, or for a list of books to become a list of books and toys instead. Having a statically typed language can be a great hindrance here. If you have to change a list of Book objects into a list of BookOrToy objects, you’d have to change your static types throughout your codebase. Although it’s true that you can always use the base type as the type of objects in container classes (for example, Java’s Object class), this is certainly not seen as a best practice—this is effectively reverting to pregenerics Java. As a result, choosing a web framework that’s based on a language in the dynamic layer is certainly a valid option to investigate.