https://github.com/msopentech/orc-for-android

Several 'special' characters that should be escaped in query strings, are not escaped, e.g.,: +, =, & etc. This makes it impossible to send things like time zone information in Odata queries.

May I suggest to use a standard library, like Apache URIUtil, instead of rolling your own encoding (https://github.com/MSOpenTech/orc-for-java/blob/master/src/main/java/com/microsoft/services/orc/core/Helpers.java#L145)?

This library is currently not compatible with Guava 20.0, because the Futures.transform(ListenableFuture, AsyncFunction) method has been renamed to Futures.asyncTransform(ListenableFuture, AsyncFunction).

See the deprecation warning in the Guava 19.0 docs. In Guava 20.0 the original method was removed (and a different method with the same name, but a different signature has been introduced).

The Guava dependency should be upgraded to 19.0 at least, before the usages in the com.microsoft.services.orc.core.Helpers class can be fixed.

I was browsing though https://github.com/MSOpenTech/orc-for-java/blob/master/orc-engine-jvm/src/main/java/com/microsoft/services/orc/jvm/impl/GsonSerializer.java and it looks like some of the referenced classes are not defined in this repository.

Are they hosted in another repo or are they missing from this one?

The default JavaDependencyResolver expects an OAuth access token as String. I think there are a couple of issues with this approach when it comes to token renewal. Normally, you want to reuse the dependency resolver (it can contain your HttpClient state and it is unnecessary to recreate it each time), but if the access token is a string there is no way to do proper token renewal.

Ideally, the dependency resolver would take some other object, and use that to retrieve its access token. On an HTTP 401, it would signal this object that the access token has expired, and optionally retry the request.

In the current architecture, using some factory object to provide the access token is possible by providing a custom dependency resolver. But handling an HTTP 401 error in a nice way is impossible - the error will always bubble up through the client libraries and you have to handle it at each place where you perform a REST API call.