[
https://issues.apache.org/jira/browse/CAMEL-22894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-22894:
--------------------------------
Component/s: camel-core
> Refactor Simple/CSimple language implementation for better maintainability
> --------------------------------------------------------------------------
>
> Key: CAMEL-22894
> URL: https://issues.apache.org/jira/browse/CAMEL-22894
> Project: Camel
> Issue Type: Task
> Components: camel-core
> Reporter: Guillaume Nodet
> Priority: Major
>
> h2. Background
> The Simple and CSimple language implementations have grown organically over
> time and now present significant maintainability challenges. This issue is to
> discuss potential refactoring approaches with the community.
> h2. Current State Analysis
> || File || Lines || Concern ||
> | SimpleFunctionExpression.java | 3,713 | Dual responsibility: runtime + code
> generation |
> | CSimpleHelper.java | 1,199 | Static helper methods for compiled expressions
> |
> | SimpleFunctionStart.java | 707 | Function block handling |
> | SimpleTest.java | 3,595 | Simple language tests |
> | OriginalSimpleTest.java | 3,344 | Near-duplicate CSimple tests |
> | *Total* | *~12,500* | |
> h2. Key Issues
> h3. 1. Massive Class with Dual Responsibility
> {{SimpleFunctionExpression.java}} (3,713 lines) contains both:
> - {{createExpression()}} path for runtime Simple language
> - {{createCode()}} path for compile-time CSimple language
> Each function (body, header, variable, date, bean, file, math, etc.) is
> implemented *twice* with similar parsing logic but different output
> generation.
> h3. 2. Test Duplication
> {{SimpleTest.java}} and {{OriginalSimpleTest.java}} are essentially copies
> (~7,000 lines combined) with "simple" vs "csimple" language. When adding new
> features (e.g., ternary operator in CAMEL-22873), tests must be manually
> duplicated.
> h3. 3. Parallel Implementation Pattern
> Every AST node supporting csimple must implement both {{createExpression()}}
> and {{createCode()}}. Adding the ternary operator required ~140 lines of
> nearly duplicate code.
> h3. 4. String-Based Code Generation
> Code generation uses error-prone string concatenation:
> {code:java}
> return "Object value = " + exp + ";\n return convertTo(exchange, " +
> type + ", value)";
> {code}
> h2. Proposed Refactoring Approach
> h3. 1. Declarative Function Registry
> Replace if-else chains with declarative function definitions:
> {code:java}
> @SimpleFunction(name = "headerAs", syntax = "headerAs(key, type)")
> public class HeaderAsFunction implements FunctionDescriptor {
> Expression interpret(FunctionContext ctx) { ... }
> CodeFragment compile(FunctionContext ctx) { ... }
> }
> {code}
> h3. 2. Visitor Pattern for AST Processing
> Separate parsing from output generation:
> - Parse once → produce AST
> - InterpreterVisitor → produces Expression (Simple)
> - CodeGenVisitor → produces Java code (CSimple)
> h3. 3. Unified Test Framework
> Use JUnit 5 parameterized tests:
> {code:java}
> @ParameterizedTest
> @ValueSource(strings = {"simple", "csimple"})
> void testTernaryOperator(String languageName) {
> // Single test runs on both backends
> }
> {code}
> h3. 4. Type-Safe Code Generation
> Replace string concatenation with builders that can validate generated code.
> h2. Expected Benefits
> || Aspect || Current || After Refactoring ||
> | Add new function | Edit 2 places in 3700-line file | Create single class |
> | Add new operator | Edit multiple AST classes + tests | One AST node +
> visitor methods |
> | Test maintenance | Duplicate ~3500 lines | Single parameterized suite |
> | Estimated LOC | ~12,500 | ~6,000-7,000 |
> h2. Migration Approach
> This could be done incrementally:
> 1. Create unified test framework (low risk, immediate benefit)
> 2. Extract function registry, migrate functions one at a time
> 3. Introduce visitor pattern for new features
> 4. Migrate existing AST nodes to visitor pattern
> 5. Clean up legacy code
> h2. Questions for Discussion
> 1. Is there appetite for this level of refactoring?
> 2. Should we prioritize any specific aspect (e.g., tests first)?
> 3. Are there backward compatibility concerns to consider?
> 4. Should this be a GSoC or similar project given the scope?
> Related: CAMEL-22873 (ternary operator) exposed the maintenance burden when
> adding new features.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
