Java

On Wednesday November 9, 2011 I’ll be presenting “Running Java, Play! and Scala Apps on the Cloud” at the Dallas Java User Group. If you are in the Dallas area then I hope to see you there!

Update: I’ve posted a new video showing how to create and run Play2 apps in IntelliJ.

JetBrains just announced that they have posted a new EAP release of IntelliJ IDEA that supports Play Framework apps! Here is a quick video I recorded that shows how to get IntelliJ setup with a Play app:

Thanks JetBrains! This is awesome stuff!

This week I’m starting a Java User Group tour where I’ll be travelling to JUGs around the US (or maybe world). On the tour I’ll be giving a talk about Running Java, Play! and Scala Apps on the Cloud. Here is the description:

Heroku is a Polyglot Cloud Application Platform that makes it easy to deploy Java, Play! and Scala apps on the cloud. Deployment is as simple as doing a “git push”. This session will teach you how to instantly deploy and scale Java, Play! and Scala apps on Heroku.

I’ve been intrigued by Akka for a while but finally I was able to take it for a spin. The first thing I wanted to learn was how to compose Futures. Composing Futures provides a way to do two (or more) things at the same time and then wait until they are done. Typically in Java this would be done with a <del datetime="2011-09-23T22:23:58+00:00">CyclicBarrier</del> ExecutorService. But setting up the code to manage a CyclicBarrier is challenging. (UPDATE: Turns out it’s not very challenging, I just didn’t know how to do it. I’m new to concurrency in Java and didn’t find much on this stuff - probably because I didn’t even know what to search for.) So I put together a quick little demo that shows how to do the same thing with Futures in Akka.

Here is a quick screencast that shows how to instantly deploy Java web applications on the cloud with Heroku.

If you want more than a quick introduction check out a recording of my presentation at JavaZone. And visit heroku.com/java for more details on how to get started running Java apps on Heroku.

UPDATE: I’ve released a S3 Play Module based on this project.

A couple of questions [1, 2] on StackOverflow.com led me to look into how we can send file uploads in a Play Framework application to Amazon S3 instead of the local disk. For applications running on Heroku this is especially important because the local disk is not persistent. Persistent disk storage makes it hard to scale apps. Instead of using the file system, it’s better to use an external service which is independent of the web tier.

Next week I am speaking in Oslo at JavaZone about deploying Java and Play! Framework apps on the Cloud. I submitted the session before Heroku for Java was available so I had to obfuscate the title and description. If you are at JavaZone then I hope to see you at my “Deploying Apps on Heroku” session!

Today Heroku announced that Java is now supported on the Heroku Cloud Application Platform! This is incredibly exciting news and I’m very lucky to be a Heroku for Java Developer Evangelist!

Joining salesforce.com and jumping into the the Java Cloud space holds some nostalgia for me. When I began using Java in 1997 I was working at an ISP in Denver. We did the regular web hosting thing, but when the first Java Servlet engines (like Java Web Server 1.0) came out, I created the “wantjava.com” hosting service. Things were really nasty at first. We could only run one instance of the JWS on a server so I came up with a really bad way to do “multi-tenancy”. I setup a cron job to rsync the customers’ .class files into the server’s webapp and then restart the server. Customers had to email me to get a servlet added to the web.xml file. Uggg… I feel like I need to go to confession for this. But it worked and as the Servlet containers improved we quickly migrated to a more sustainable model.

Have you ever thought about why in Java we package up web apps into WAR files (or WAR directory structures)? It certainly is a convenient way to move an application and its dependencies from one place to another. But wouldn’t it be nice if everything could just stay in its original location and there wouldn’t be any moving of files around? Wouldn’t it also be nice if you specified your required version of Jetty or Tomcat just like you do with every other dependency? The WAR-less approach is one that is catching on as emerging Java web frameworks like Play! ditch the WAR files. With standard Java web apps we can also ditch the WAR files by simply launching an embedded Jetty or Tomcat server. Let’s give this a try and see how it goes.

I’m very excited to be presenting at Dreamforce (salesforce.com’s anual conference) this year! On Thursday, September 1, from 1:15 pm to 2:15 pm I will be presenting:

Developing Java Cloud Apps

The cloud makes it easy to deploy highly scalable apps in an instant. This session will walk you through the steps to build your first Java app for the cloud. You’ll also learn best practices for building mission-critical and horizontally scalable Java cloud apps.