Key Quotes from Java API Copyright Case between Oracle and Google

May 17, 2014

Posted by Jerome Louvel in : Android, Ecosystem, Google, Oracle, Restlet General - no comment

After the shock wave following the recent legal decision at Federal level on the Java copyright case between Oracle and Google, I decided to read the 69 pages of the court decision and extract the most interesting quotes, from a Java technologist point of view.


US Court - Oracle vs Google

Quote 1 – Scope

This copyright dispute involves 37 packages of computer source code. The parties have often referred to these groups of computer programs, individually or collectively, as “application programming interfaces,” or API packages, but it is their content, not their name, that matters.”

Quote 2 – On patents

The jury found no patent infringement, and the patent claims are not at issue in this appeal.

Quote 3 – Java definition

The Java platform includes the “Java development kit (JDK), javac compiler, tools and utilities, runtime programs, class libraries (API packages), and the Java virtual machine.

Quote 4 – API analogy with a books library

The parties have not disputed the district court’s analogy: Oracle’s collection of API packages is like a library, each package is like a bookshelf in the library, each class is like a book on the shelf, and each method is like a how-to chapter in a book.

Quote 5 – Core Java packages

The district court found, and Oracle concedes to some extent, that three of those packages—java.lang,, and java.util—were “core” packages, meaning that programmers using the Java language had to use them “in order to make any worthwhile use of the language.”

Quote 6 – Two types of source code

Every package consists of two types of source code— what the parties call (1) declaring code; and (2) implementing code. Declaring code is the expression that identifies the prewritten function and is sometimes referred to as the “declaration” or “header.” As the district court explained, the “main point is that this header line of code introduces the method body and specifies very precisely the inputs, name and other functionality.”

Quote 7 – Android history with Java

Google acquired Android, Inc. in 2005 as part of a plan to develop a smartphone platform. Later that same year, Google and Sun began discussing the possibility of Google “taking a license to use and to adapt the entire Java platform for mobile devices.” Copyrightability Decision, 872 F. Supp. 2d at 978. They also discussed a “possible co-development partnership deal with Sun under which Java technology would become an open-source part of the Android platform, adapted for mobile devices.” Id. The parties negotiated for months but were unable to reach an agreement. The point of contention between the parties was Google’s refusal to make the implementation of its programs compatible with the Java virtual machine or interoperable with other Java programs. Because Sun/Oracle found that position to be anathema to the “write once, run anywhere” philosophy, it did not grant Google a license to use the Java API packages.

When the parties’ negotiations reached an impasse, Google decided to use the Java programming language to design its own virtual machine—the Dalvik virtual machine (“Dalvik VM”)—and “to write its own implementations for the functions in the Java API that were key to mobile devices.” Id. Google developed the Android platform, which grew to include 168 API packages—37 of which correspond to the Java API packages at issue in this appeal.

Quote 8 – SSO and the 37 Java packages at issue

With respect to the 37 packages at issue, “Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.” Id. To achieve this result, Google copied the declaring source code from the 37 Java API packages verbatim, inserting that code into parts of its Android software. In doing so, Google copied the elaborately organized taxonomy of all the names of methods, classes, interfaces, and packages— the “overall system of organized names—covering 37 packages, with over six hundred classes, with over six thousand methods.” Copyrightability Decision, 872 F. Supp. 2d at 999. The parties and district court referred to this taxonomy of expressions as the “structure, sequence, and organization” or “SSO” of the 37 packages. It is undisputed, however, that Google wrote its own implementing code, except with respect to: (1) the rangeCheck function, which consisted of nine lines of code; and (2) eight decompiled security files.

Quote 9 – Android incompatibility with Java

Although Android uses the Java programming language, it is undisputed that Android is not generally Java compatible. As Oracle explains, “Google ultimately designed Android to be incompatible with the Java platform, so that apps written for one will not work on the other.”

Quote 10 – Java interoperability and command structure

According to Google, however, the district court correctly determined that: (1) there was only one way to write the Java method declarations and remain “interoperable” with Java; and (2) the organization and structure of the 37 Java API packages is a “command structure” excluded from copyright protection under Section 102(b). Google also argues that, if we reverse the district court’s copyrightability determination, we should direct the district court to retry its fair use defense.

Quote 11 – Decision on copyrightability

The court also erred by importing fair use principles, including interoperability concerns, into its copyrightability analysis. For the reasons that follow, we conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages are entitled to copyright protection.

Quote 12 – Java API design was a creative process

The testimony at trial revealed that designing the Java API packages was a creative process and that the Sun/Oracle developers had a vast range of options for the structure and organization. In its copyrightability decision, the district court specifically found that the API packages are both creative and original, and Google concedes on appeal that the originality requirements are met.

Quote 13 – Is an API just an idea and the implementation its expression?

In its analysis, the court identified the method declaration as the idea and found that the implementation is the expression. Id. (“The method specification is the idea. The method implementation is the expression. No one may monopolize the idea.”) (emphases in original). The court explained that, under the rules of Java, a programmer must use the identical “declaration or method header lines” to “declare a method specifying the same functionality.”

Quote 14 – Two years to write the core Java packages

it took years to write some of the Java packages and that Sun/Oracle developers had to “wrestle with what functions to include in the package, which to put in other packages, and which to omit entirely”).

Quote 15 – Interoperability doesn’t relate to copyrightability, but to fair user

Oracle also argues that the district court erred in invoking interoperability in its copyrightability analysis. Specifically, Oracle argues that Google’s interoperability arguments are only relevant, if at all, to fair use—not to the question of whether the API packages are copyrightable. We agree.

Quote 16 – Java interoperability was not the real aim of Google with Android

Google maintains on appeal that its use of the “Java class and method names and declarations was ‘the only and essential means’ of achieving a degree of interoperability with existing programs written in the [Java language].” Appellee Br. 49. Indeed, given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google’s interoperability argument confusing. While Google repeatedly cites to the district court’s finding that Google had to copy the packages so that an app written in Java could run on Android, it cites to no evidence in the record that any such app exists and points to no Java apps that either pre-dated or post-dated Android that could run on the Android platform.

Quote 17 – Google wanted to capitalize on trained Java developers

The compatibility Google sought to foster was not with Oracle’s Java platform or with the JVM central to that platform. Instead, Google wanted to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue. The district court agreed, finding that, as to the 37 Java API packages, “Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.”

Quote 18 – Irrelevant argument of Java as an industry standard

Google was free to develop its own API packages and to “lobby” programmers to adopt them. Instead, it chose to copy Oracle’s declaring code and the SSO to capitalize on the preexisting community of programmers who were accustomed to using the Java API packages. That desire has nothing to do with copyrightability. For these reasons, we find that Google’s industry standard argument has no bearing on the copyrightability of Oracle’s work.

Quote 19 – Fair use  factors

“Section 107 requires a case-by-case determination whether a particular use is fair, and the statute notes four nonexclusive factors to be considered.” [...] Those factors are: (1) “the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;” (2) “the nature of the copyrighted work;” (3) “the amount and substantiality of the portion used in relation to the copyrighted work as a whole;” and (4) “the effect of the use upon the potential market for or value of the copyrighted work.”

Quote 19 – Fair use defense from Google

Google contends, however, that, although it admittedly copied portions of the API packages and did so for what were purely commercial purposes, a reasonable juror still could find that: (1) Google’s use was transformative; (2) the Java API packages are entitled only to weak protection; (3) Google’s use was necessary to work within a language that had become an industry standard; and (4) the market impact on Oracle was not substantial.

Quote 20 – New trial on fair use question

On balance, we find that due respect for the limit of our appellate function requires that we remand the fair use question for a new trial. First, although it is undisputed that Google’s use of the API packages is commercial, the parties disagree on whether its use is “transformative.”

Quote 21 – Google transformative argument and Oracle’s defense

Google argues that it is, because it wrote its own implementing code, created its own virtual machine, and incorporated the packages into a smartphone platform. For its part, Oracle maintains that Google’s use is not transformative because: (1) “[t]he same code in Android . . . enables programmers to invoke the same pre-programmed functions in exactly the same way;” and (2) Google’s use of the declaring code and packages does not serve a different function from Java.

Quote 22 – Inability to decide on fair use

While Google overstates what activities can be deemed transformative under a correct application of the law, we cannot say that there are no material facts in dispute on the question of whether Google’s use is “transformative,” even under a correct reading of the law. As such, we are unable to resolve this issue on appeal.

Quote 23 – Importance of Java core packages for fair use retrial

We find this particularly true with respect to those core packages which it seems may be necessary for anyone to copy if they are to write programs in the Java language. And, it may be that others of the packages were similarly essential components of any Java language-based program. So far, that type of filtration analysis has not occurred.

Additional references

APISpark 2.1 released

May 6, 2014

Posted by Swann Vichot in : APISpark, Google, Restlet General - no comment

The sun is shining, Summer is approaching and it’s time to share all the cool stuff we’ve added in this APISpark 2.1 release!

Improved Google Spreadsheet Wrapper

A lot of work was done on stabilizing the wrappers and improving the tutorials. One that we think you will find interesting is Turn your Google Spreadsheet into a custom web API. You have to admit it sounds pretty cool!

GSheet Tutorial_2

This tutorial will guide you through creating an API directly from one of your Google Spreadsheet. Give it a go, it’s quite simple! Let us know what you think by commenting below or sending us an email.

API Commons Support

API Commons objective is to “provide a simple and transparent mechanism for the copyright free sharing and collaborative design of API specifications, interfaces and data models.” 


So for this release, we thought it would be great to support API Commons out-of-the box. Here is a preview of the integration in the APISpark Console:

API Commons preview

With this integration, APISpark lets you define copyright and licensing metadata and automatically generates your API Commons manifest including your API definition based on Swagger specification. This saves you time and allows you to quickly share your API design in the commons.

Sign up now to try it out!

Document your Restlet web API

Have you been using the Restlet Framework to build you API?

integration AS and RF_3

Now you can use APISpark to provide you with always up-to-date documentation. The integration has been added to the recent Restlet Framework release. Download 2.3 M2 now.

We will continue to enhance this integration to support not only Restlet API but also JAX-RS API and others, generate client SDKs, manage users and prepare usage reports for all your existing web APIs!

Read the APISpark page in Restlet user guide for details. Don’t forget to give us your feedback so we can make a product better suited to you!


Additional resources

Learn more:
TutorialsUser guideCatalog
A Field Guide to Web APIs by Kin Lane
PaaS Market Moves Beyond Deployment and Scaling by David Linthicum

For more updates:
Follow APISpark on Twitter (@apispark)

Restlet Framework 2.1 M4 and 2.0.7 released

April 27, 2011

Posted by Jerome Louvel in : GAE, Restlet Releases, SDC, Security - no comment

In order to adress several pressing issues, we are releasing those new versions one month after the previous release cycle. The good news is that we had time to add a couple of nice features to the 2.1 development branch!

Bug fixed

First, the 2.0.7 version fixes a couple of issues on the stable branch including:

  • Dormant threads in some IO operations due to excessive thread pool instantiation (via TaskService). Now a single temporary thread is used when an existing TaskService can’t be found.
  • Broken Amazon S3 authentication due to new AWS domain naming strategy
  • Cookies management interference when using the Apache HTTP client extension
  • Performance issue with JAXB serialization when used by the JAX-RS extension
  • Equality testing between Role instances wasn’t properly done (object identity testing)

Those fixes are of course also available in the new 2.1 release.

Major changes

In addition, version 2.1 Milestone 4 contains several major enhancements and new features summarized below.

  • The ClientResource#entityBuffering property now buffers non transient representations of unknown size. This change was necessary to fully prevent HTTP chunking when talking to a GAE backend (which forbids chunk encoding).
  • Refactoring of the SSL support to reduce the “org.restlet.jar” size by moving all SSL logic to the “org.restlet.ext.ssl” extension. Now other HTTP extensions including Jetty, Simple and Apache HTTP Client need to add this dependency. The SSL extension also includes an experimental HTTPS client that will be stabilized and completed with a HTTPS server in next milestone.
  • The simplified logging format (one line per log entry) used by default in the Java SE edition has now been disabled from the Java EE edition by default as it could interfer with logging behavior of some containers such as Tomcat
  • Throwing ResourceExceptions in ServerResource subclasses now properly preserves the given status code back to the client
  • The SDC protocol support added in 2.1 M3 via the “org.restlet.ext.sdc” extension is now available in the GAE edition via the “” extension, with the same syntax for better code portability between cloud platforms (Protocol.SDC and ChallengeScheme.SDC constants also added)
  • New “org.restlet.ext.gae” extension added to the GAE edition that supports authentication and enrolement based on the GAE users service
  • ClientResource now respects any change to the default client preferences when using dynamic proxies (via wrap() for example), such as change in preferred media types.

Recent contributors

  • Avi Flax
  • Bo Xing
  • Christoph Dietze
  • John Logsdon
  • Julien Landuré
  • Kristoffer Gronowski
  • Martin Svensson
  • Matt Kennedy
  • Michael Guiral
  • Rhett Sutphin
  • Tal Liron
  • Tim Peierls

Thanks to all others who helped us in various ways for this fourth milestone.

Additional resources

Changes log:

Download links:

Maven repositories:

Leveraging SDC beyond Google cloud with Restlet

March 31, 2011

Posted by Jerome Louvel in : Restlet, Restlet General, SDC - no comment


When Google announced Secure Data Connector in 2009, it was welcomed with interest as it addressed people concerns regarding public cloud security and especially integration with their private information system.

SDC solves this cloud integration dilemma without requiring to open new ports on your firewall by establishing a reverse web proxy, called SDC Agent, that connects to an SDC Tunnel Server located in Google cloud infrastructure. Once established, the secure tunnel can be used in the opposite direction, from the Google cloud to your secure intranet by Google Sites, Google App Engine applications and Google Docs spreadsheets.

Missing features

While Google SDC is great if you fully live in the Google Apps ecosystem, it comes with several limitations:

  • SDC Agent is available as an open source project, but not the SDC Tunnel Server part
  • Google App Engine SDK doesn’t provide a way to test SDC locally without deploying your application
  • Can’t be used with other cloud platforms such as Amazon EC2 and Microsoft Azure
  • You can’t easily port a GAE application using SDC to another platform, private cloud or public cloud

As one of the Restlet Framework goals is to ensure a maximum portability across various Java based platforms such as GAE, GWT, Android and Java SE/EE those SDC challenges were compelling.

Restlet SDC connector

At the end of 2010, RunMyProcess, a long time Restlet user offering a cloud workflow solution as a cloud computing service, offered us to co-develop a Restlet SDC connector that would emulate Google SDC Tunnel Server and expose it like an HTTP client connector.

Thanks to the SDC Agent being available as open source, we could dive inside the implementation and understand the SDC protocol design which heavily relies on Google Protocol Buffer to implement a multiplexing tunnel (frames going both ways without constraint) over a TLS socket.

In the picture above, we illustrated how the Google SDC Agent software can be configured to connect to Restlet SDC Tunnel Server in the same way that you would do it for your Google Apps domain.

All the missing features are now supported by this Restlet extension which has just been released with version 2.1 M3 today! Thanks to RunMyProcess for co-developing this feature with Noelios Technologies.

You can find more technical details about this new feature in Restlet User Guide including sample usage code. Improvements are planned for a future release in order to increase the scalability of the connector by leveraging non blocking NIO/SSL connections or allowing load-balancing between a set of SDC Agent within the same intranet.

Update: RunMyProcess has now officially announced the support for this feature, see also press release

Restlet Framework 2.1 M3 and 2.0.6 released

March 31, 2011

Posted by Jerome Louvel in : NIO, Restlet, Restlet Releases, SDC, SIP - no comment

Past months have been very intense for Noelios in a positive way and we are pleased to release those two new versions today. Our long running effort to develop our own non-blocking NIO connector into Restlet core, comparable in performance to Jetty/Netty/Grizzly but simpler and directly aligned to HTTP/SIP transport semantics is starting to give great results.

First, the 2.0.6 version fixes a couple of issues on the stable branch. In addition, version 2.1 Milestone 3 contains several major enhancements and new features summarized below.

Main changes

  • Support for GWT 2.2 has been added, but due to breaking changes inside GWT core API, we couldn’t maintain compatibility with previous versions of GWT. If you can’t upgrade your GWT version, you can still rely on the 2.0 branch of Restlet.
  • Stabilized the built-in SIP and HTTP client and server connectors based on our non-blocking NIO core layer, refactoring the previous design and fixing many bugs. This should solve most issues related to blocked connections and infinite loops that were encountered. See this blog post for an official announce.
  • Added a new SDC extension providing a client connector for the Google Secure Data Connector protocol compatible with the official SDC agent. This allows usage of this feature during development phases as well as for deployment to private clouds and other public clouds such as Amazon EC2 and Microsoft Azure. See this blog post for an official announce.
  • Improved ClientResource class by adding several properties
    • requestEntityBuffering, responseEntityBuffering properties to make transient entities reusable (retry attempts, chunk encoding issues with GAE, response entity reuse)
    • maxRedirects property to prevent infinite redirects, in addition to the existing infinite loop detection.
  • Added an easy to listener mechanism that facilitates the support of asynchronous representation consumption. We tested this feature successfully by consuming live feeds from CouchDB.
  • Updated several dependencies including Jetty to version 7.3.0 and Jackson to version 1.7.1

Recent contributors

  • Andreas Taube
  • Carolyn Duby
  • Charlie Mason
  • Henry Story
  • Guido Schmidt
  • John Logsdon
  • Kristoffer Gronowski
  • Leandro Oliveira
  • Olivier Miel
  • Phil Dunks
  • Sebastien Gaide

Thanks to all others who helped us in various ways for this third milestone.

Additional resources

Changes log:

Download links:

Maven repositories:

GSoC and Restlet integration with Equinox

May 6, 2010

Posted by Jerome Louvel in : Ecosystem, Equinox, GSoC, OSGi, Restlet General - no comment

Two years ago, we announced that NASA launched Restlet on the OSGi orbit by developing an integration of Restlet 1.1 with OSGi, based on Equinox extension points. This effort was presented at EclipseCon 2008 & 2009, and the code was contributed to the Ensemble project under a special license as explained by Bryan Hunt in this post. Also, listening to feed-back on OSGi from Restlet community, version 2.0 of the Restlet Framework was enhanced to ensure that all its modules and dependencies were available as good OSGi bundles.

However, even though deploying Restlet components and applications in an OSGi environment is already possible and explained in the user guide, it doesn’t take advantage of the dynamic and extensible nature of OSGi. Today, Bryan Hunt pointed me to a great tutorial written by Wolfgang Werner that nicely describes the Restlet Framework, covers its usage with Eclipse’s Plugin Development Environment (PDE) and explains how to leverage Equinox’s extension points to dynamically register Restlet components, applications and resources. See the series of posts titled “Building web services on Equinox and Restlet”:  part #1, part #2 and part #3.

But wait, there is more good news as a Google Summer of Code 2010 project “Restlet integration with Equinox” was proposed by the Eclipse Foundation and just accepted by Google! Thanks to Bryan Hunt for initiating the effort, to Equinox’s development team for supporting it, including Jeff McAffer, Simon Kaegi and Scott Lewis. We also received a positive review from Benjamin Cabé, an Eclipse contributor. Thanks also to all supporters including Jeff Norris and Khawaja S Shams from NASA, Rob Heittman from Solertium and Thierry Templier.

Two students proposals were submitted, one from Rajeev Sampath and another one from Samrat Dhillon. The first one was finally selected but Samrat has offered to contribute to the project. Rajeev is a Computer Science undergraduate student from University of Moratuwa, Sri Lanka, with good Java and distributed system experience as illustrated by his participation to the Epzilla project on Complex Event Processing (CEP).

I’m very happy to see this project, initiated by the Restlet community, taking shape and wish it full success. At Noelios Technologies, we will support it as co-mentor and encourage other interested parties to join and contribute. The project web site at Google Code is here… stay tuned!


Restlet supports OData, the Open Data Protocol

March 15, 2010

Posted by Jerome Louvel in : GData, OData, RDF, Restlet - no comment

OData adoption

Since the release of our Restlet extension for ADO.NET Data Services in September 2009, many changes happened on this front. Microsoft has been busy enhancing their technology, splitting it into an open specification for the REST API called OData, for Open Data Protocol, and using WCF Data Services for the server-side framework. This article gives an overview of the technology, and this page the full specifications of the protocol.

The OData protocol has also been embraced by IBM in its Java-based WebSphere eXtreme Scale product and Microsoft has leveraged it in several of its products like Excel PowerPivot, SharePoint Server, Windows Azure Table Storage and SQL Server Reporting. Other recent initiatives are the project code-named “Dallas“, which offers a market place for data services with full support for access control and billing, and the OData visualizer part of Visual Studio 2010.

In addition, public OData services are starting to pop-up, like the one to access Netflix’s media catalog. Microsoft has been providing examples via the OGDI initiative and for the MIX’10 conference. Here is a longer list of producers.

Enhanced Restlet extension

While preparing our recent Restlet Framework 2.0 RC1 release, we enhanced our Restlet extension for OData, moving it from the “org.restlet.ext.dataservices” to the “org.restlet.ext.odata” package and adding support for those advanced features:

  • Projections, similar to database views
  • Transparent server-side paging
  • Blobs, to expose media resources
  • Row counts retrieval
  • Customizable Atom feeds
  • Version headers
  • Operations, to expose stored procedures

The extension is also available on the Restlet edition for Android, allowing you to directly access OData services, for example hosted on Azure cloud computing platform, from a smart phone.

The diagram above illustrates how useful the Restlet extension for OData is becoming, as a high-level client for data services powered by a growing number of server-side technologies. For explanation on how to use this extension, read the Restlet user guide page for the extension as well as a detailed tutorial.

Towards standardization

All those initiatives have caught attention with articles and posts like:

An interesting thing to watch going forward is how this technology will be compared with Google Data Protocol (GData) alternative. In his OData Q&A page, Microsoft hopes for a collaboration with Google on an official set of extension to the Atom suite of standards.

Yahoo! has also worked on a similar technology called DataRSS, and finally the W3C is pushing the Linked Data, an application of the Semantic Web, as a way to transform the Web of documents into a Web of data, with technologies like RDF and SPARQL.




Restlet, a RESTful middleware for GWT, GAE and Android

December 17, 2009

Posted by Jerome Louvel in : Android, Ecosystem, GAE, Google, GWT, Microsoft, REST, Restlet, Restlet General - no comment

The Web is taking multiple shapes with the Mobile Web, Cloud Computing and RIA being hot topics recently. If you follow this blog frequently, you are certainly aware that the Restlet Framework, the first RESTful web framework for Java developers, is available in five consistent editions since version 2.0 M4. Each edition targets a special development environment:

  • Google Web Toolkit (GWT) for AJAX applications deployed in desktop browsers, without any plugin required
  • Google App Engine (GAE/J) for deployment on Google’s cloud computing infrastructure
  • Android for deployment on compatible smartphones
  • Java SE for standalone deployments in regular Java Virtual Machines
  • Java EE for deployment in Servlet engines

Each edition is offering the same Restlet Framework, with restrictions and adjustments based on the target environment. For example, the GWT edition only supports the client-side usage of Restlet, while the GAE edition only provides compatible extensions and ensures that we don’t break the security sandbox or use unsupported JRE classes.

As a result, you can easily develop a unified Restlet application with a server-side deployed in GAE, a client version available for Android smartphones and another available for desktop browsers with GWT, fully leveraging the most innovative technologies available from Google for Java developers.

You might wonder what exact value does Restlet brings in the middle of those technologies? The Restlet Framework is all about REST, supporting advanced HTTP features such as content negotiation, caching and conditional processing, allowing for the same URI-addressable resource to expose various representations. Each representation renders the same information in  various languages or formats such as JSON, XML or anything else that makes sense for your clients such as binary pictures.

Supporting content negotiation allows your Restlet cloud server to expose the same resources to all its clients, including an Android smartphone client, a GWT desktop client, a Flex client, a programmatic Java SE robot or a basic HTML browser. One Java API and one unified code base gets you covered in all those scenarios, even if you need to serve static files: a Restlet Application truly merges the notion of Web Site, Web App and Web Service!

So, using Restlet as a cloud server gets you much further than a regular Servlet application. Usually, you would use GWT-RPC to communicate between your GWT client and your GAE back-end, and the low-level HTTP client provided by Android to communicate with your GAE custom Servlets. Obviously, the result wouldn’t be very RESTful as GWT-RPC is introducing some strong coupling. You could use the low-level HTTP client provided by GWT as well, but then you would loose the big benefit of using Java proxies in GWT, with transparent serialization of parameters and result object.

This is where the Restlet Framework comes to rescue! For GWT, we provide both a high-level HTTP client, removing the need to manually parse and format HTTP headers thanks to its Restlet API but also a proxy generation mechanism based on GWT deferred binding very similar to GWT-RPC but truly RESTful! Migration of existing GWT-RPC code is straightforward as we also support GWT-RPC AsyncCallback interface in addition to our equivalent Result interface. For our serialization format, we reused the one of GWT-RPC, a special JSON variant, therefore it is fully featured and as robust as GWT-RPC ! In your Restlet cloud server, you just need to add our server-side GWT extension to transparently support this serialization format, thanks to content negotiation.

If you are a Google fan, you should be happily developing with the recent GWT 2.0, Android 2.0 and GAE 1.3.0 releases and the RESTful solution described above should gives you a big smile and to get started, we have written a complete tutorial, with full source code, illustrating a unified Restlet application for GAE, GWT and Android.

But even in this scenario, you wouldn’t be restricted to Google technologies, you could chose to support alternative clients such as regular HTML browsers, Flex or Silverlight clients, or any other HTTP client. On the server-side, you could take the same Restlet application and deploy it locally, or on Amazon EC2 or Microsoft Azure, thanks to our Restlet editions for Java SE and Java EE which can be installed on those major cloud platforms!

In the end, the Restlet Framework offers you, for free, the first comprehensive RESTful middleware for Google technologies and beyond! As a last word, I would like to thank again my friend Didier Girard, for sharing his insights that led us to this post (and a lot of work!) :)