[
https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531494#comment-17531494
]
Hussachai Puripunpinyo commented on JEXL-367:
---------------------------------------------
[~henrib] We added a ton of things to JEXL. We also removed a lot of things
from JEXL.
For example, this one will work on our JEXL fork as well as JS
{code:java}
var list = [1, 2, 3];
var r = list.map(x => {return x * x}).reduce((acc, x) => { return acc + x});
console.log(r) {code}
We have data binding for Scala and Kotlin. When the list literal above is used
in Scala environment, it produces scala.immutable.List instead of
java.util.List. The map, reduce, and other functions defined in JS work out of
the box.
We also unwrap Java Optional, Scala Option, Kotlin Arrow Option and other
monadic types like Either and Try by default.
The dot notation (object navigation) is null-safe by default. So, for the
expression like a.b.c
if a is null, it's still fine. If b is Option, it will be unwrapped. There is
no other language can beat this succinctness :)
We also have some weird features that some objects can behave differently based
on the context it is used. Some objects can yield a dynamically computed value
instead of the object itself.
My users understand that this is not JS and they actually like it more than JS.
Like the above example. The return keyword can be omitted in JEXL but it's
required in JS. The JSON navigation works out of the box and it doesn't matter
what JSON library they are using, our JEXL fork understands their JSON tree and
walks it as if it is a regular object.
Unfortunately, the code is hosted in my company private repo and I'm kinda
believe that it's hard to request it to be open source
due to security concerns.
[~dmitri_blinov] You have a valid point, but I don't think it is good for JEXL
to be a unique language by its own. Honestly, JEXL as a language doesn't stand
a chance to compete with other languages out there. To be unique and making it
worth learning must come with substantial benefits that users will gain. The
key point is familiarity as most of my users do not want to be a JEXL expert.
My target users are not even a software engineer. They want to get the job done
with minimum effort. They usually don't care much about the beauty of code or
how smart the language is. They just want to utilize their existing knowledge.
I like that JEXL is similar to JS and it has some unique features that make it
even better for quick and dirty scripting (JEXL is much better than Coffescript
for example). My JEXL fork is also much more succinct than JS and it works well
across different JVM languages. Thanks to the extensibility of JEXL.
Before JEXL, we did use Nashorn as our javascript engine. It's not quite
secure, and the performance is really poor. On top of that, Nashorn has its own
types that we have to convert back and forth (We cannot create a native binding
so there is a big overhead right there). We cannot reuse existing
Java/Kotlin/Scala libraries there. Putting JS libraries and interpreting the
whole thing takes enormous time and resource. So, we didn't even dare to think
about doing it :D Later, Oracle announced that they would deprecate Nashorn in
Java11, and it was the last string for us. We were uncertain with the future of
the engine. So we dropped it and looked for another simple language to use.
Luckily I found the hidden gem, JEXL. So, we extended it instead of building
everything from scratch. Since Rhino is mentioned, I can tell you that Nashorn
is slow but it's still way faster than Rhino. Using JS engine in JVM, it means
we also have to deal with the platform compatibility and the code base that is
way harder to comprehend than JEXL because the full JS implementation is very
very complex.
> Deprecate -> and support =>
> ---------------------------
>
> Key: JEXL-367
> URL: https://issues.apache.org/jira/browse/JEXL-367
> Project: Commons JEXL
> Issue Type: Wish
> Affects Versions: 3.2.1
> Reporter: Hussachai Puripunpinyo
> Assignee: Henri Biestro
> Priority: Major
>
> The JEXL code surprisingly looks a lot like Javascript. I think this change
> is a good transition for folks to update the code, and it's pretty fine if
> they can tolerate using the deprecate syntax and don't mind seeing a warning
> log pop up every time.
> I'd like to propose supporting => and deprecate ->.
> The reasons are
> - JavaScript becomes very popular and many people are familiar with it.
> - JEXL is more like for a quick short script. In many scenarios, the target
> audiences are not a programer. They often mistake a language as a JavaScript
> (from my experience).
> - JEXL syntax already looks a lot like JavaScript
> -- var for variable declaration (Java added in Java 10, but JavaScript
> supports this from the beginning)
> -- The function keyword
> -- Implicit type coercion
> -- Ternary operator
> The proposed change.
> * Support => in addition to ->
> * Deprecate -> and show a warning log when it's used.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
