ramu11 commented on PR #25778: URL: https://github.com/apache/camel/pull/25778#issuecomment-5437158711
> Hello @ramu11 thanks for working on this! I see you implemented option A, the simpler one, that is fine as a first step. > > But I do think that in the future we should look into expanding this component capabilities to be in parity with the javascript one, since it is a language (like javascript), at least my expectation, is that they behave similarly, and hopefully, javascript can be easily replaced with quicks gaining portability (and hopefully) performance. > > To sum up, right now, it is possible to `Read body/headers/properties`, what the javascript component offer other than the read is: > > * `Mutate headers/properties from JS` > * `Call Java / Camel APIs` > > We can merge the PR as is, but it would be nice to check if implementing these features is feasible, and how javascript and quicks behave performance wise (a blogpost would comparing the two would be nice). > > @davsclaus @oscerd wdyt? Thanks for the additional feedback. I took a closer look at the existing camel-javascript implementation and the QuickJS4J capabilities to assess what would be involved in bringing QuickJS closer to JavaScript parity. The current Option A implementation can remain as-is for this PR. The requested capabilities are feasible, but they fall into two different areas: - Exchange mutation (setHeader, setProperty, setBody) is reasonably feasible using QuickJS host functions. This could be a relatively small follow-up, although we would need to carefully handle Exchange lifecycle and engine reuse. - General Java/Camel API access is a much larger piece of work. QuickJS4J provides host callbacks/host references, but it does not provide the same general Java host-object integration that GraalJS provides. Implementing equivalent functionality would require additional infrastructure for object wrapping, method dispatch, type conversion, exception handling, and lifecycle management. There is also a security/design consideration. The current JavaScript implementation uses GraalJS HostAccess.ALL, host class lookup, and IO access. I don't think we should automatically reproduce that model in QuickJS. A controlled/allowlisted host API, potentially opt-in, would be a safer direction for a future implementation. For the performance comparison, I agree it would be useful. The architectures are quite different: QuickJS currently reuses its engine but creates JSON snapshots of the Exchange data, while the JavaScript component creates a new GraalJS context per evaluation and exposes live Java objects. Therefore, I don't think we should make any performance claims without benchmarking representative Camel workloads. My suggestion would be to merge CAMEL-23398 with the current Preview/Option A scope, and consider separate follow-up work for: 1. Controlled Exchange mutation helpers. 2. A controlled Camel/Java host API. 3. A QuickJS vs GraalJS benchmark, which could provide the basis for the proposed blog post. This would allow us to establish the initial QuickJS language implementation without significantly expanding the scope of this PR, while keeping the path toward JavaScript parity open. suggestions/comments welcome -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
