TreeMap getValues() serialization fails with -XX:+AggressiveOpts on Oracle VM

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run the attached class on an Oracle (or Apple) VM. Notice the output that 
says "*[{"name":"foo","displayName":"foo"}]*"
2. Re-run the attached class on the same VM with -XX:+AggressiveOpts . With 
Gson 1.7.1 I get "**", with 2.1 I get "*null*".

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

I would expect in both runs that the output would be 
"*[{"name":"foo","displayName":"foo"}]*"

What version of the product are you using? On what operating system?

I've tried with Gson 1.7.1 or 2.1 (didn't really make a difference) on a 
MacBook pro with:
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)

Please provide any additional information below.

The cause seems to be a new TreeMap implementation ( -> 
https://blogs.oracle.com/dagastine/entry/apache_harmony_thanks_for_the ) that's 
enabled with that option. On an IBM JVM this new implementation seems to be the 
default, so Gson fails "out of the box" when running on an IBM JDK.

If I'm really coding the serialization myself it's of course simple to use 

        Type typeOfSrc = new TypeToken<Collection<Dummy>>() {}.getType();
        gson.toJson(map.values(), typeOfSrc, writer);

instead of just:

        gson.toJson(map.values(), writer);

But if Gson is used by an intermediate Framework then I don't have that control 
and would expect that "built-in" types work.

Original issue reported on code.google.com by DerWi...@googlemail.com on 27 Mar 2012 at 12:53

Attachments:

• GsonTest.java

[GoogleCodeExporter]

The JVM is incorrect when the -XX:+AggressiveOpts option is used. You shouldn't 
use that option in your application; it's only intended for foolish 
benchmarking.

Original comment by limpbizkit on 11 Apr 2012 at 8:38

• Changed state: WontFix

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

What about the IBM JVM? Above mentioned example will fail using standard 
options. Is the coding not supposed to work with an IBM JVM?
Also, it could well be that Oracle decides to change the default behaviour of 
the Oracle JDK, i.e. the coding would fail there too without any 
-XX:+AggressiveOpts option set.

Original comment by UweFisch...@gmail.com on 16 Apr 2012 at 12:56