- Java support in LibreOffice is optional ... A large percentage of user disables the Java runtime environment in LibreOffice, for many reasons.
Macros, especially in Calc is a key feature, and enhance programming languages powerful and easy to learn seems like a good idea. It is also a bit to free themselves from dependence to Java in LO.
Open source alternatives: SpiderMonkey and V8.
Let's set to NEW and see what happens.
It seems choosing Spidermonkey would be shooting ourselves in the foot:
An promising choice (that the Polkit devs are considering) would be http://duktape.org/
Duktape is easy to integrate into a C/C++ project: add duktape.c, duktape.h, and duk_config.h to your build, and use the Duktape API to call Ecmascript functions from C code and vice versa.
I was thinking to create an integration between dukescript and libreoffice.
This could be a first step to give it a try.
Already some work in progress in your side ?
(I'm currently in the technical study step)
(In reply to Johan PIQUET from comment #3)
> I was thinking to create an integration between dukescript and libreoffice.
> This could be a first step to give it a try.
> Already some work in progress in your side ?
> (I'm currently in the technical study step)
Dukescript seems to be using Java: https://dukescript.com/
I think it would not be added to LibreOffice as they want to remove Java dependencies, but you can of course do it as an extension.
Sorry, I mean "duketape" not "dukescript".
(In reply to Johan PIQUET from comment #5)
> Sorry, I mean "duketape" not "dukescript".
Oh ok :) I'm not a dev, so have not done anything. You could study the thing a bit and then post a proposal to the developer mailing list.
this is utterly irrelevant - your macro is going to call heavy and slow LibreOffice code via heavy and slow UNO bridge that looks up every method
to call via UNO reflection, so it will never be fast anyway.
SpiderMonkey and V8 are very large and complex C++ projects with unstable APIs so integrating them would be very painful (cf. the ongoing Firebird disaster).
also they have their own GC whereas Rhino uses the Java GC, so switching would make our distributed-GC problem (which already exists between Java and Python) worse and leak memory (can't collect cycles).
for LO scripting anyway, there is ~no documentation for it,
in fact there was a plan to unbundle all the Java Scripting Host based
stuff to an extension and the only reason that didn't get done
is that nobody had the time to work on it.
see ESC minutes from 08.11.2012:
+ could be turned into an extension
+ was in the past was turned off (Stephan)
AA: + disable Rhino / Beanshell unless in experimental mode (Michael)
+ for future deprecation / removal.
(In reply to Michael Stahl from comment #7)
(In reply to Michael Stahl from comment #7)
> for LO scripting anyway, there is ~no documentation for it,
Which is sadly a Catch 22: Without documentation, it is no wonder that no one uses it.
I think it would be great to have a better JS support and (better/any) documentation. JS is a widespread language and would enable to tap into a different group of devs (if that is wanted).
There is now also QuickJS from Fabrice Bellard & friends: https://bellard.org/quickjs/
Out of curiosity I tried Rhino and QuickJS on the bench-v8 version 7 benchmark (https://github.com/mozilla/arewefastyet/tree/master/benchmarks/v8-v7), used on the official QuickJS website as a comparison with other JS micro-engines (https://bellard.org/quickjs/bench.html).
I wanted to benchmark Duktape too, but it would not compile on my Debian 11 system, since the build system requires Python2 YAML (which is not available anymore at the repositories).
Rhino 1.7.14-SNAPSHOT 2021 09 14
//commented out a line with console.log (Rhino does not support it)
RESULT Richards 53.6
RESULT DeltaBlue 55.3
RESULT Crypto 52.0
RESULT RayTrace 134
RESULT EarleyBoyer 167
RESULT RegExp 147
RESULT Splay 302
RESULT NavierStokes 65.7
RESULT Richards 363
RESULT DeltaBlue 350
RESULT Crypto 419
RESULT RayTrace 483
RESULT EarleyBoyer 676
RESULT RegExp 125
RESULT Splay 893
RESULT NavierStokes 751
Some more facts from Michael: https://lists.freedesktop.org/archives/libreoffice/2022-January/088381.html
another problem is that Rhino cannot simply be replaced by packging yet
another JS implementation; if you look at the examples we ship, they have:
so any existing Rhino based macros will likely use the Java APIs and
cannot work with a non-JVM based JS implementation.
also, Rhino relies on the Java-UNO bridge and some Java glue code in the
scripting module to provide access to UNO APIs; this would need to be
reimplemented in the form of a bridge for any non-JVM based JS