Posts Tagged Google App Engine

Google Eclipe plugin 1.1.0 available

Logo GWTMiguel Méndez:

We wanted to let all of you know that the Google Plugin for Eclipse 1.1.0 is now available. Some of the notable improvements are:
-Support for Eclipse 3.5 (Galileo)
-GWT RPC interface validation with quick fixes
- App Engine DataNucleus enhancer console no longer steals focus on save

Announcement, Relase Notes

, , ,

No Comments

Google App Engine – Where Does It Fit?

In an interesting article about GAE, Dmitriy Setrakyan points out several limitations of the new Java support in the Google App Engine. Most importantly:

1. You have no control over number of deployment instances.
2. You have no control over load balancing
3. You cannot use any of the existing clustering infrastructure you have

What this means practically is that the GAE is not suited for deployment of large-scale distributed applications, where fine-grained control over how jobs are split and distributed or how threads are managed is necessary.

This doesn’t mean it will not come one day, and I doubt that Google will (forever) leave this part of the market to Amazon. But for now the GAE/J is best for deploying web apps that don’t care about how their infrastructure is managed, only that it is available.

@Gridify Cloud Computing: Google App Engine – Where Does It Fit?.

No Comments

Google App Engine: killing many birds with one stone

Logo Google App EngineAn interesting fact about the new support for Java in the Google App Engine, is that it supports real, standards based Java; in other words it runs JVM bytecode. It might sound like something trivial, but it’s not. In fact, before the announcement many people had speculated that the Java support in GAE would be based on some sort of variant of Java. Maybe they would use only the Java syntax, but not the compiler.

See GWT: on one hand you’re developing in Java, and you’re lead to believe that you are actually writing a Java application, but when the source gets translated for deployment, it’s JavaScript that is generated. There is no trace of Java whatsoever in the code that runs in your browser. Using Java as a source language is just a way to leverage existing tools and developer skills.

See also Android: here it’s not the source code that gets translated to a target code, it’s the compiled JVM bytecode that gets translated to another kind of bytecode, the Dalvik executable bytecode. And the Dalvik bytecode runs in Dalvik VM, Android’s own virtual machine. Again, no trace of Java at runtime. Again, Java is used because of the existing tools and skills.

But apparently, it goes differently with the GAE. It runs true, standard JVM bytecode. It supports WAR deployment, JDO and JPA mapping, etc. This is already a good thing in itself, but there’s an added benefit to this, which is maybe the reason why Google choose to make it this way: it can run bytecode generated by the emerging galaxy of languages that compile to JVM bytecode or run in a JVM, such as JRuby, Groovy, Jython, Scala, and others.

That’s what you call killing many birds with one stone…

, , ,

No Comments

Google Web Toolkit Blog: Introducing GWT 1.6 and friends

Logo GWTBruce Johnson:

Starting today, there is a simpler way to use the JavaTM language to develop and deploy world-scalable web applications. We are very happy to announce today:
- Google Web Toolkit 1.6,
- An early look at Google App Engine for Java, and the brand-new
- Google Plugin for Eclipse that supports a productive integration of the two.

This is really big! Java support for Google App Engine was expected, as was GWT 1.6, but the integration of the two through an Eclipse plugin wasn’t on my radar. I imagine/hope this will boost both the Google App Engine and GWT adoption.

Google Web Toolkit Blog: Introducing GWT 1.6 and friends.

,

No Comments