String values converted to numeric literals are losing precision in Javascript due to it's 64 bit floating point representation

We have encountered this issue using RESTEasy, and I'd argue that it is a blocker, not minor. An example:

@XmlRootElement
@XmlAccessorType(XmlAccessType.PROPERTY) // leaving off getters/setters for clarity.
public class DemoBean
{
  @XmlElement(type = String.class ) // <-- just indicating that type doesn't help. ( Annotation would be on getter for AccessType.Property)
  private String value = "999999999999999999";
  private String name = "aName";
}

Marshalled value on first request:

{"demoBean":{"name":"aName", "value":999999999999999999 } }

Eval the bean:

demoBean : {
 name : 'aName',
 value : 1000000000000000000
}

If the consumer then changes 'name' and saves the bean back to the server, value is modified as well.

I can imagine a couple of potential fixes for this.

Modify org.codehaus.jettison.mapped.DefaultConverter:

• Argument in favor: It would better to return a string - which can be converted to a float - than to return a value which loses precision.
• Argument against: changes existing behavior.

  Object primitive = null;
   // Attempt to convert to Integer
   try 
  {
     primitive = Long.valueOf(text);
     if( primitive > Integer.MAX_VALUE || primitive < Integer.MIN_VALUE )
     {
       return text;
     }
   } 
   catch (Exception e) {}
  

Another possible fix:
Check the System properties for a user-specified classpath to use for the TypeConverter

• This in Configuration.java and MappedNamespaceConvention.java.
• Since Jettison is embedded by RestEasy users will generally not be able to modify the TypeConverter to be used, at least without creating a vast amount of additional boilerplate.

Thanks,
Geoff Granum

This patch also modifies the POM in order to enable per-test forking. Not sure how important that is to anyone.

I went ahead and fixed the infinity and NaN bug (64) while I was in the code - I didn't notice the patch on the Jira post until just now. I do slightly favor the solution in this file, as it delegates the determination to the JVM rather than hard-coding the strings 'Infinity' and 'NaN'.

This patch includes the option to set two System properties:
#1: 'jettison.mapped.typeconverter.enforce_32bit_integer': Disable Long values.
– Iff set to true, any integer value which exceeds 32bits will be returned as a String

#2 'jettison.mapped.typeconverter.class': Specify a custom 'default' converter class (not to be confused with the current 'DefaultConverter').
– Iff set to a valid class name before Configuration.java is accessed in the current Classloader, then the specified class will be instantiated via Class.forName(theValue) for all instances of Configuration.java in that Classloader. If not set, DefaultConverter will be used, as before.

Test cases for all of the above.

Hi Geoff, thanks for the patch. I'll see to commit it soon.

Patch applied with svn revisions 83 and 84. Thanks.