ammachado opened a new pull request, #28651: URL: https://github.com/apache/camel/pull/28651
# Description [CAMEL-26392](https://issues.apache.org/jira/browse/CAMEL-26392), tier 1 item #6 of [CAMEL-25132](https://issues.apache.org/jira/browse/CAMEL-25132). Converting a String to an enum (`convertTo(LoggingLevel.class, "INFO")`, an operation header read as an enum, a predicate on an enum header) goes through `EnumTypeConverter`, which first asks `TypeConverterRegistry.lookup(enumType, String.class)` for a dedicated converter. Almost no enum has one, and `lookup` ran `TypeResolverHelper.doLookup` on every call: the exact map lookup, a breadth-first walk of `String`'s type hierarchy twice (`tryMatch`, `tryPrimitive`), `tryAssignableFrom`, which scans all the converters and computes type distances, and the `Object` converter. The registry records misses (`MISS_CONVERTER`) only on the `convertTo` path, which does not run for this pair. Changes: 1. **`CoreTypeConverterRegistry.lookup` caches its results, misses included**, in a map of its own (not in `converters`, so `listTypeConverters()`, the statistics and the TUI tab do not change). Caching a miss is safe here, unlike on the `tryConvertTo` path ([CAMEL-22564](https://issues.apache.org/jira/browse/CAMEL-22564)), because `lookup` does not use the fallback converters, so its result depends only on the two types. The cache is cleared: - in `clearMisses()`, which every `add*` method calls; - in `removeTypeConverter()`, which does not call `clearMisses()`; - when the convert path puts a converter for a pair of types (a fallback that converted, an assignable, `Object` or super type match), but only if that changes the stored converter, so a fallback that converts again does not clear it on every exchange. A lookup reads a version counter before resolving and drops its result if the cache was cleared meanwhile, so a lookup that races with an added converter does not keep a stale result. 2. **`EnumTypeConverter` caches the enum constants per enum type** with a `ClassValue`, as `getEnumConstants()` copies them on every call (up to 3 times per conversion). 3. **`EnumTypeConverter.tryConvertTo` returns `null`** when no enum constant matches, instead of creating an `IllegalArgumentException` that `CoreTypeConverterRegistry.tryConvertTo` ignored. `convertTo` throws as before. A converter found by the lookup is still called inside a try/catch on the try path. Measured locally (JDK 25 on macOS, single thread, 200k calls after 200k warm-up calls, `ThreadMXBean` allocated bytes) with the type converter of a `CamelContext`: | | before | after | |---|---|---| | `convertTo(LoggingLevel, "INFO")` | 1180 ns, 1560 B | 14 ns, 24 B | | `tryConvertTo(LoggingLevel, "NOPE")` | 2604 ns, 4040 B | 165 ns, 856 B | New `TypeConverterLookupCacheTest`, on a `DefaultTypeConverter` that counts the calls to `doLookup`: - a found converter and a miss are each resolved once (fails before this change: resolved twice); - an added converter replaces a cached miss, a removed converter replaces a cached hit, and a fallback that converted is returned by `lookup` afterwards; - enum conversion without a matching constant: `tryConvertTo` gives `null`, `convertTo` throws a `TypeConversionException` with the same `IllegalArgumentException` message as before. Verified: the full camel-core test suite, 8404 tests, 0 failures, 44 skipped (`@Disabled` or manual tests on main). One flake, `DefaultTimeoutMapTest.testExpiredInCorrectOrder` (a timer-based expiry test that does not use the type converter), passed on the rerun. [CAMEL-25231](https://issues.apache.org/jira/browse/CAMEL-25231) (non-deterministic source type selection) is about the same resolver. This change caches whichever converter the resolver picks first; since CAMEL-21513 that pick no longer depends on map order. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. Not from the root folder: I built and installed the changed module (camel-base), ran `mvn formatter:format impsort:sort` on the changed modules, and `git status` was clean afterwards. # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. The code and this description were written with Claude Code (Claude Opus 5.5) and reviewed by me. 🤖 Generated with [Claude Code](https://claude.com/claude-code) on behalf of Adriano Machado (@ammachado) _This was generated by an AI agent and may contain inaccuracies. Please verify before relying on it._ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
