On 02.02.2023 17:02, robertlazarski wrote:
On Thu, Feb 2, 2023 at 5:23 AM Rony G. Flatscher (Apache) <r...@apache.org>
wrote:
On 01.02.2023 14:42, robertlazarski wrote:
On Wed, Feb 1, 2023 at 3:32 AM robertlazarski <robertlazar...@gmail.com>
wrote:
A couple years ago after using J2V8 - they only support Android now - we
moved to the Javet project that is Apache licensed.
On a scale of 1/10 I give it a 10. They do an impressive release about
once a month lately and most importantly they ship with the latest V8
which
is important for us.
If you need something else besides JS though I have no idea.
I forgot about GraalVM but the performance wasn't much better than Rhino
but it is a small improvement.
For us, Javet is by far the best one out there.
It seems that Google's J2V8 according to [1] does not support JSR-223/BSF,
which is unfortunate as
it breaks/ignores the Java scripting framework (BSF 3 would have allowed
them to employ it in the
Harmony days already).
Your complaints seem to be about the speed of different JavaScript
implementations in Java, if I
read that correctly, and that you have experienced that Google's
JavaScript implementation is the
fastest and the preferred one for you.
---rony
[1] J2V8: <
https://eclipsesource.com/blogs/tutorials/getting-started-with-j2v8/>
The terminology here is confusing however it is important to get it right.
For the record, I am an Apache committer (PMC chair of Axis web services
and no relation here) and am speaking in terms of the state of JSR-223.
Speaking broadly here as not a contributor, but someone who built and
studied the source of these projects below.
V8 is the JavaScript engine that Google supports for Chrome. It is written
in C. It has no relation to JSR-223 besides some Java people want to run it
via JNI.
Java people usually use Java, JSR-223 is the package javax.script which should be used by scripting
engines. It would allow to exploit V8 from any Java application that employs javax.script for
executing scripts.
V8 progresses very rapidly in performance so old jars are not a good fit.
Not sure what you mean when referring to "old jars". java.lang.Object is probably older than many
"old jars", yet, it is of vital importance and up-to-date, despite being old. So age is not
necessarily an indicator for obsolescence.
J2V8 is a one man project with no relation to Google. At one point the
individual provided OS specific jars with C libs and JNI code but a while
back dropped all support except Android.
If javax.script/JSR-223 is not available on Android - not even in the OpenJDK deployments - then
this may make sense (having a non-standard, individual interface), however it impedes the Java
infrastructure in the scripting application area. In such a case BSF 3 may be helpful in bringing
javax.script to the Android table, allowing Java apps to exploit any scripting engine that is made
available to Android via this standard Java scripting framework. (Will eventually know more as I
might be able to explore these very waters on Android sometimes in the near future.)
Javet is a one man project as well, who like my day job also needed to move
on from J2V8.
Having briefly looked at
<https://sjtucaocao.medium.com/javet-java-and-javascript-interop-245c28210f32> what is described
there (allowing Java objects to be shared with the V8 JavaScript engine) is what the
javax.script/JSR-223 framework has been defining in a standardized way, cf. e.g. ScriptContext and
Bindings in <https://docs.oracle.com/javase/8/docs/api/javax/script/package-summary.html>. This way
a Java programmer can register whatever Java objects they want to share with the scripting engine
that evals the Java supplied script code.
---
To get an idea what javax.script (BSF3) allows for in the context of web applications (having
learned your PMC role in Apache Axis) you could take a look at
<https://sourceforge.net/projects/bsf4oorexx/files/Sandbox/rgf/taglibs/ga/> where JSPs programmed
with scripting languages becomes possible. There was a ApacheCon Tomcat presentation about it, the
slides can be found at
<https://sourceforge.net/projects/bsf4oorexx/files/Sandbox/rgf/taglibs/ga/AC21-Flatscher-EnablingScriptingLanguagesInJsps-v05.pdf>.
Demonstration examples were created in the scripting languages ooRexx (using BSF and implementing in
addition JSR-223), Nashorn JavaScript, Jython, PHP (caucho's Resin) and Groovy. Any scripting
language that has an implementation of javax.script.Engine (very simple to create if one extends
javax.script.AbstractEngine) could be used in addition out of the box.
There are also non-Web-related applications for which javax.script/JSR-223 script engines get
exploited for scripting and macros, as it makes it very easy for Java programmers to allow for
running scripts and macros against any Java application (adding scriptability to any Java
application). Another example may be Apache OpenOffice which supplies Java APIs. Thanks to the Java
APIs ooRexx (open object Rexx originally written by IBM in C++, open-sourced 2005 by
https://www.rexxla.org) can be used as a macro language and it can be used to write programs that
control AOO/LO via Java (both realized via the ooRexx-Java bridge BSF4ooRexx850) in a platform
independent manner (exploiting Java's "write once, run everywhere").
Notabene, if a scripting language implements javax.script/JSR-223 [Abstract]Engine it is a
no-brainer for acquainted Java developers to employ any such script engine easily for evaluating
scripts and even let them interact with supplied Java objects. Therefore I had assumed that V8
implements javax.script/JSR-223 making it immediately available as a Java scripting engine to any
Java application on any platform.
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
