Support binary literal format for String to Number conversion

[MightyEagle82]

At the moment there is support for hexadecimal literals but not for binary:

• 0xF0 - allowed
• 0b11110000 - disallowed

[sbrannen]

We actually provide support for decimal, hexadecimal, and octal numbers simply because that's what java.lang.Integer.decode(String) and related decode() methods support.

I had forgotten about binary literals, since I never use them personally, but...

Starting in J2SE 7.0, as binary numbers, using the form 0b (or 0B) followed by one or more binary digits (0 or 1). For example, 0b101010 is the integer 42. Like octal and hex numbers, binary literals may represent negative numbers.

So, although we could potentially introduce explicit support for binary literals in org.junit.platform.commons.support.conversion.StringToNumberConverter, I think it may also be a good idea to request direct support in the JDK (in Byte::decode, Short::decode, Integer::decode, and Long::decode).

@sormuras, thoughts?

[sormuras]

https://bugs.openjdk.org/browse/JDK-7181749 "Integer.decode("0b1010101") fails" has:

Duplicate of functionality requested in comments of 6863378; closing accordingly.

Which in turn https://bugs.openjdk.org/browse/JDK-6863378 "Project Coin: Consider library support for underscores in numbers and binary literals" has:

"Not essential functionality; closing as will not fix."

So, supporting such conversions is an option for JUnit - if there's enough interest from users and we are willing to maintain it.

[MightyEagle82]

Guys, thank you for the replies anyway.

It was the first time when I decide to use CsvSource instead of MethodSource to provide binary values for test arguments. I haven't faced with decode methods until now. After posting this issue I found that they didn't support binary literals and was very surprised.

I understand that JUnit relies on JDK API. So it won't be a problem if you just close this issue with won't be fixed status.