Bug 97827 - Change the rhino engine for javascript macros for non Java alternative (spidermonkey/V8)
Summary: Change the rhino engine for javascript macros for non Java alternative (spide...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-13 05:26 UTC by Bastián Díaz
Modified: 2018-04-24 07:28 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bastián Díaz 2016-02-13 05:26:38 UTC
From my point of view, the best programing languages to make macros in LibreOffice are Python and Javascript. Learning either of the two lets you reuse your knowledge.

Moreover, JavaScript is the most popular programming language for a long time (first or second place). It is accessible and easy to learn for the end user. Also JavaScript is omnipresent and multipurpose in different areas (valued element for a user).

I think there are many advantages to improve support for JavaScript in LibreOffice, however:

- LibreOffice uses the Rhino engine to support JavaScript. Rhino is written in Java, it is heavy and slow for complex macros.
- 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.

Cheers
Comment 2 Buovjaga 2016-03-07 08:37:11 UTC
It seems choosing Spidermonkey would be shooting ourselves in the foot:
https://lists.freedesktop.org/archives/polkit-devel/2015-August/date.html
https://lists.freedesktop.org/archives/polkit-devel/2015-September/date.html

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.
Comment 3 Johan PIQUET 2016-03-09 08:46:46 UTC
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)
Comment 4 Buovjaga 2016-03-09 08:49:51 UTC
(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.
Comment 5 Johan PIQUET 2016-03-09 09:41:04 UTC
Sorry, I mean "duketape" not "dukescript".
Comment 6 Buovjaga 2016-03-09 10:06:19 UTC
(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.
Comment 7 Michael Stahl (CIB) 2016-03-09 10:30:40 UTC
> - LibreOffice uses the Rhino engine to support JavaScript. Rhino is written in Java, it is heavy and slow for complex macros.

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).

furthermore, ~nobody is using JavaScript (or BeanShell for that matter)
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:

http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/38646

	+ should we drop Rhino, Beanshell & javascript in 4.0 ? (Michael)
		+ 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.
Comment 8 Bastián Díaz 2016-03-09 16:40:11 UTC
(In reply to Michael Stahl from comment #7)

Sure you may be right, but to use Java to run a Javascript engine is not the most efficient way anyway. Maybe V8 or Spidermonkey are not the ideal solution, but the spirit is to remove Java dependencies in LibreOffice and improve performance.

In my case not to use Java in LibreOffice, some friends either. Therefore could not use JavaScript for my macros (and other features that require Java). It really is a nuisance for users no-developers have to learn a new language and more complex to create macros. 

So... why javascript are not as used to create macros in LibreOffice? Well JavaScript is everywhere and is easy to use, but the JavaScript support in LibreOffice is bad.

Regards
Comment 9 jan d 2017-02-22 10:25:23 UTC
(In reply to Michael Stahl from comment #7)
> 
> …
> 
> furthermore, ~nobody is using JavaScript (or BeanShell for that matter)
> 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).