generalized javascript runtime support (including Nashorn)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

generalized javascript runtime support (including Nashorn)

Rob Platt
I've started this as a new topic, instead of continuing "javascript (nashorn) build script engine for gradle", given that the scope has changed significantly from the original post.

I have set up an experimental plugin for the generalized javascript support at https://github.com/momentumjs/gradle-jsengine-plugin. We can relocate/rename stuff as desired once its a bit more stable, but please feel free to comment, review, raise issues or PR if you're interested.

So far there's not much. I've put together a proof of concept for javascript engine discovery. This is the equivalent of the native toolchain functionality for javascript.

The default behavior is that available engines are ordered by ECMAScript standards version, then by engine version. So a script which specifies that it needs Rhino will use the latest Rhino. A script which can use any engine would choose Nashorn over Rhino on the basis that it is ECMAScript 5.1 instead of 5 (if Nashorn is available). This seems the most natural ordering, given that engines don't have an objective 'awesomeness' score. But of course it could this could be modified by plugins. Engines might also be filtered according to if a task needs specific features e.g. the ability to compile to bytecode on disk, but I haven't gotten to this yet.

Next I'm going to look at the concept of javascript applications. These will have engine requirements, equivalent to the "engines" section of a package.json file. Indeed, I have it in mind that we should be able to determine the appropriate engine to use from package.json files in future.

I'll report back when there is a basic "run" task. Then the plugin will actually do something ;-)

Regards
Rob

Reply | Threaded
Open this post in threaded view
|

Re: generalized javascript runtime support (including Nashorn)

Adam Murdoch

On 4 Mar 2014, at 5:59 am, Rob Platt <[hidden email]> wrote:

I've started this as a new topic, instead of continuing "javascript (nashorn) build script engine for gradle", given that the scope has changed significantly from the original post.

I have set up an experimental plugin for the generalized javascript support at https://github.com/momentumjs/gradle-jsengine-plugin. We can relocate/rename stuff as desired once its a bit more stable, but please feel free to comment, review, raise issues or PR if you're interested.

Looks good to me.

The only feedback I’d give at this stage is that possibly DefaultJsEngineRegistry should search for a compatible engine in the order that they are added to the registry, and instead do the ordering in EmbeddedJsEnginePlugin for the embedded engines only. This way, the user can tweak the search order in the registry.


So far there's not much. I've put together a proof of concept for javascript engine discovery. This is the equivalent of the native toolchain functionality for javascript.

The default behavior is that available engines are ordered by ECMAScript standards version, then by engine version. So a script which specifies that it needs Rhino will use the latest Rhino. A script which can use any engine would choose Nashorn over Rhino on the basis that it is ECMAScript 5.1 instead of 5 (if Nashorn is available). This seems the most natural ordering, given that engines don't have an objective 'awesomeness' score. But of course it could this could be modified by plugins. Engines might also be filtered according to if a task needs specific features e.g. the ability to compile to bytecode on disk, but I haven't gotten to this yet.

Next I'm going to look at the concept of javascript applications. These will have engine requirements, equivalent to the "engines" section of a package.json file. Indeed, I have it in mind that we should be able to determine the appropriate engine to use from package.json files in future.

Sounds good. This is exactly the idea.


I'll report back when there is a basic "run" task. Then the plugin will actually do something ;-)

Great.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: generalized javascript runtime support (including Nashorn)

Rob Platt

Adam Murdoch wrote:
> possibly DefaultJsEngineRegistry should search for a compatible engine in the order that they are added to the registry, and instead do the ordering in EmbeddedJsEnginePlugin for the embedded engines only. This way, the user can tweak the search order in the registry.

No problem. Would this then be determined by the order in which the plugins are listed, or does the user adjust it some other way? It'd be good to have test coverage for this.

Cheers
Rob
Reply | Threaded
Open this post in threaded view
|

Re: generalized javascript runtime support (including Nashorn)

Adam Murdoch

On 6 Mar 2014, at 11:23 pm, Rob Platt <[hidden email]> wrote:


Adam Murdoch wrote:
> possibly DefaultJsEngineRegistry should search for a compatible engine in the order that they are added to the registry, and instead do the ordering in EmbeddedJsEnginePlugin for the embedded engines only. This way, the user can tweak the search order in the registry.

No problem. Would this then be determined by the order in which the plugins are listed, or does the user adjust it some other way?

The idea is that the plugin order determines some default engines in some default order if the user does not specify any engines. If the user specifies some engines, then no defaults are applied and we use only those engines specified by the user and in the order specified.

Thinking about it, we could possibly order the engines if we’re using the defaults, but not if the user has specified any engines.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com