Claus Ibsen created CAMEL-24976:
-----------------------------------
Summary: camel-core - Type converter: fix bugs found in a deep
review
Key: CAMEL-24976
URL: https://issues.apache.org/jira/browse/CAMEL-24976
Project: Camel
Issue Type: Bug
Components: camel-core
Reporter: Claus Ibsen
A deep review of the core type converter (CoreTypeConverterRegistry,
TypeResolverHelper and the core converters in camel-base) found several
correctness bugs. All of the items below were reproduced against
4.23.0-SNAPSHOT.
*Registry (CoreTypeConverterRegistry / TypeResolverHelper)*
# Converting to a primitive type returns the value unchanged when it is an
Integer or Long, whatever primitive was asked for. convertTo(int.class, 5L)
returns a Long and convertTo(double.class, 5) returns an Integer, so callers
get a ClassCastException. User impact: a bean method with an int parameter
fails with "argument type mismatch" when the body is a Long.
# tryConvertTo(boolean.class, "abc") throws TypeConversionException instead of
returning null.
# The miss cache is keyed by class pair, but fallback converters decide per
value:
#* one value a fallback cannot convert makes every later value of the same
class pair return null, even values the fallback can convert.
#* a converter or fallback added after a miss is never consulted for that pair.
#* the miss marker is found by the super-type scans (tryMatch /
tryAssignableFrom), so a miss on Base -> X also blocks Sub -> X.
#* lookup(to, from), lookup(to) and getTypeConverter(to, from) return the
internal miss marker, so callers checking lookup(...) != null believe a
converter exists.
# When several super-type converters match, the one chosen depends on
ConcurrentHashMap iteration order, which changes between JVM runs (see
CAMEL-21513).
# The last-resort Object -> type lookup uses the primitive type rather than its
wrapper.
*Converters*
# ObjectConverter.toNumber("-3000000000") throws NumberFormatException,
toNumber("2147483647") returns a Long, and exponent notation such as "1e5"
fails.
# ObjectConverter.toBigInteger(BigDecimal("123456789012345678901234")) returns
a wrong value with the wrong sign (it goes through longValue()).
# String -> TimeUnit does not support MICROSECONDS.
# String -> ByteBuffer ignores the charset from the exchange (CamelCharsetName
header) and uses the JVM default.
# ArrayTypeConverter returns a List when a Set is requested, which causes a
ClassCastException.
# Enum conversion is case-insensitive first-hit, so an exact match is not
preferred (enum E { a, A }: "A" becomes a).
# byte[] -> char sign-extends, so 0xE9 becomes a wrong character.
# A converter obtained via lookup() leaks the internal Void.class "null value"
marker instead of returning null (BulkTypeConverters default convertTo).
# FutureTypeConverter does not restore the thread's interrupt flag when
interrupted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
