Java and I go way back. It was the first language I ‘went steady with’ when I started my professional career after graduating from college (contrary to popular belief, I’m not illiterate) and it was love at first sight. We were a steady, reliable couple for many years and I was even at the 2000 JavaOne conference where they announced the ruling to breakup Microsoft during its long antitrust saga (to wild audience applause I might add). Eventually though we started to drift apart. “It’s not me – it’s you” was my diagnosis. Java had become too bloated, complex and just plain hard to code for my taste. I obviously wasn’t the only one of that opinion and though Java (rightfully) retains its preeminence as THE enterprise development language, there are now a plethora of languages and platforms that are more efficient for specific use cases. Want to develop a scalable, secure enterprise app 5x faster at 1/2 the cost? Try the Force.com platform. Developing a cutting-edge B2C web app? Try Ruby/Rails. Developing a massive event driven app? Try Node.js. Need massive concurrency? Try Clojure.  And the list goes on. Note that many of these languages run on a JVM (Scala, Groovy, Clojure etc.) and so its important to separate the Java Platform from the language.

After a couple of years of being just “friends”, I’ve been giving Java a new look lately. Its partly because of the many great attempts to address Java’s bloat/low developer productivity issue (Spring Roo comes to mind) and partly because of my recent interest in Android. I didn’t however want to go back to the old ‘classpath hell’ and so I started playing around with a couple of new Java Frameworks that have recently gained prominence. Today, there are many great Java web frameworks to chose from, but the one that really caught my fancy is Play! – a web application framework for Java (and Scala). There are many great resources on the web that describe the virtues of Play better than I even could, but for me the attraction was very simple. Play makes it fun to code in Java. It has a low learning curve for an old Java hack like myself, has some great abstractions for things like JPA and dramatically reduces the develop/test/deploy cycle. In short, it borrows the best things from languages like Ruby/Rails (e.g. Shared Nothing architecture, creating default scaffolding) and Groovy (a cool template system) while still retaining the best things about Java (rock solid, enterprise strength scalability and security, great external libraries and developer community etc.).

My weekend project for the last couple of weeks has been a simple Play application that integrates with Force.com using OAuth and the Force.com REST API. I’ve posted the application to GitHub and you can download it here. The application is a super simple web app that uses OAuth 2.0 to authenticate the user with Force.com and then uses the REST API to display a list of Account records. It certainly won’t win any awards for creativity, but I just wanted to get the basic plumbing between Play and Force.com working.  Here are some of the highlights of the application :

• The application requires the user to login to Force.com using OAuth 2.0. The OAuth authentication code is encapsulated in the generic ‘ForceDotComOAuth2’ class and anyone developing a Play application that needs to authenticate with Force.com can simply reuse that class and save some development time (Note: While Play does have a OAuth 2.0 library, it doesn’t work with the Force.com OAuth implementation). One of the key principles of the Play framework is the Shared Nothing architecture which requires your web app to be as stateless as possible. Developing a web app using the Shared Nothing architecture can be tricky if you come from the old Servlet world of storing any and everything in the user Session (or come from the Force.com world where session management is handled for you).  The ‘ForceDotComOAuth2’ class has a couple of features that makes it easier to develop a stateless Play application that integrates with Force.com. It uses the Play Memcached based caching mechanism to maintain the user’s Force.com OAuth session between multiple browser calls. It also has an optional ‘Remember me’ configuration option (‘sfdc.persistentSession’ ) that if enabled, will persist the user’s OAuth Refresh Token across multiple browser sessions (it uses Cookies and JPA under the covers). With the ‘Remember Me’ option enabled, the user does not have to login to Force.com every time they access the application. Finally, the ‘ForceDotComOAuth2’ class also implements the OAuth 2.0 Refresh Token flow so that you can get a fresh access token without having the user log in again.

• Once the user has logged in, the other part of the application uses the Force.com REST API to query some Account records. Given the inherent simplicity of the REST API, there is not much code to highlight or discuss, but you can look at it in the Application.java class.
• The sample application is completely runtime agnostic. You could run it on a local machine, or deploy it to a cloud platform that supports the Play framework.