Re: ad J2V8 (Re: Commons bsf

[Rony G. Flatscher (Apache)]

On 02.02.2023 17:02, robertlazarski wrote:

On Thu, Feb 2, 2023 at 5:23 AM Rony G. Flatscher (Apache) 
wrote:


On 01.02.2023 14:42, robertlazarski wrote:

On Wed, Feb 1, 2023 at 3:32 AM robertlazarski 
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 

ad J2V8 (Re: Commons bsf

[Rony G. Flatscher (Apache)]

On 01.02.2023 14:42, robertlazarski wrote:

On Wed, Feb 1, 2023 at 3:32 AM robertlazarski 
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: 




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Ad git-related information (Re: Commons bsf

[Rony G. Flatscher (Apache)]

Bonjour Gilles,

On 01.02.2023 13:53, Gilles Sadowski wrote:

Le mer. 1 févr. 2023 à 13:27, Rony G. Flatscher (Apache)
  a écrit :

[...]
One thing that will take me some time is re-orienting myself to
<https://github.com/apache/commons-bsf>  and learn about becoming able to 
commit there

Why "there", when you can commit directly here (at ASF "Commons")?


(not sure
where I would have to register/report my github id such that it can be 
associated with my ASF id).

https://whimsy.apache.org/roster/committer/__self__


thank you very much!

Also to get up and running with Apache git:

 * Apache git primer: https://infra.apache.org/git-primer.html
 * Apache git repositories: https://gitbox.apache.org/repos/asf
 * Apache self-service platform: https://selfserve.apache.org/

Best regards

---rony

Re: Commons bsf

[Rony G. Flatscher (Apache)]

On 01.02.2023 09:49, sebb wrote:

On Wed, 1 Feb 2023 at 00:22, Alex O'Ree  wrote:

No problem. There was some activity on github.

Please note: That does not mean the component is being developed.
Dependabot runs on most components, and that generates traffic.
Also there may need to be changes to asf.yaml which affect all
components on github.
Etc. This is no indication that the component is being actively
maintained, as such changes need very little (if any) knowledge of the
component.


Well, I have been interesting in keeping BSF up and going.


I ran the owasp dependency
check thing against it and found a few issues, attempted to update some of
the dependencies (jython) and hit a bit of a snag. I'm not entirely sure
where to go from here. I'm not sure if anyone else has attempted this or
not.

Note that the component has a separate 3.x version, which is based on
JSR-223 - see https://commons.apache.org/proper/commons-bsf/

I’m not entirely sure that either are still needed.


BSF 3.0, the open-source implementation JSR-223 (package javax.script) may not be needed anymore 
with OpenJDK containing it.



On Tue, Jan 31, 2023 at 6:34 PM Gary Gregory  wrote:


This is an open source project, so support is as best as us volunteers see
fit or have itches to scratch ;-)

In this case the lack of activity might show that the original authors
could have abandoned the component. Let's see how else pipes in.
At least one project (BSF4ooRexx, e.g. ) 
has been actively using it.

On Tue, Jan 31, 2023, 17:21 Alex O'Ree  wrote:


Is the bsf library still supported? Looks like the website hasn't been
published since 2011.


This is mostly a question of free time on one's hands. E.g. for the BSF4ooRexx project I have a few 
little changes applied to BSF which I have always been meaning to incorporate.


Alex, your initiative w.r.t. jython and the website are highly welcome!

---rony

P.S.: Will try to assess the differences between the official BSF and the one in BSF4ooRexx in the 
next weeks (time permitting) and then adding the few enhancements with JIRA tickets for tracking. 
One thing that will take me some time is re-orienting myself to 
 and learn about becoming able to commit there (not sure 
where I would have to register/report my github id such that it can be associated with my ASF id).




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

BSF? (Re: [SCXML] Javascript as expression language

[Rony G. Flatscher (Apache)]

Hi Ingmar,

how did that get implemented?

Did you use by any chance BSF http://jakarta.apache.org/bsf? If so,
then not only JavaScript/Rhino would be available, but any of the
supported scripting languages!

---rony



Ingmar Kliche wrote:
 Hi Roger,

 yes, we have implemented it and plan to provide it to the project quite
 soon. But the licensing issue is a good point and should be clarified.
 Technically the implementation needs some final cleanup and things like test
 cases. If you can wait another couple of weeks (due to holiday season) it
 should be available.

 Regards,
 Ingmar.

 2008/12/16 Roger Hoover roger.hoo...@gmail.com

   
 Hi,

 Has anyone implemented Javascript as an expression language in SCXML Common
 with Rhino?  Would there be licensing issues with SCXML under Apache
 license
 and Rhino under MPL/GPL/LGPL triple license?

 If it can't be done as part of this project, how hard would it be to
 implement externally and do others have interest in it?

 Thanks,

 Roger