Gmail Api Potential memory leak in com.google.api.client.util.escape.Platform

[GoogleCodeExporter]

Version of google-api-java-client (e.g. 1.15.0-rc)?
From my pom, I updated to the latest version but found it initially in earlier 
versions.
<dependency>
            <groupId>com.google.apis</groupId>
            <artifactId>google-api-services-gmail</artifactId>
            <version>v1-rev18-1.19.0</version>
</dependency>

Java environment (e.g. Java 6, Android 2.3, App Engine)?
Java 7, Tomcat 7, Spring MVC

Describe the problem.
Tomcat is reporting a memory leak on shutdown:
SEVERE: The web application [/#####] created a ThreadLocal with key of type 
[com.google.api.client.util.escape.Platform$1] (value 
[com.google.api.client.util.escape.Platform$1@6daa869b]) and a value of type 
[char[]] (value [[C@566b625c]) but failed to remove it when the web application 
was stopped. Threads are going to be renewed over time to try and avoid a 
probable memory leak.

How would you expect it to be fixed?
I would like the ThreadLocal created in 
com.google.api.client.util.escape.Platform to be properly disposed of. This was 
reported as fixed in the GSON library. 
https://code.google.com/p/google-gson/issues/detail?id=402
But it appears to have crept back in somehow.

Original issue reported on code.google.com by cmayn...@gmail.com on 17 Dec 2014 at 8:53

[GoogleCodeExporter]

I admit this is an annoying warning and there is a small memory leak (1KB) 
because the ThreadLocal never gets released when running in the container 
thread. However, this is not as bad as the gson issue because the thread local 
variable is an array of primitive (char[]), i.e., there's no chained 
application-order classloaders prevented in memory.

Other the other hand, the performance gain of this cached buffer is 
considerable as the escaping functionality is constantly used. We could have 
provided a clean-up helper method so that users of the library can choose to 
free the buffer as they like. However, there's layers and layers of other code 
that wrap this library, we have to either add such a helper at every layer, or 
users at the far end wouldn't know how/when to use this low level API.

So, it's a tradeoff between performance and usability to me.

Original comment by wonder...@google.com on 30 Dec 2014 at 9:56