aeberhart commented on PR #12670: URL: https://github.com/apache/camel/pull/12670#issuecomment-1882844229
I am one of the maintainers of the new jsonata lib. I wanted to provide some context on this lib and hopefully ease some of the concerns that @orpiske rightfully voiced about changing dependencies. You can find a list of JSONata implementations here: https://docs.jsonata.org/next/overview. At the moment there are two Java implementations: [JSONata4Java](https://github.com/IBM/JSONata4Java) and [jsonata-java](https://github.com/dashjoin/jsonata-java). We use JSONata heavily for our low code platform (https://github.com/dashjoin/platform) and started out with JSONata4Java. Works great but there are some [limitations](https://github.com/IBM/JSONata4Java?tab=readme-ov-file#current-limitations) with more complex expressions which can be frustrating because something that works in the JSONata playground does not in the Java environment. Then we decided to leverage the JS language reference via graal, which worked but had some performance issues. Finally, we started our Java version which is a 1:1 port of the original JS reference implementation to Java. This ensures * 100% compatibility with the language specification * an easy path to port future changes in the language and bugfixes into the Java world by keeping the code structure, comments, formatting of the original as much as possible As far as I know, there are no expressions that evaluate differently when changing the library. This means that Camel code does not have to be changed when upgrading. We're also committed to maintaining the library. Of course more contributors are always 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: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
