// Do not edit directly!
// This file was generated by camel-quarkus-maven-plugin:update-extension-doc-page
[id="extensions-js-dsl"]
= JavaScript DSL
:linkattrs:
:cq-artifact-id: camel-quarkus-js-dsl
:cq-native-supported: true
:cq-status: Experimental
:cq-status-deprecation: Experimental
:cq-description: An JavaScript stack for parsing JavaScript route definitions
:cq-deprecated: false
:cq-jvm-since: 1.8.0
:cq-native-since: 1.8.0

ifeval::[{doc-show-badges} == true]
[.badges]
[.badge-key]##JVM since##[.badge-supported]##1.8.0## [.badge-key]##Native since##[.badge-supported]##1.8.0##
endif::[]

An JavaScript stack for parsing JavaScript route definitions

[id="extensions-js-dsl-whats-inside"]
== What's inside

* xref:{cq-camel-components}:others:js-dsl.adoc[JavaScript DSL]

Please refer to the above link for usage and configuration details.

[id="extensions-js-dsl-maven-coordinates"]
== Maven coordinates

[source,xml]
----
<dependency>
    <groupId>org.apache.camel.quarkus</groupId>
    <artifactId>camel-quarkus-js-dsl</artifactId>
</dependency>
----
ifeval::[{doc-show-user-guide-link} == true]
Check the xref:user-guide/index.adoc[User guide] for more information about writing Camel Quarkus applications.
endif::[]

[id="extensions-js-dsl-camel-quarkus-limitations"]
== Camel Quarkus limitations

Since the function `Java.extend` https://www.graalvm.org/latest/reference-manual/js/JavaInteroperability/#extending-java-classes[is only available in JVM mode], by default, there is no way to implement a functional interface like a `Camel Processor` in JavaScript that is supported by the native compilation.

As workaround, an implementation of the main functional interfaces (`org.apache.camel.Processor`, `java.util.function.Consumer`, `java.util.function.Supplier`, `java.util.function.Function`, `java.util.function.Predicate`, `java.util.function.BiConsumer`, `java.util.function.BiFunction` and `java.util.function.BiPredicate`) is available in the package `org.apache.camel.quarkus.dsl.js.runtime` whose simple name is prefixed by `JavaScriptDsl`. For each implementation, the body of the method to implement must be provided to the constructor. When the method to implement has arguments, the name of the arguments can also be provided to the constructor if the default names are not good enough.

So for example, to implement a `Camel Processor` instead of using the function `Java.extend` which is only available in JVM mode as next:

[source,javascript]
----
const Processor = Java.type("org.apache.camel.Processor"); // <1>
const p = Java.extend(Processor); // <2>
const a = new p(e => { e.getMessage().setBody('Some Content') }); // <3>

from('direct:a')
    .process(a); // <4>
----
<1> Retrieve the class `org.apache.camel.Processor`
<2> Create a new class that implements the functional interface `org.apache.camel.Processor`
<3> Instantiate the new class with a function as argument representing the implementation of the method to implement
<4> Provide the processor to the route definition.

To have a code compatible with the both modes, it is possible to instantiate directly the implementation of the corresponding functional interface which is in this case the class `org.apache.camel.quarkus.dsl.js.runtime.JavaScriptDslProcessor` as next:

[source,javascript]
----
const Processor = Java.type("org.apache.camel.quarkus.dsl.js.runtime.JavaScriptDslProcessor"); // <1>
const p = new Processor("e", `e.getMessage().setBody('Some Content')`); // <2>

from('direct:a')
    .process(p); // <3>
----
<1> Retrieve the class `org.apache.camel.quarkus.dsl.js.runtime.JavaScriptDslProcessor`
<2> Instantiate the dedicated class with the name of the argument `e` as first parameter and the body of the function as second parameter representing the implementation of the method to implement
<3> Provide the processor to the route definition.

