[#1695] Fix parsing of 'tru...' values inconsistent to true boolean

[laurentschoelens]

Fixes #1695
Adding test case to validate _parseBoolean function

[antoniosanct]

Hi, @laurentschoelens:

I have some questions about this PR because it could be some mistakes based on another tests at the same project:

• Are using JUnit 4 for any reason? You can extend JUnit 3's TestCase superclass by same manner than other tests that exists at the same project.
• You didn't fix the 'f' case clause. For this reason, unit tests in your own test file, lines 25, 34, 35, 36 and 41, expects null while the correct value would be false, according to use the same solution for 't' case clause.

Regards,
Antonio.

[laurentschoelens]

Hi @antoniosanct

Hi, @laurentschoelens:

I have some questions about this PR because it could be some mistakes based on another tests at the same project:

• Are using JUnit 4 for any reason? You can extend JUnit 3's TestCase superclass by same manner than other tests that exists at the same project.

Is there any reason to stay to JUnit 3 testing style ? Since JUnit 5 is out for a moment, I would say that the best option would be to start migration to JUnit 5.
I can sure adapt to JUnit 3.

• You didn't fix the 'f' case clause. For this reason, unit tests in your own test file, lines 25, 34, 35, 36 and 41, expects null while the correct value would be false, according to use the same solution for 't' case clause.

You're right. Since this class is deprecated and behaviour inconsistent, I didnt want to change too much.
Will fix more parseBoolean inconsistent results based on the same PR I did in API with more strict boolean checking : jakartaee/jaxb-api#279

Regards,
Antonio.

Regards,
Laurent

[antoniosanct]

@laurentschoelens
I'm agree with you about JUnit 5. My point is to use other PR to improve it.

[laurentschoelens]

@laurentschoelens
I'm agree with you about JUnit 5. My point is to use other PR to improve it.

Ok but I didnt add junit4 dependency, it was already in the classpath, no ?

[lukasj]

as long as the test runs as part of the build, it does not matter whether it is 3 or 4; 4 is on the classpath already

[laurentschoelens]

Let me fix my PR first before merging this one @lukasj

[laurentschoelens]

@antoniosanct new commit to be more accurate based on API impl (without throwing any excepion)

[antoniosanct]

Hi, @laurentschoelens
Is it correct to return instead of when it parses other string than "1" or "true"?
Regards,
Antonio!

[laurentschoelens]

@antoniosanct missing comment no ? 😄

[antoniosanct]

@laurentschoelens
Sorry, I wanted to say "1" or "true". Whatever, what's the best result when it parses other value than "1" or "true"?
https://www.w3.org/TR/xmlschema-2/#boolean
Thanks again!
Antonio

[laurentschoelens]

In my opinion and in author original spirit, when it parses 0 or false, it should return false, when something else, since not a boolean in xsd representation, that will be null or Exception (in api).
I've just aligned the impl code in jaxb-ri to the same code in api with that difference (null in ri vs exception in api)

[antoniosanct]

@laurentschoelens
OK for me! Thanks a lot for this PR!!

[lukasj]

LGTM