[
https://issues.apache.org/jira/browse/CAMEL-25166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18121151#comment-18121151
]
Claus Ibsen commented on CAMEL-25166:
-------------------------------------
Finding 11, from fixing the Java dumper (CAMEL-25157,
https://github.com/apache/camel/pull/27129): *model options the Java DSL cannot
express at all.* XML and YAML can write them, so a route in those DSLs cannot
be dumped as Java and a Java route cannot state them:
* {{throwException}} with a {{ref}} (about 100 of the camel-spring-xml test
routes use it): the Java DSL only has throwException(Exception) and
throwException(Class, String).
* Options of {{marshal}}/{{unmarshal}} such as
{{variableSend}}/{{variableReceive}}: marshal() returns a DataFormatClause,
which has no such option.
* {{log}} with a {{logger}} bean reference: the Java DSL takes a Logger object,
not its name.
* {{sort}} with a {{comparator}} reference only works through the clause form
sort().<language>.comparator("ref").
* Predicates built in Java ({{header("x").isEqualTo("y")}}) the other way
round: Java can state them, XML and YAML cannot (finding 2).
For Camel 5: every option of the model has a Java DSL form, checked by a test
that dumps every model option as Java and compiles it (the dumper's
JavaDslCompileTest and the round trip of CAMEL-25148 are the start of such a
test).
_Claude Code on behalf of davsclaus_
> 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
> Priority: Major
> 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)
