Tuesday, May 20, 2008

Java The Next App Engine Language?

When Google released App Engine, Pythonistas were thrilled to receive such high-profile publicity for their favorite language. They should be, since a lot of people are jumping into Python for the first time, (or the first serious time), because they want to work with App Engine. I think that's cool since Python is a great language, but even in this recent dynamic language renaissance for some reason has not received the same hype-factor as Ruby and RoR.

While a somewhat exotic choice on the surface, it was actually perfectly natural and understandable for Google to go with Python out of the gate. It has long been known that Google uses Python behind the scenes for a great many things, from managing the bazillions of servers and other in-house systems to the implementation of Google Code. I mean Guido works there... on App Engine. I'm sure having the language's creator on staff helped when architecting this thing.

It's not all about Python though. Google has said that they are going to be offering the service in other languages in the future, and those who have played with it know about the 'runtime' property in the app.yaml config file. The documentation states plainly that "Additional runtime environments and languages may be supported in the future."

So what's the next supported runtime gonna be? I have no idea, but if I'm going to speculate I think a good case could be made for Java.

At first blush, that seems pretty divergent from the way that the platform is setup right now. Another dynamic, scripty language with a *nix heritage like PHP, Ruby or Perl would be a much closer match as far as management characteristics in a hosted offering like this go. But Google has no history of using any of these languages, and are reported to be pretty averse to language proliferation in their systems.

Steve Yegge blogged recently about how you are only allowed to write C++, Java, Python and JavaScript code at Google. He went into even more detail here. So if Google is going to go with something other than these it would have to be the result of an explicit change in policy.

So minus said policy change, where does that leave us? I'm going to rule C++ out completely out of hand. I welcome comments that can convince me this is a plausible option. JavaScript? If they were going to do a server-side JavaScript thing the implementation would most likely be Rhino anyway, (for all we know the current App Engine is using Jython), so that brings us to Java.

So how reasonable would it be to offer a hosted Java environment? While almost any hosting provider currently gives you the option of running PHP, lots of 'em give you Perl, etc. virtually nobody except boutique hosting providers let you run Java. There's a good reason for this. First of all, Java is an enterprisey language and the apps that use Java on the server side are not especially well suited to run in a shared environment. Secondly, even if the market existed, there are technical limitations that make running Java in a shared resource pool problematic. While you can chroot PHP to prevent people from accessing the shared, underlying filesystem, with Java you can spawn threads and do lots of other things that make implementing resource consumption quotas problematic. The fact that you can't just run a Java program using an Apache module or through CGI, and the fact that there tends to be a mismatch in the skill sets that *nix ops people usually have and the skill set required to effectively manage a Java app just further muddies the waters.

What you would really need is a customizable JVM that let a hosting provider limit what hosted apps are allowed to do. You may be able to do this with a locked down SecurityManager, but doing the kinds of things that Google is doing with the App Engine Python implementation would be even better. Not very many people have the chops to write their own VM. Google is one of them, and oh yeah, they've already sorta done it. Twice.

GWT is interesting in that you write your applications in Java with certain elements of the API stripped out and the compiler translates your code to JavaScript. Android apps are written in Java with certain elements of the API stripped out and the compiler translate your code to run in Dalvik. Why not do something like this for App Engine and make it a trifecta?

Google is pouring a lot of resources into Java lately and in a public way. Guice is getting lots of attention lately as a Spring competitor.

So here's the prediction: The next App Engine language is going to be Java, but with a limited API, utilizing some kind of translation in the compiler and potentially running on something like Dalvik. They will offer a framework like they do with webapp in Python, but based on Guice.

You heard it here first...

16 comments:

ctran said...

dream on :-)

visik7 said...

app engine had require some modification to the python vm to achive google needs so java would follow the same path but java skilled developers are working on andorid right now so
Dream on :)

Anonymous said...

JSR-284: http://jcp.org/en/jsr/detail?id=284

Not that I was working on this before google stole my thunder with appengine. :(

felix said...

Huh! That would be cool, but I'm not convinced. I think Java's fortress is the enterprise and I wonder if the enterprise is ready to move into such an outsourced box with so little control.

AppEngine seems a lot more start-upy - smaller sites that are more purpose driven and have to worry significantly about reaching scale during spikey moments and over the long haul. There I think that PHP is going to be where I put my money (must as I don't love PHP as a language). And I'll vomit if it is Ruby (not that I dislike Ruby, but really...)

I think I'd prefer it to be java, though. :)

Anonymous said...

>> The fact that you can't just run a Java program using an Apache module or through CGI,

What about Wicket?

rock said...

@Anonymous

>>What about Wicket?

What about it?

rock said...

@felix

What do you make of their choice of Java in GWT and Android though?

I don't disagree with you. I think it could very well be PHP or Ruby (sorry). I doubt Perl (double sorry!)

I honestly could also see a server-side JavaScript API. Wouldn't be that crazy. I've done it before with Rhino. They have too according to Yegge. I could see them releasing a Java and JavaScript option simultaneously even...

rock said...

@Anonymous Re: JSR-284

I'm intrigued. What were you working on? What does it mean that the spec lead was from Google?

felix said...

I think Java makes a bunch of sense for GWT and Android. Java's got a firm foothold in the mobile world so it makes sense to bring all them mobile devs over to Android with a little friction as possible. And GWT since even enterprise devs want some AJAXy goodness for their web frontends!

But for AppEngine, unless they're Apple like in their devotion to their languages of choice (which they may be, honestly Python was a pretty odd choice to start with from that perspective) PHP and Ruby are the much more likely choices. Perl, sadly, probably is pretty low in the running. Javascript would be triply odd - trying to leverage those 4 Rhino devs. ;)

rock said...

@felix

4 Rhino devs maybe, but how many client-side JavaScript coders?

If the language syntax is familiar...

cheolho said...

no way it will be java, Java is not an optimal language to build small applications, and is not the epitome of RAD. With the amount of code, and configuration needed for Java, I see this as very unlikely.
I see them going with Ruby with the hype behind it, and the development on the JRuby project, or possibly making a real push for Grails. You heard it here first. Python was a great choice, because you will not get huge Python applications initially , and not get a large amount of developers hosting, as Python, is not as mainstream. But its a great way to see how there systems will scale, and hold up to traffic. Also regardless if that is true to there adversity to other languages.. I really doubt this would be a reason for them not to go with Ruby or Grails. As a software engineer, I can pick up any of these languages easily, and if you can't then change your occupation.

Fahim Ilyas said...

well if its java then surely it will open window of opportunities for so many java developers out there. Honestly i believe that C# 3.0 has become so much stronger as compared to java that i wont switch back to java in future. But good luck for the java developers out there. I think they should support PHP as well because it is very popular these days...

TrashHalo said...

In response to excluding C++ from the choices:

Currently there exists two C++ servlet API's.
CPPSERV
C++ Server Pages

The only way I could see this happening was if each app was executed in a powerful sandbox and if their hosting servers have homogeneous hardware. Both of these issues could be addressed by executing app code inside of virtualized hardware (vbox,vmware,etc) as developers would only have to target that specific virtual machines architecture. The problems with this solution is scalability. These problems are much less severe with a interpreted/byte code language as the interpreter controls the execution environment.

Adam Charnock said...

It may interest you to know that Zend and Google do seem to be talking about providing PHP support in GAE.

For more info:
http://porteightyeight.com/archives/201-PHP-for-Google-App-Engine-in-the-works.html

felix said...

Huh, maybe you're right on about Rhino!

http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html

Lakshman Prasad said...

It's now official, they are! Soon. http://controlenter.in/2008/10/google-developer-day-bangalore-google-app-engine-to-support-java-android-sdk-release-on-oct-22/