Make Gson class non-final and open to extension

[GoogleCodeExporter]

https://groups.google.com/d/topic/google-gson/j2XiGLqdRco/discussion

Original issue reported on code.google.com by inder123 on 24 Sep 2012 at 5:38

[GoogleCodeExporter]

From that discussion:

> On Monday, 24 September 2012 10:12:26 UTC-7, Brandon Mintern wrote:
>>
>> Here's an actual use-case:
>>
>> Certain interfaces (TypeAdapterFactory, for example) take a Gson
>> instance as a method argument. If I want to implement a
>> RecursionSafeTypeAdapterFactory, the easiest way might be to have a
>> Gson subclass that does some bookkeeping before delegating to an
>> underlying Gson instance. This way, any user code is using the
>> familiar Gson interface (no changes necessary) but they get to make a
>> call like gson.toJson(this) safely for free, just by registering the
>> TypeAdapterFactory.

On Mon, Sep 24, 2012 at 10:42 AM, Inderjeet Singh <inder123@gmail.com> wrote:
> So, in your case, the recursion safe type adapter factory will only be
> usable with your Gson suclass. Any way this class could be written with the
> standard Gson? That would be a better design, IMHO, and avoid the need for a
> Gson subclass.

I could add code to Gson.java, sure. But I think you're suggesting that I 
present an interface not unlike the old JsonSerializationContext (for example, 
I had one called GsonContext) to clients? That works, but when I'm developing a 
library, my focus is generally on making client usage as simple as possible. I 
consider the ability to use a familiar interface (e.g., Gson.toJson, 
Gson.toJsonTree) in the implementation of write or read to be superior to 
having to learn yet another interface.

As the Gson project matures, there has been a nice trend of defining new 
functionality via interfaces, and adding internal classes that implement those 
interfaces. It would be nice in Gson 3.0 if some of the core classes (Gson, 
JsonElement, JsonWriter, JsonReader) were made into interfaces instead of final 
classes. This would have the nice side effect of simplifying things like 
performance testing different implementations. It would also make it possible 
for library users to create non-trivial extensions to Gson. Of course, 
extending a class and relying on a protected interface would come with caveats, 
but that seems to me to be superior to disallowing it completely.

Original comment by mint...@everlaw.com on 24 Sep 2012 at 5:55

[GoogleCodeExporter]

Agreed about providing means to plugin different implementations. Definitely 
worth looking at in Gson 3.0 scope which we are going to start soon.

Original comment by inder123 on 24 Sep 2012 at 6:35

[GoogleCodeExporter]

I think we should be very careful here. The best way to accomplish this type of 
framework on Gson is to compose TypeAdapters, which is already possible.

Original comment by limpbizkit on 4 Feb 2013 at 4:10

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

that would be a nice feature:

my scenario is the following:

Html escaping is insufficient for our use, i would like to employ a whitelist 
approach for serializing values (like bring in the Jsoup library for this).

1. Have GSON non-final
2. newJsonWriter() method non-private but protected.

Then I would be able to customize JsonWriter.value(...) method to do some of 
that stuff.
Or better: JsonWriter would have
protected void string(String value) 
instead of 
private void string(String value) 

Original comment by kolmis@gmail.com on 21 Feb 2013 at 9:22