Creating custom scrollbars with CSS; How CSS isn’t great for every task What if you, and people like you, volunteered for the police?
Apr 08

Google App Engine and The Java Web; The Wrong Java?

Ajax, Google, HTML, JavaScript Add comments

I had the pleasure of being at the Google Campfire event that launched the worst kept secret, App Engine supports Java and Google has a preview for you to check out if you signup in time.

Java is a huge ecosystem, which is a big win, but what interested me was the nuance. The Secure Data Connector feature that gives us a glimpse of “on premise” type functionality (that Microsoft is touting with Azure) is a big one, and something that enterprises need.

The GWT pitch and the Google plugin for Eclipse is another interesting one. I am always so incredibly torn here. GWT is fantastic technology. Because of the way it works, it gets to do things that pure JavaScript libraries would love to be able to do but can’t. The team is great, and the hard core tech is incredibly impressive. I understand why people use it.

My personal issue is that it feels so funny to see the two messages from Google.

Now, these aren’t mutually exclusive of course. GWT can wrap all of the HTML 5 stuff and both can be happy. But it just feels weird to me. The idea that JavaScript is the assembler of the Web, when it is such a high level language is hard to wrap my mind around. It can be moulded to do so much more than Java can with its static nature (which has downsides too of course!)

Another thing. Writing your applications using Java in this world is about the source code and the language but not about the VM. For me this is hard to wrap my head around too. I get to use a language I *personally* don’t like as much (Java the language) and have it run on a runtime that isn’t as good as the Java VM. Hmm. And, since there isn’t the VM there (on the client, there is with App Engine!), I don’t get the pleasure of writing in any of the very interesting languages available on the JVM (Scala, Clojure, JRuby, Groovy, etc). They have picked the wrong Java for my taste!

Now, Paul Hammant has a very detailed post about building a rich Ruby application on top of AppEngine4J. He flips from a jQuery view to a Ruby client using Swiby to a Ruby Shoes app and beyond. Then, at the end, he says something very interesting:

If Google made changes to GWT to make it a viable thick/desktop/offline technology then AppEngine might shift up a gear with online/offline apps.

Since you are writing Java code, why not ship down a jar file for browsers that support Java (still a fair few) and run the application natively within the browser? Kinda bizarre, but imagine if Gears had been done in Java, and people could add functionality easily that way (this is where Yahoo! BrowserPlus is interesting… how you can write services in Ruby and the like). And now you are sending down a jar, you could write the applications using any JVM language you want. Huh. That would be an interesting direction.

Who knows where this ends. When you get practical though, Google have delivered a nice experience for people that like Java, and that is a large group still.

I am still in the camp of DSLs and lightweight and all that jazz, and agree that one great thing about the Web is that some people can come in and make a change here and there at a very high level and make something their own.

Fun times!

6 Responses to “Google App Engine and The Java Web; The Wrong Java?”

  1. Anshu Mishra Says:

    You may write your app in groovy :-

  2. Michael Says:

    So App Engne good, but GWT bad? I can see your point. However, a lot of web developers really hate JavaScript and its implementations. From a language standpoint, it is so different from the OO languages that most developers live and breathe. Even most of the frameworks out there try to make JavaScript more like an OO language (Prototype/Ruby for example.) And then there are the implementations (browsers.) Being able to write in a true OO language, leveraging tools like Eclipse, and having the implementation differences not only smoothed over, but actually having a compile that aggressively takes advantage of the differences in implementations, is very appealing to many developers.

    I would say that Google’s support for the would-be standards of HTML 5 is optimistic and forward thinking at best. GWT is realistic. Web standards remain a romantic notion. You could give Google credit for backing different strategies, or you could just rack it up to Google being a big company with a lot of different groups who do their own thing.

  3. Joel Webber Says:


    I see where you’re coming from here — it *does* seem a bit odd to cross-compile from one “high-level” language to another. But at the same time, I don’t see GWT and HTML5 evangelism as being in any way antithetical to one another. GWT is simply a tool to help get leverage over a complex Java[script] code base. HTML5 is a collection of browser APIs that we either have already created abstractions for, or will be doing as soon as they’re prevalent enough to be useful. We *love* most of the HTML5 features here on the GWT team, because their adoption will increase the number of cool things we can do in the browser.

    To reiterate a point I keep trying to get out there: GWT doesn’t use Java as a source language because we think it’s the greatest language in the world. It uses Java because (a) it has extremely good tools, and (b) its type system allows us to perform a lot of optimizations that would otherwise be impossible.

    To your point about “other Javas” we could support, I’m pretty excited about Scala support, though at this point it’s more of a twinkle in Lex’s eye than anything else. The other languages you mention would seem less useful in this context, because their dynamic type systems would preclude most interesting optimizations — without a monolithically optimizing compiler in the mix, I’d just as soon write Javascript (opinions may of course differ on that last bit; you’ll find I’m the sort who will happily write code in any language that allows me to get the job done).

    Allow me to humbly submit my blog post from last year for your consideration:


  4. Iein Valdez Says:

    So I presented last night at campfire and think the combination of GWT and Java AppEngine is actually really powerful and productive. See my techblog post about why we’re excited about the combination and why we chose to stay away from hand coding javascript….

  5. Porter Says:

    Considering a number of how-tos have already been published on using Groovy, Scala, Clojure, and you even mention one on using jRuby… I’m not sure where you’re going with the “wrong Java” direction. It’s a Java 1.6 (6) JVM. There are some limitation in terms of threading and file I/O, as well as certain Java APIs (JMS for instance) – other than that – as far as I can tell, anything that runs on the modern JVM is fair game.

    App Engine isn’t a virtualized server, nor is it a v-host. It’s a different animal altogether. That being said – I don’t think you’ll be prevented from using DSLs, and going the lightweight route.

  6. Ray Cromwell Says:

    The problem exists because frankly, the browsers have approached VMs in the wrong fashion. They have decided to standardize on a language syntax, rather than standardize a dynamic-language friendly generic VM. As you clearly realize, on the server side, people love the ability to use any of the favorite languages for development, but on the client, they are effectively forced to use Javascript. Now, why do advocates of open development push so strongly for heterogenous open development on the server, but rebel when anyone suggests developing in a language other than their beloved Javascript? :)

    Cross-compilation to Javascript is the only mechanism for getting new languages on the client VM. Javascript is the only available entry point to V8/TraceMonkey/SquirrelFish’s underlying JIT/VM infrastructure. You don’t just see this with GWT, there are projects that compile Python to JS, Ruby to JS, hybrids like Objective-J. “JS as assembler” is not going to go away until this issue in the browser platform goes away. We are wedded now to decisions made in 1995, which may have been the most efficient way back then, but in the era of super-advanced VMs like V8 look silly. Why should V8’s internals remain tightly bound to a single input syntax when it could be used for other languages?

    On GWT, it is a cross-compiler, and in that regard, there is nothing stopping the GWT team from adding new frontend languages in time. I could forsee a future in which GWT can compile Scala, and other languages to Javascript as well, but not until the Java compilation has reached its limits, which it has not.

    I don’t see the issue between HTML5 and GWT. HTML5 covers the markup, and DOM APIs. GWT can interface to any of these and do so with no overhead whatsoever. The fact that it made feel weird to you is an emotional or aesthetic observation, not a practical one. There are people who may feel that certain constructs in Javascript are ‘weird’ too. I don’t see any legitimate criticism.

    The reason why you don’t ship down a JAR and run it in the Java VM is precisely because of the way GWT works. It is a static ahead-of-time compiler that operates on a closed-world code base, which allows it to perform optimizations that can’t be done on Java bytecode traditionally. This means GWT can prune dead code away that would normally be shipped in the JAR.

    GWT is all about end user experience, reducing latency. Shipping down a JAR full of byte code which can’t be optimized until runtime loading would defeat the purpose of saving bytes on the wire and startup time.

    And, as I talk about in my latest post ( GWT is actually more powerful than Java. I can do things with GWT that you can’t do in Java, like add extension methods to types with zero-overhead.

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'cricket'