WARN log level to high for message about overriding type handlers

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a GSON object: new GsonBuilder().create(); 
2. Retrotranslate the byte code to jdk 1.4, using Retrotranslator 
http://retrotranslator.sourceforge.net/
3. Run the code.

What is the expected output? What do you see instead?

I would expect no WARNINGs to be logged. However, I see the following output to 
the console:

com.google.gson.ParameterizedTypeHandlerMap register
WARNING: Overriding the existing type handler for interface java.util.Collection

What version of the product are you using? On what operating system?
1.3 and also tested with 1.4 built from trunk.

Please provide any additional information below.

This log message comes from the following line of code:
http://code.google.com/p/google-
gson/source/browse/trunk/gson/src/main/java/com/google/gson/ParameterizedTypeHan
dlerM
ap.java#49

Specifically, it is logged because the 
DefaultTypeAdapters.createDefaultInstanceCreators method 
adds a COLLECTION_TYPE_HANDLER for Collection.class, and then later, a 
Queue.class. 
Because Queue.class is @since 1.5, retrotranslator replaces the class literal 
"java.util.Queue", with 
"java.util.Collection". This causes the Queue type handler to overwrite the 
Collection type 
handler.

    map.register(Map.class, MAP_TYPE_ADAPTER);

    // Add Collection type instance creators
    map.register(Collection.class, COLLECTION_TYPE_ADAPTER);
    map.register(List.class, COLLECTION_TYPE_ADAPTER);
    map.register(Queue.class, COLLECTION_TYPE_ADAPTER);

I'm not sure that a WARNING is needed here, since both Collection and Queue 
have the same 
Collection type handlers. 

Either the WARNING could be removed, or there could be some smarter registering 
of type 
handlers so that the Queue class automatically gets the COLLECTION_TYPE_HANDLER.

Original issue reported on code.google.com by npel...@gmail.com on 27 Aug 2009 at 1:17

[GoogleCodeExporter]

We log it as a WARNING because we want to make sure that the user is not
"accidentally" overriding one of the default type adapters.  We are using the 
JDK
logger, so it is possible for you to disable all logging coming from the Gson 
library
by adding the following line to your logging properties file:

# Turn off all Gson logging.
com.google.gson.level = OFF

Or you can turn off all JDK logging with:
# Disable all logging
.level = OFF

-----------------

On a side note, would you be able to post the instructions on how you 
retrotranslated
the Gson library to run on a Java 1.4 VM?

Thanks,
Joel

Original comment by joel.leitch@gmail.com on 29 Sep 2009 at 5:30

• Changed state: WontFix

[GoogleCodeExporter]

HI Joel, 

Thanks for the update.

I worked around this by telling retrotranslator to keep class literals. The 
configuration for the retrotranslator Ant task is as follows:

<retrotranslator target="1.4"
                             destjar="${destjar}" srcjar="${srcjar}"
                             smart="true" verify="false" failonwarning="true" keepclasslit="true">
                <classpath>
                     ....
                </classpath>
</retrotranslator>

However, IMO - that logging should be at DEBUG level by default, because it is 
a programmer error, and not a user error.
The programmer should ensure the program functions correctly by writing tests, 
etc before shipping to the customer, rather than use log 
messages from the library to detect possible errors. Or, the library should 
fail hard and fast if an error really exists.

In my case - everything worked fine, and that log message was still being 
output as WARN.

Cheers,
Nick

Original comment by npel...@gmail.com on 29 Sep 2009 at 10:20

[GoogleCodeExporter]

I noticed this is marked won't fix. I just spent some time figuring out why our 
logs are bloated with this particular message and found my way here. From my 
point of view this is indeed debug level information. In general, libraries 
should be very conservative with logging above debug level IMHO.

Anyway, am I actually doing something wrong here? I was under the impression I 
was using a (well) supported feature of GSon when I implemented a handful of 
custom serializers and deserializers.

Original comment by jillesva...@gmail.com on 10 Dec 2010 at 2:02