Fixed opt/get Int/Long/Double inconsistencies

[abimarank]

As discussed here, this PR fixed the inconsistencies between get/opt Numbers

[johnjaylward]

This looks good to me. I think removal of the hexfloat is probably OK. It is not a standard in JSON anyway.

[stleary]

Possible problem with the unit tests?

[abimarank]

@stleary The test failures aren't from these changes, they must be there earlier too.

For example, consider the following test case

@Test
public void verifyConstructor() {
    
    final JSONArray expected = new JSONArray("[10]");
    
    @SuppressWarnings("rawtypes")
    Collection myRawC = Collections.singleton("10");
    JSONArray jaRaw = new JSONArray(myRawC);

    Collection<Integer> myCInt = Collections.singleton(Integer.valueOf(10));
    JSONArray jaInt = new JSONArray(myCInt);

    Collection<Object> myCObj = Collections.singleton((Object) 10);
    JSONArray jaObj = new JSONArray(myCObj);

    System.out.println(jaRaw.toString());

    assertTrue(
            "The RAW Collection should give me the same as the Typed Collection",
            expected.similar(jaRaw));
    assertTrue(
            "The RAW Collection should give me the same as the Typed Collection",
            expected.similar(jaInt));
    assertTrue(
            "The RAW Collection should give me the same as the Typed Collection",
            expected.similar(jaObj));
}

The line JSONArray expected = new JSONArray("[10]"); outputs "["10"]" not "[10]". Hence the test case is failed.

What should be the behaviour with numbers in String format when providing through the constructor?

[johnjaylward]

Something must be incorrect with the changes in this PR. That test case is correct.

[abimarank]

@johnjaylward Testcase is correct.

The line JSONArray expected = new JSONArray("[10]"); outputs "["10"]" not "[10]"

It's like instead of producing an array of int, it produces an array of String numeric literals. Any hint why this behaviour?

[abimarank]

I have fixed the issue with validating the String for numeric literals.

Do we need to consider 23.45e-4 as a valid numeral?

[stleary]

Modifying stringToNumber() may not be the best way to address this issue. The goal is for the get* and opt* methods to behave the same, while minimizing changes to existing behavior.