CAMEL-22894: Refactor SimpleFunctionExpression: introduce function-factory dispatcher (part 1)

[ammachado]

Description

First incremental step toward CAMEL-22894: break up the 4,500-line SimpleFunctionExpression that today carries both runtime Simple language and compile-time CSimple code-generation responsibilities, with no behavior change.

This PR establishes the pattern and ports the first batch of small built-in families. Larger families (header, exchangeProperty, the rest) will follow in subsequent PRs once the dispatcher pattern lands.

Three commits, each independently reviewable:

1. fc43e0d — Deprecate SimpleLanguageFunctionFactory#createCode. The createCode(...) method on the public SimpleLanguageFunctionFactory SPI (@since 4.10) exists solely to support csimple, which is already @Deprecated(since = \"4.19\") and slated for removal in 5.0. Marked the method @Deprecated(since = \"4.21\") and made it a default returning null, so implementations that don't care about csimple no longer have to override it. The three in-tree implementations (camel-attachments, camel-base64, camel-jsoup) keep their existing overrides and pick up the deprecation marker via inheritance.

2. 4beafc9 — Centralize external-component function dispatch in SimpleFunctionDispatcher. SimpleFunctionExpression previously had six near-identical methods plus six gating predicate blocks dedicated to dispatching to the three external SimpleLanguageFunctionFactory implementations (camel-attachments, camel-base64, camel-jsoup). Moved the dispatch into a new internal SimpleFunctionDispatcher that owns the list of known component factories and their gating predicates, exposing tryCreate(...) / tryCreateCode(...) entry points. Behaviour preserved exactly: same factories, same order, same gating (so a missing component still surfaces the helpful "add this JAR" error via ResolverHelper.resolveMandatoryBootstrapService), and camel-jsoup remains excluded from the csimple createCode path because its createCode throws UnsupportedOperationException.

3. 63d326e — Extract random, skip, collate, join into SimpleLanguageFunctionFactory classes. Moved four self-contained Simple functions out of SimpleFunctionExpression into their own factory implementations under org.apache.camel.language.simple.functions, registered as built-ins on SimpleFunctionDispatcher. The dispatcher consults built-ins before external component factories, preserving today's priority. Both createFunction (Simple) and createCode (csimple) live side by side in each class, instead of being ~2,000 lines apart in SimpleFunctionExpression.

Net structural impact so far:

• SimpleFunctionExpression.java: 4,526 → ~4,255 lines (−270 LOC), with the new dispatcher (~150 LOC) and four small factory classes (~300 LOC combined).
• Adding a new external-component factory is now a one-line edit in SimpleFunctionDispatcher instead of a six-block change spread across SimpleFunctionExpression.
• Built-in extraction template established for follow-up PRs.

Out of scope for this PR (and the broader refactor, see plan locked in JIRA discussion):

• No public-API additions (no new SPI, no addFunctionFactory(...) on SimpleFunctionRegistry).
• No CSimple-side restructure: no visitor pattern, no type-safe code-generator, no parameterized cross-tests. The current generated csimple Java source is identical before/after.
• No classloader auto-discovery of factories — would not work in Quarkus native; current explicit allowlist is the right shape.

Verification:

• mvnd clean install -Dquickly -Dci.env.name=local from repo root: ✅ BUILD SUCCESS.
• SimpleTest (227), CSimpleTest (1), SimpleCustomFunctionTest (5), CSimplePredicateParserTest (4), CSimpleExpressionParserTest (13), SimpleExpressionParserNodesTest (2), SimplePredicateParserNodesTest (3): all green.
• camel-attachments SimpleAttachmentTest (10), camel-base64 SimpleBase64Test (2), full camel-jsoup test suite (3): all green.
• mvn formatter:format impsort:sort clean.

Review follow-up after the initial proof-of-concept commits:

The first three commits were intentionally scoped to prove the extraction/dispatcher pattern and get reviewer feedback on the shape before applying it more broadly. Based on that review, this branch now also:

• restores the original built-in evaluation order
• extracts codeSplitSafe(...) into SimpleFunctionHelper
• fixes the pre-existing skip(...) runtime/code inconsistency
• moves the touched function coverage into dedicated factory unit tests

Target

• I checked that the commit is targeting the correct branch (Camel 4 uses the main branch)

Tracking

• If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

• 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.

---

Claude Code on behalf of Adriano Machado

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• core/camel-api
• core/camel-core-languages
• core/camel-core

ℹ️ Dependent modules were not tested because the total number of affected modules exceeded the threshold (50). Use the test-dependents label to force testing all dependents.

⚠️ Some tests are disabled on GitHub Actions (@DisabledIfSystemProperty(named = "ci.env.name")) and require manual verification:

• core/camel-core: 2 test(s) disabled on GitHub Actions

Build reactor — dependencies compiled but only changed modules were tested (3 modules)

• Camel :: API
• Camel :: Core
• Camel :: Core Languages

---

⚙️ View full build and test results

[davsclaus]

We are not keeping csimple until camel 5 in so many years. It will be removed sooner. Its not really in use by end users. And users who use it can easily use regular simple

[davsclaus]

Review — CAMEL-22894: Refactor SimpleFunctionExpression: introduce function-factory dispatcher (part 1)

Well-structured refactoring PR with clear scope boundaries. The three-commit structure is easy to follow, and the PR description is exemplary. CI is green and no blocking issues found.

Observations

1. (Low) Evaluation order change for random, skip, collate, join

In the original code these four functions are evaluated inside createSimpleExpressionMisc() which runs before createSimpleExpressionMath(). After this PR they are evaluated via the dispatcher after math. Since these function names (random(, skip(, collate(, join() have no overlap with math function patterns, this is harmless in practice. But the PR description states "Behaviour preserved exactly" — this is a safe ordering change rather than exact preservation, and worth acknowledging.

2. (Low) JoinFunctionFactory couples back to SimpleFunctionExpression.codeSplitSafe()

For the follow-up PRs, codeSplitSafe should move to a shared utility (e.g. SimpleParserHelper) as more factories are extracted. Not blocking for this PR.

3. (Low) No dedicated unit tests for individual factory classes

The existing SimpleTest (227 tests), CSimpleTest, etc. cover behavioral correctness. As more factories are extracted in follow-up PRs, per-factory unit tests would help catch regressions faster.

Verified Clean

• SkipFunctionFactory correctly uses StringHelper.before() in createFunction and StringHelper.beforeLast() in createCode, matching the original.
• The @Deprecated default createCode returning null is safe — existing overrides in camel-attachments/base64/jsoup continue working.
• @Deprecated(since = "4.21") without forRemoval is consistent with existing csimple deprecation convention.
• CI green, formatting clean.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[gnodet]

Claude Code on behalf of Guillaume Nodet

Good first step toward decomposing the 4,500-line SimpleFunctionExpression. The commit structure is clean — deprecation, dispatcher, extraction are each independently reviewable. Two issues to address before merge (see inline comments), plus a few suggestions.

Summary of findings:

1. (blocking) SkipFunctionFactory: before vs beforeLast inconsistency — createFunction uses StringHelper.before() while createCode uses StringHelper.beforeLast(). This is a pre-existing bug faithfully ported from the original code, but since we're touching this code now, we should fix it.

2. (blocking) Ordering change for extracted built-ins — random, skip, collate, join previously evaluated in createSimpleExpressionMisc() (before createSimpleExpressionMath()). Now they evaluate via the dispatcher (after math). Safe in practice since these prefixes don't collide with math patterns, but the PR description claims "behaviour preserved exactly" — this should be acknowledged or addressed.

3. (major) Circular dependency — JoinFunctionFactory calls SimpleFunctionExpression.codeSplitSafe(...), creating a dependency from the extracted factory back into the monolith being decomposed.

4. (minor) Javadoc/comment mismatches — The dispatcher Javadoc and inline comments don't reflect that it now handles both built-in and external functions.

[ammachado]

The first three commits were intentionally scoped to prove the extraction/dispatcher pattern and get reviewer feedback on the shape before applying it more broadly. Based on that review, this branch now also:

• restores the original built-in evaluation order
• extracts codeSplitSafe(...) into SimpleFunctionHelper
• fixes the pre-existing skip(...) runtime/code inconsistency
• moves the touched function coverage into dedicated factory unit tests

[gnodet]

All review feedback has been addressed:

• SkipFunctionFactory before/beforeLast inconsistency fixed
• Evaluation ordering restored (built-ins dispatched before misc/math)
• Circular dependency removed (codeSplitSafe moved to SimpleFunctionHelper)
• Javadoc and comments updated to reflect both built-in and external dispatch
• record Entry replaced with conventional static final class
• Dedicated per-factory unit tests added, routed through the full language pipeline

Claude Code on behalf of Guillaume Nodet

[davsclaus]

thanks part 2 is welcome