[
https://issues.apache.org/jira/browse/LANG-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
尹茂椿萱 updated LANG-1821:
-----------------------
Description:
According to Java language syntax, hexadecimal numeric literals can be combined
with type qualifiers such as 'L' or 'l'. For example:
```java
long a = 0Xdefl; // valid Java literal, evaluates to 3567
However, {{NumberUtils.isCreatable(String)}} does not recognize such inputs as
valid numbers.
This suggests an inconsistency between the documented capabilities and the
actual implementation.
h2. Reproduction
import org.apache.commons.lang3.math.NumberUtils;
public class Test {
public static void main(String[] args)
{ long a = 0Xdefl; System.out.println(a); // 3567
System.out.println(NumberUtils.isCreatable("0Xdefl")); // false }
}
h2. Additional Cases
The following cases illustrate the inconsistency more clearly:
NumberUtils.isCreatable("123L"); // true
NumberUtils.isCreatable("0xdef"); // true
NumberUtils.isCreatable("0xdefL"); // false (unexpected)
NumberUtils.isCreatable("0XDEFl"); // false (unexpected)
h2. Expected Behavior
Inputs such as {{"0xdefL"}} and {{"0Xdefl"}} should be recognized as valid
numbers, and {{isCreatable}} should return {{{}true{}}}.
h2. Actual Behavior
{{NumberUtils.isCreatable("0Xdefl")}} returns {{{}false{}}}.
h2. Documentation Reference
The Javadoc for {{isCreatable}} states that:
* Hexadecimal numbers with {{0x}} or {{0X}} prefixes are supported.
* Numbers with type qualifiers (e.g., {{{}123L{}}}) are supported.
However, the combination of these two features (hexadecimal + type qualifier)
is not handled correctly.
h2. Impact
This issue may lead to incorrect validation results when processing numeric
strings that are valid Java literals, especially in contexts where hexadecimal
values with type qualifiers are expected.
h2. Possible Cause
The parsing logic in {{isCreatable}} appears to handle hexadecimal prefixes and
type qualifiers independently, but does not correctly support their combination.
h2. Suggested Fix
Extend the parsing logic to allow type qualifiers ({{{}L{}}}/{{{}l{}}}) after
hexadecimal numeric literals, consistent with Java syntax and existing support
for decimal numbers with qualifiers.
was:
Description
According to Java language syntax, hexadecimal numeric literals can be combined
with type qualifiers such as 'L' or 'l'. For example:
```java
long a = 0Xdefl; // valid Java literal, evaluates to 3567
However, {{NumberUtils.isCreatable(String)}} does not recognize such inputs as
valid numbers.
This suggests an inconsistency between the documented capabilities and the
actual implementation.
h2. Reproduction
import org.apache.commons.lang3.math.NumberUtils;
public class Test {
public static void main(String[] args)
{ long a = 0Xdefl; System.out.println(a); // 3567
System.out.println(NumberUtils.isCreatable("0Xdefl")); // false }
}
h2. Additional Cases
The following cases illustrate the inconsistency more clearly:
NumberUtils.isCreatable("123L"); // true
NumberUtils.isCreatable("0xdef"); // true
NumberUtils.isCreatable("0xdefL"); // false (unexpected)
NumberUtils.isCreatable("0XDEFl"); // false (unexpected)
h2. Expected Behavior
Inputs such as {{"0xdefL"}} and {{"0Xdefl"}} should be recognized as valid
numbers, and {{isCreatable}} should return {{{}true{}}}.
h2. Actual Behavior
{{NumberUtils.isCreatable("0Xdefl")}} returns {{{}false{}}}.
h2. Documentation Reference
The Javadoc for {{isCreatable}} states that:
* Hexadecimal numbers with {{0x}} or {{0X}} prefixes are supported.
* Numbers with type qualifiers (e.g., {{{}123L{}}}) are supported.
However, the combination of these two features (hexadecimal + type qualifier)
is not handled correctly.
h2. Impact
This issue may lead to incorrect validation results when processing numeric
strings that are valid Java literals, especially in contexts where hexadecimal
values with type qualifiers are expected.
h2. Possible Cause
The parsing logic in {{isCreatable}} appears to handle hexadecimal prefixes and
type qualifiers independently, but does not correctly support their combination.
h2. Suggested Fix
Extend the parsing logic to allow type qualifiers ({{{}L{}}}/{{{}l{}}}) after
hexadecimal numeric literals, consistent with Java syntax and existing support
for decimal numbers with qualifiers.
> NumberUtils.isCreatable fails for hexadecimal numbers with long type qualifier
> ------------------------------------------------------------------------------
>
> Key: LANG-1821
> URL: https://issues.apache.org/jira/browse/LANG-1821
> Project: Commons Lang
> Issue Type: Bug
> Affects Versions: 3.20.0
> Reporter: 尹茂椿萱
> Priority: Major
>
> According to Java language syntax, hexadecimal numeric literals can be
> combined with type qualifiers such as 'L' or 'l'. For example:
> ```java
> long a = 0Xdefl; // valid Java literal, evaluates to 3567
> However, {{NumberUtils.isCreatable(String)}} does not recognize such inputs
> as valid numbers.
> This suggests an inconsistency between the documented capabilities and the
> actual implementation.
> h2. Reproduction
>
>
> import org.apache.commons.lang3.math.NumberUtils;
> public class Test {
> public static void main(String[] args)
> { long a = 0Xdefl; System.out.println(a); // 3567
> System.out.println(NumberUtils.isCreatable("0Xdefl")); // false }
> }
>
> h2. Additional Cases
> The following cases illustrate the inconsistency more clearly:
>
>
> NumberUtils.isCreatable("123L"); // true
> NumberUtils.isCreatable("0xdef"); // true
> NumberUtils.isCreatable("0xdefL"); // false (unexpected)
> NumberUtils.isCreatable("0XDEFl"); // false (unexpected)
>
> h2. Expected Behavior
> Inputs such as {{"0xdefL"}} and {{"0Xdefl"}} should be recognized as valid
> numbers, and {{isCreatable}} should return {{{}true{}}}.
> h2. Actual Behavior
> {{NumberUtils.isCreatable("0Xdefl")}} returns {{{}false{}}}.
> h2. Documentation Reference
> The Javadoc for {{isCreatable}} states that:
> * Hexadecimal numbers with {{0x}} or {{0X}} prefixes are supported.
> * Numbers with type qualifiers (e.g., {{{}123L{}}}) are supported.
> However, the combination of these two features (hexadecimal + type qualifier)
> is not handled correctly.
> h2. Impact
> This issue may lead to incorrect validation results when processing numeric
> strings that are valid Java literals, especially in contexts where
> hexadecimal values with type qualifiers are expected.
> h2. Possible Cause
> The parsing logic in {{isCreatable}} appears to handle hexadecimal prefixes
> and type qualifiers independently, but does not correctly support their
> combination.
> h2. Suggested Fix
> Extend the parsing logic to allow type qualifiers ({{{}L{}}}/{{{}l{}}}) after
> hexadecimal numeric literals, consistent with Java syntax and existing
> support for decimal numbers with qualifiers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
