Google App Engine for Java sounds great but contains a fair number of limitations including a lot of unsupported APIs and frameworks. I have documented my experiences with Google App Engine for Java in the form of two blog posts. 3 Tips for Getting Started with Google App Engine for Java is for programmers considering Google App Engine for Java. A Case Study of Google App Engine for Java reviews the use of Google App Engine for Java in developing a new microblogging service and includes developer thoughts on ease of use, costs, and support.
- Posted by: R M
- Posted on: June 15 2009 07:30 EDT
- More case studies! by Roy van Rijn on June 15 2009 17:04 EDT
- bigger issue! by shawn spencer on June 15 2009 19:38 EDT
- Re: More case studies! by ^C^ ^C^ on June 16 2009 01:37 EDT
- Re: More case studies! by Roy van Rijn on June 16 2009 03:11 EDT
- Re: More case studies! by Deepak A on June 16 2009 03:17 EDT
- Re: More case studies! by ^C^ ^C^ on June 16 2009 08:52 EDT
- Cannot access your home page by Dorel Vaida on June 19 2009 01:18 EDT
- Would you consider GAE for your next project? by Pranab Ghosh on June 24 2009 20:55 EDT
- Great info by vanessa calabria on October 27 2009 13:48 EDT
- unsupported APIs and frameworks by du lendo on June 16 2009 05:04 EDT
- More case studies! by Reik Schatz on June 16 2009 06:54 EDT
Good to see more case-studies of people trying out GAE. I've blogged about my experiences too, with Spring (annotations), JPA and Wicket. http://blog.smart-java.nl/blog/index.php/2009/06/05/getting-on-the-cloud/ The biggest issue I have with GAE at the moment is the persistence. Datanucleus is trying hard, but the JPA support is really basic, and shouldn't be called JPA IMHO. You can't have joins, aggregations, or even something as simple as the 'OR' in a query. Hopefully more people using GAE and Datanucleus will drive them to develop it further and extend the support for queries on the cloud.
You have to be very careful with GAE as not all jee features/apis/extensions are not supported by GAE. Its very very confusing and a pain to remember what all to use and what not. Last month a sun offical (you know who) was upset at GAE for breaking the "integrity" of a jee. anyway.. I dont get the business model of google to get into this business of specifics of jee. Why not just be a cloud computing provider of all of jee or all of .net or both ?
My assumption is that GAE is similar to what Google uses internally for their Java web applications. Further, that Google is hoping to acquire companies that do well on their platform and then not have to worry about transitioning the acquired company's technology to Google's technology. In other words, maybe they are tired of acquiring companies that use totally different technologies...just a guess.
that's no different to e.g. j2me. The jee security model has always been a lot of work for very little benefit; most of Googles modifications are down to the need for reliably partitioning different users of the same appserver from each other.
The biggest issue I have with GAE at the moment is the persistence. Datanucleus is trying hard, but the JPA support is really basic, and shouldn't be called JPA IMHO.Can't comment on your blog itself since you insist on people registering, so I'll give your comments here:-P
- DataNucleus (the project) provides core facilities for JDO/JPA and the plugin architecture. DataNucleus actually provides *complete* JPA (and JDO) support for RDBMS. It provides partial support for many other datastores (using the features suitable for the datastore).
- Google write their own plugin for JDO/JPA persistence to BigTable, and it is this that decides which part of JDOQL/JPQL to implement, not DataNucleus.
- Google's AppEngine DataNucleus plugin provides partial JDO and JPA support due to the underlying datastore structure and concepts.
- Future releases of the AppEngine DataNucleus plugin will provide support for more features, providing more complete implementation of the two specs. See their issue tracker.
- JPA (and JPQL) was designed for RDBMS and only RDBMS, so it is unrealistic to expect complete support for a datastore that is not RDBMS.
- JDO (and JDOQL) was designed to be datastore agnostic, and so provides a better fit in many areas to BigTable
Thanks for the heads-up. It wasn't clear which piece was from Datanucleus and which piece was Google. Still, I really hope there will be more features. Of course I understand the underlaying data structure (BigTable) is less suited for JPA, something like the OR-operator isn't specific for RDBMS of course. With a Map/Reduce algorithm you can do this kind of stuff too. Oh, and in Python they have one-on-many and many-on-many working, so technically its possible with the underlaying structure(s) of the cloud.
Yes, GAE's JPA support has been very primitive. Surprisingly there is support for transactions, but in a transaction only one entity instance of a particular type can be updated or persisted to the datastore. However, Local datastore turns out to be useful in developing and testing applications locally before you go live over the BigTable. But, I'm not sure how it works with enormous amount of data and support for map/reduce.
I chose to use JPA because it is much richer and has more features then JDOJust so that people don't get mislead by your statement (from the blog), this is the complete opposite to what I have found and what is exhibited clearly in all comparisons I've seen. I implemented both specs for DataNucleus so have something to base my statement on. Here's a couple of links for your research http://db.apache.org/jdo/jdo_v_jpa.html http://db.apache.org/jdo/jdo_v_jpa_orm.html Sure you may have some reason for choosing JPA and there's no problem with that ... maybe your familiarity with it, or you prefer JPQL for example, but you cannot use "has more features" as any possible reasoning; JDO has many many more features than JPA, and to get you started on what JDO has that JPA doesn't ... fetch groups, fetch group API, metadata API, enhancer API, many ORM relation types not supported by JPA, persist transient fields, datastore transactions, datastore identity, nondurable identity, persistent interfaces, FK constraints, just to name some. --Andy (DataNucleus)
Andy, just a small observation, I was never able to access the data nucleus home page (e.g. the link in your signature now). I'm also a follower on GAE discussion list so I have tried to get to the DataNucleus site before and never succeeded. The page won't simply load. Any thoughts on that ? :-)
I was never able to access the data nucleus home pageWorks for me, clearly ;-) Either of http://www.datanucleus.org http://www.datanucleus.com
Have you considered it for a project? What's been your decision and why? Pranab
Thanks for your share. petites annonces
unsupported APIs and frameworks. --------------------------------------------------- for example,package java.net.*,and so on. but for all that GAE is pretty so much to me.
When I tried a while ago, I found it very limited and surprising too. http://javasplitter.blogspot.com/2009/05/how-to-google-app-enginefy-your.html I guess it will be better and better over time. Maybe it was too early to make it public.