| JavaScript Engine Types Determination [message #1736319] |
Tue, 28 June 2016 11:43  |
Eclipse User |
|
|
|
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?
Regards,
Nedelcho
[1] http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html
[2] https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide
[3] https://github.com/eclipsesource/J2V8
[4] http://api.dirigible.io
|
|
|
| Re: JavaScript Engine Types Determination [message #1736323 is a reply to message #1736319] |
Tue, 28 June 2016 12:28  |
 Yordan Pavlov
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.
Regards,
Yordan
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!
|
|
|
Powered by
FUDForum. Page generated in 0.03533 seconds
] 
Search
Help
Register
Login
Home
