Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Dirigible » JavaScript Engine Types Determination(Discussion about JavaScript engine types and their support)
JavaScript Engine Types Determination [message #1736319] Tue, 28 June 2016 11:43 Go to next message
Nedelcho Delchev is currently offline Nedelcho DelchevFriend
Messages: 57
Registered: May 2013
Hi All,

As you know we are integrating Nashorn JavaScript engine as an alternative to Rhino for JavaScript in Eclipse Dirigible.
Unfortunately, they are not fully compatible hence we need a special attention here [1][2].
Another point is the plan to integrate also v8 via the J2V8 bridge [3] and also node.js via remote server paradigm.
Hence, there are a few statements came out from a discussion with Georgi to start shaping this idea:

    There will be a default setting per instance which engine to be used rhino, nashorn, v8
    There will be "per-endpoint" configuration (like security (authorisation) feature), which will set the required engine per service
    There will be NO possibility to execute in one call (request) different required modules with different engines
    There will be a setting per-project (design time) showing compatibility with the engines
    There will be compatibility checks for dependencies can be done only at design time
    Enterprise JavaScript API have to state (at [4]?) which engine (version?) each module is compatible with
    There could also be introduced an alternative file extensions (*.rhino, *.nashorn, *.v8), which can have hard linking to the underlying engine

Do you see some more constraints or capabilities to be added to the list?


Re: JavaScript Engine Types Determination [message #1736323 is a reply to message #1736319] Tue, 28 June 2016 12:28 Go to previous message
Yordan Pavlov is currently offline Yordan PavlovFriend
Messages: 10
Registered: October 2014
Junior Member
Hi Nedelcho,

Do we really want to have a such degree of flexibility, because with it we will pay a higher costs for maintenance, complexity and UX (developer experience)?

At first sight, having the "per-endpoint" configuration sound good to me, but latter I found some drawbacks. What will happen if this "endpoint" require the module "X", that uses an API, that is not compatible with the configured engine (Rhino for example)? What if the same module ("X") is used by another "endpoint", that is configured with different engine (V8 for example)?

I'm not sure if having a separated file extensions will be a good approach. Yes, it will be more clear which engine will be used to execute the file, but at the end my expectations are that, the content of the file is a JavaScript and it is an engine independent.

How we will solve the challenges of transporting project(s) between instances? Do we plan exporting of the "engines configuration"? What will happen if I want to transport project(s) from one instance to another instance (with different "default instance engine" configurations)?

As a bottom line, I will said, that having a settings per project and settings for the default engine of the instance, should be good enough and simple to use.


PS: Having multiple type of engines is really a "killer feature" and we can use it as a "selling point", along with all other good things that Dirigible has!
Previous Topic:Dirigible Testing Lab
Next Topic:Injected API Requests
Goto Forum:

Current Time: Sun May 22 18:08:34 GMT 2022

Powered by FUDForum. Page generated in 0.01982 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top