At CloudForce 2010, we had a session on Force.com for Java developers. We talked about scenarios that are supported by Force.com for Java developers and where the platform is heading with VMforce, with specific examples using JPA.
Today, Java developers can develop applications on Force.com using Force.com for developing apps that use Force.com as a database primarily; for building tools for Force.com or for integration with Force.com applications. These are all use cases that are benefiting from connectivity with WS-APIs and WSC Java toolkit. A lot is gained by doing so, the built in services of Force.com from user management to specific capabilities of Force.com database which allows you to search and use built in analytics are just a few of the examples. However, the deployment of the Java application has to be always somewhere else, not managed by Force.com. This results in replicating and/or consolidating user management, thus security and handling the requirements of the composition elsewhere in another platform. Consequently, the developer needs to manage multiple environments, channel data between hybrid deployments (such as GAE/Force.com or Appserver/Force.com), etc. When it comes to app development, integration of different platforms is not that simple. More is not really merrier :).
This is where VMforce comes in, by giving the developer the capability to develop as well as deploy to Force.com. By allowing the developer to deploy to a web container that is running on its own JVM with multitenant VMforce cloud hosting JVMs, the developer can take advantage of the Force.com features and benefits directly without having to deal with hybrid environments and having to take the hit of developing on multiple platforms or "clouds". Unlike current development approach in Force.com, the developers would be able to develop and debug locally and deploy it to Force.com. As a matter of fact, local development and debugging is a feature that we tried to emphasize during the talk.
VMforce is also being designed to accommodate existing Force.com investment as well. For example, the development of certain features that may benefit from utilizing existing Java libraries can be handled with VMforce where the existing logic and investment in the platform may reside in the application with APEX, VF pages, etc. that can co-exist in the same application. By having the ability to callout between Apex and VMForce, the specific needs of an application can be compartmentalized with appropriate tools, or libraries or even with teams that have specific skills. Several use cases of VMforce and many questions of attendees were addressed in the long Q&A session with Fiaz and Jesper who are responsible for VMforce.
VMforce promises to be a new option for the Java developer by allowing deployment directly within Force.com instead of only thinking of connectivity. As a result, Java developers have another choice for cloud development. VMForce is still in design and development, however I am looking forward to the day when we can provide this functionality as a developer preview for our developers and for Java developers who would like to deploy with Force.com in the near future.