Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ES6 Support for Automation #9266

Closed
jpg0 opened this issue Nov 2, 2019 · 7 comments
Closed

ES6 Support for Automation #9266

jpg0 opened this issue Nov 2, 2019 · 7 comments

Comments

@jpg0
Copy link
Contributor

jpg0 commented Nov 2, 2019

I have written a bundle which adds the GraalJS scripting engine to OH automation. This allows writing scripts in ES6 (well, even later versions), and should be more compatible with the future (given that Nashorn is deprecated).

Currently the bundle is self-contained and requires no changes in other bundles (although JS using Nashorn-specific extensions will break).

I'd like to contribute this, although I'm unsure of the desired structure for the automation stuff. Should I submit a PR to the openhab2-addons repo? Or should it be core, like the existing automation pieces are? Or a new repo entirely?

@jpg0
Copy link
Contributor Author

jpg0 commented Nov 2, 2019

Related discussion in forums: https://community.openhab.org/t/graalvm-for-automation/84116

@wborn wborn transferred this issue from openhab/openhab-core Dec 6, 2020
@wborn
Copy link
Member

wborn commented Dec 6, 2020

I've transferred this issue to the addons repo since that's where PRs for automation add-ons should be created. That's also the repo where your #8516 PR is.

@FSeidinger
Copy link
Contributor

Hey @wborn, @jpg0,

currently the Nashorn script engine factory (NashornScriptEngineFactory) is part of the core platform and part to the openHAB Core :: Bundles :: Automation Script Modules core bundle. If the plans are moving from Nashorn to GraalVM, I guess a suitable GraalVM script engine factory has to go into the core platform as well. Any thoughts on this?

If the GraalVM on the other side is only thought of as an alternative to the default Nashorn implementation, having it as an addon is the right way to go. I guess that the platform maintainers must decide on this topic to reach a final and usable conclusion.

Even if Nashon stays in OH3 as the default implementation, you could think about a separation of the Nashorn script engine from the openHAB Core :: Bundles :: Automation Script Modules. Let's say you create a new core bundle carrying the Nashorn implementation, then you can deactivate the bundle and let the user decide about the default implementation.

The GraalVM implementation can then be put into another bundle, either as a core bundle or as an addon. This would give the user more control over what will be the default javascript engine. The setup procedure or the settings in OH3 can then take care of the default implementation with a suitable default for fresh installations. Your thoughts on this?

@jpg0
Copy link
Contributor Author

jpg0 commented Jan 3, 2021

Something to note is that Nashorn is deprecated, so my assumption is that GraalJS should replace it. That does raise the question of where these engines go though; they are currently spread across core and addons.

Another thing of note: having two engines both supporting .js can cause issues - the one that gets used is the last one that gets loaded, but (currently, OH3.0.0) what actually happens is that scripts begin getting processed by the first one, then as the next one loads the remaining scripts are processed by this next one! Certainly fixable, but does point to challenges with supporting two engines handling the same script types.

@GUlbricht
Copy link

Hey everybody,
any progress on this topic yet. It would be nice if the es6 support comes in near future.
Thanks.

@jpg0
Copy link
Contributor Author

jpg0 commented Feb 21, 2021

I (author of this PR) am not a maintainer, so I cannot really make progress myself. I'm hoping that it's picked up for review by someone who is, at which point it should move forward.

@wborn
Copy link
Member

wborn commented Oct 10, 2021

Fixed by #8516.

@wborn wborn closed this as completed Oct 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants