[jira] [Created] (CAMEL-25166) Camel 5 - Java DSL: findings from reading Java DSL routes without compiling them

["Claus Ibsen (Jira)" <ji...@apache.org>]

Claus Ibsen created CAMEL-25166:
-----------------------------------

             Summary: Camel 5 - Java DSL: findings from reading Java DSL routes without compiling them
                 Key: CAMEL-25166
                 URL: https://issues.apache.org/jira/browse/CAMEL-25166
             Project: Camel
          Issue Type: Improvement
          Components: camel-core
            Reporter: Claus Ibsen
         Attachments: camel5-java-dsl-findings.md

Input for a Java DSL in Camel 5, from the analysis done while building the lightweight Java DSL parser of CAMEL-25148 (the root of this analysis).

h3. Where the findings come from
CAMEL-25148 adds {{LwJavaParser}} to {{camel-java-io}}: it reads the routes of a Java DSL source into the Camel model without compiling it. The source is read as text and each chain of calls is replayed against Camel's own DSL; nothing of the project is loaded or run (design: {{design/java-dsl-parser.adoc}}). To make it read what people really write, it was run over about 8,400 Java sources with about 18,000 routes: the tests of the components and of camel-core, the camel-spring-boot and camel-quarkus repositories, the three example repositories, and round trips of the XML test routes through the Java dumper.

What was hard for the parser is what a Camel 5 Java DSL could avoid, for people and for tools alike (TUI, AI, documentation checks, low-code editors).

h3. Findings (details, examples and numbers in the attached camel5-java-dsl-findings.md)
# *Block scoping by return types.* end()/endChoice()/endDoTry() close whatever is open; routingSlip(...).doCatch(...) does not compile while to(...).doCatch(...) does; steps after onFallback() go into the fallback. The nesting in the code is not the nesting in the model.
# *Expression clauses and ValueBuilder predicates have no language form.* setHeader("x").constant("y"), header("x").isEqualTo("y") keep Java objects in the model, which no DSL can write (the Java dumper writes expression("")).
# *The same option as a Class or its name* (throwException(Foo.class) vs exceptionType, typeClass vs type, unmarshalType vs unmarshalTypeName): about 25 such pairs in the model.
# *Overloads where Object and String mean different things* (method(Object, String) vs method(String, String)): only Java's most-specific rule chooses right.
# *Varargs pairs* (setHeaders("h1", expr, "h2", expr)): meaning by position only.
# *Unqualified names clashing across builders and static imports* (bean(...) is the bean component in the endpoint DSL, an aggregation strategy with a static import).
# *The endpoint DSL follows rules with exceptions* (clas, coapTcp, coapsTcp, restEndpoint), and multi-value option prefixes are only in the catalog.
# *Constants and header names live in component classes* (KafkaConstants.KEY, HazelcastOperation.PUT_IF_ABSENT): a tool needs the component jar or the catalog.
# *Routes are code:* ports, injected fields, helper methods and loops build URIs where properties and templates would keep them data.
# *Processors and lambdas are opaque:* about 1,200 in camel-core's tests alone, with no name or purpose a tool can show.

h3. A bridge from the current Java DSL
The parser's replay (current Java DSL source -> current DSL -> model, without compiling) is the natural shape of a bridge: an adapter JAR keeping the current DSL working on the Camel 5 model, and a migration tool reading current routes with LwJavaParser and writing the Camel 5 DSL, saying which routes need hand work. The corpora above are the test suite for both.

_Claude Code on behalf of davsclaus_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)