說明一下個人的看法。

Java當紅，主要是因為當初提供J2EE(現在改叫Java EE)的分散式架構，所以很多大企業認為擴充性足夠，因此投入Java的懷抱中，這些企業到現在也都沒有後悔，像許多銀行的大型網站，背後都是跑J2EE，用的是高檔的Application Server(如Weblogic)，因其本身就提供可擴充性，這部分除非成本考量，否則一時半刻是不考慮轉到雲端的。

回過頭來看，許多中、小型的網站，也用了J2EE架構的「一部分」，就是用了JSP, Servlet或Structs、Spring等基礎架構，但沒全面用到Application Server(就是直接用Apache啦！)，這時，轉移到雲端就有其利基了，因為不必再維護伺服器的基礎架構，而且可以無限擴充，當然主要是省錢。

再看看Google App Engine提供的的Java版本，主要有三大功能，我剛看完，一、資料的儲存、二、快取的應用、三、Google權限的整合。後兩者，如同樓上所說，Google的作法是，找到JSR(Java社群共同討論的規格)並加以實作，所以的確要轉換並不難。

問題出在一、資料的儲存，大家都知道，過去放在資料庫的檔案，在Java中，除了透過JDBC外，還有使用OR(Object Relation) Mapping的工具，先前當紅是EJB，最近當紅的就屬Hibernate，後來這些慢慢整合入JDO的規格之中，也就說是，如果符合JDO的最新規格，原則上舊程式只是換換語法，改變OR Mapping層的機制，其他部分程式自然不需太多更改。

不過，目前Google App Engine的JDO支援，少掉了最重要的JOIN及多對多的對應，如此一來，如果要轉換的程式中，使用到JOIN或多對多對應的功能，那麼在轉換上就要花很大的工夫，這工夫大到要改掉整個資料層的結構，把JOIN變成物件關聯，把多對多換成二個一對多，同時，所有相關的資料存取Query/Update/Delete都要全部跟著改寫一遍。這工夫太大了，幾乎只有UI部分留下，而且一旦改動資料層，所有測試都要重來一遍，客戶要付出的代價也相對慘痛。

所以結論是，舊有案子，轉換要花的工夫，約當等於重來一遍，這部分利基真的很小，而如果是新案子，一開始講明架在Google App Engine上，那麼方案算可行，不過這部分的競爭對手又是Amazon EC2跟其他的雲端平台，Google App Engine目前除了免費外，誘因實在太小，所以沒有太多公司在願意這階段投入是合理的。