Making Credentials classes Serializable

[mziccard]

In order for us to expose google-auth-library-java classes in google-cloud-java (thus dropping our AuthCredentials classes), we need Credentials classes to be Serializable.

One of the main obstacles to making Credentials classes serializable is that some of them contain an HttpTransport field, which is not serializable (see ComputeEngineCredentials for instance).

We faced this issue with our HttpServiceOptions classes and introduced the HttpTransportFactory interface:

  /**
   * A base interface for all {@link HttpTransport} factories.
   *
   * <p>Implementation must provide a public no-arg constructor. Loading of a factory implementation
   * is done via {@link java.util.ServiceLoader}.
   */
  public interface HttpTransportFactory {
    HttpTransport create();
  }

When serializing an option object we only transmit the class name for the transport factory and try to instantiate the factory from its classname upon deserialization.

Do you think something like this could be done for Credentials classes as well? Opinions are welcome.

/cc @anthmgoogle @garrettjonesgoogle @lesv

[garrettjonesgoogle]

One thing that's not clear to me from HttpServiceOptions is why it's necessary to have two layers of indirection, i.e. httpTransportFactoryClassName => httpTransportFactory => HttpTransport.

[mziccard]

HttpTransport implementations might have instance fields (see for instance NetHttpTransport.Builder). So while you could serialize them just using the class name and a no-arg constructor the deserialized transport could have have a different behavior (e.g. missing a proxy configuration).

We introduce an HttpTransportFactory and document that it should have a no-arg costructor so we can serialize it just using only the classname. To HttpTransportFactory we can add proper documentation and it's reasonable to assume/require that a factory has no instance fields and an empty constructor.

[garrettjonesgoogle]

Ok, that makes sense. This seems like a reasonable approach and I'm personally fine with using it here (google-auth-library-java).

[anthmgoogle]

I agree with adding this functionality to Credentials so that it can be used more broadly. There was no decision when this was originally created inconsistent with this.

[mziccard]

This was fixed in #69