VerifyError after upgrading to Appengine 1.6.6; Cannot create instance of UrlFetchTransport - google-api-java-client 1.8.0 / 1.9.0-beta

Question

After the upgrade this error appears :

java.lang.VerifyError: (class: com/mydomain/server/webservices/OAuth2Utils, method: newFlow signature: ()Lcom/google/api/client/googleapis/auth/oauth2/GoogleAuthorizationCodeFlow;) Incompatible argument to function

Not sure if this might be related but some info about my environment :

Linux n53sv 3.2.0-24-generic #38-Ubuntu SMP Tue May 1 16:18:50 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

UPDATE:

I stripped the problem to the bare minimum, and it is really unbelievable. I created a class BadClassTest and I create an instance of BadClassTest in a Servlet. When my BadClassTest looks like this :

public class BadClassTest {

    public BadClassTest() {
        com.google.api.client.http.HttpTransport HTTP_TRANSPORT = new com.google.api.client.extensions.appengine.http.urlfetch.UrlFetchTransport();
    }

}

then I can create an instance.

When my BadClassTest looks like this :

public class BadClassTest {

    com.google.api.client.http.HttpTransport HTTP_TRANSPORT = new com.google.api.client.extensions.appengine.http.urlfetch.UrlFetchTransport();

    public BadClassTest() {
        //com.google.api.client.http.HttpTransport HTTP_TRANSPORT = new com.google.api.client.extensions.appengine.http.urlfetch.UrlFetchTransport();
    }

}

I cannot create an instance of BadClassTest now. I run into following exception :

java.lang.VerifyError: (class: com/klawt/server/BadClassTest, method: signature: ()V) Bad type in putfield/putstatic

Answer 1

Update (June 6, 2012): we plan to fix this in the next version of the client library early next week. We are simply going to rename the package com.google.api.client.extensions.appengine.http.urlfetch to com.google.api.client.extensions.appengine.http

Original answer:

We figured out the problem: com.google.api.client.extensions.appengine.http.urlfetch.UrlFetchTransport is included in the App Engine SDK in appengine-local-webapis.jar . This class is actually there by mistake, and in fact the whole jar is unnecessary. Our primary recommendation as a work-around is to simply delete this jar from your App Engine SDK installation. It is only loaded in the local development server, and not in the production App Engine. I have not tried this myself yet, but another engineer assures me that it should work. Please try it and let me know.

If that work-around that does not work, you may try downgrading to App Engine SDK 1.6.5. The appengine-local-webapis.jar is new to 1.6.6, and again this is only an issue for local development.

Finally, if that doesn't work for you, switch to NetHttpTransport as recommended by koma. There is a bug in App Engine HttpURLConnection implementation (upon which NetHttpTransport is built) in that it splits up HTTP response headers by any commas. UrlFetchTransport doesn't have this problem. However, this is unlikely to affect most developers, unless for example you are handling redirects and the redirect URL has a comma in it. It should not be an issue with any Google API except the old Calendar Data API version 2 (not for the new version 3).

I am working with the App Engine team right now to make sure this will be fixed in the next release. Sorry about that!

Answer 2

I got confirmation from another user in the google-api-java-client group who ran into this issue. The workaround is to drop UrlFetchTransport and use NetHttpTransport which seems to be supported nowadays on AppEngine.

I replaced the implementation of my global instance of HttpTransport with NetHttpTransport instead of UrlFetchTransport, deployed and success.

*UPDATE *

Answer from Yaniv (google-api-java-client lead) :

UrlFetchTransport is still supposed to be the recommended choice on Google App Engine. There is a flaw in Google App Engine implementation of HttpURLConnection in terms of parsing HTTP headers, whereas UrlFetch doesn't have that flaw. But if NetHttpTransport is working for you, then you may continue to use it.

However, honestly I have not tried it with App Engine 1.6.6. I have only tried it on 1.6.5. I'd really like to see an investigation of what causes it to fail on 1.6.6. Another possibility is that it is not new to 1.6.6, but rather something different about the way you set up your environment.