Possible problem with the unit tests?

@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?

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

@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?

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

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

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.