Configuration Files and some Module Scripts are currently written in Groovy, however this seems to have some downsides that are getting more and more cumbersome as Toast begins to snowball into a bigger and bigger project.
Upsides
Lets start on a positive. The upsides of allowing this Groovy implementation through the Groovy SDK are quite nice.
Easy to code for
Direct access to the JVM
Lots of 'helpers' (.withReader and things of the like)
Next to no performance deficit
Downsides
Large SDK size (The Groovy SDK is close to 6MB, taking up the large majority of Toast's build size)
The Java version running on the RoboRIO's deployed in January (8u6) doesn't have support for the Groovy SDK, meaning each team must update their RoboRIO's java to run Toast.
JavaScript
Project Nashorn was introduced in Ju8, allowing for faster, more reliable interpretation of JavaScript running directly in the JVM. JavaScript here will have direct access to the JVM and is executed fairly quickly. This almost mirrors Groovy's speed, and is natively included in the JDK without the need for an external API like Groovy does. JavaScript's objects and prototypes can enable for extremely powerful Configuration Files and ModuleScripts.
The Changeover
The changeover will not be easy. While the implementation itself shouldn't prove to be difficult (fairly similar to the current Groovy syntax with minor changes), there are other challenges. Each config will have to be sandboxed with it's own ScriptEngine to avoid conflicts with Config names. Existing modules will have to be switched to JavaScript configuration files as opposed to the Groovy ones, which is not necessarily difficult, but a pain at best. Additionally, Groovy Modules will no longer be supported. While JavaScript DOES have direct access to the JVM, the implementation isn't as clean as many would like. For example, all Type declarations are done with Java.Type, instead of a direct reference. This shouldn't be a problem, but I can see many people finding it cumbersome. These modules will also have to be sandboxed to avoid variable conflicts, as I suspect many developers won't have their Modules contained in an object.
Mitigation
Legacy Support for Groovy may have to be implemented. This can be done through a Legacy module, or perhaps through checking if the Groovy SDK is loaded into the classpath. Either way, it won't be easy to do cleanly.
Configuration Files and some Module Scripts are currently written in Groovy, however this seems to have some downsides that are getting more and more cumbersome as Toast begins to snowball into a bigger and bigger project.
Upsides
Lets start on a positive. The upsides of allowing this Groovy implementation through the Groovy SDK are quite nice.
Downsides
JavaScript
Project Nashorn was introduced in Ju8, allowing for faster, more reliable interpretation of JavaScript running directly in the JVM. JavaScript here will have direct access to the JVM and is executed fairly quickly. This almost mirrors Groovy's speed, and is natively included in the JDK without the need for an external API like Groovy does. JavaScript's objects and prototypes can enable for extremely powerful Configuration Files and ModuleScripts.
The Changeover
The changeover will not be easy. While the implementation itself shouldn't prove to be difficult (fairly similar to the current Groovy syntax with minor changes), there are other challenges. Each config will have to be sandboxed with it's own ScriptEngine to avoid conflicts with Config names. Existing modules will have to be switched to JavaScript configuration files as opposed to the Groovy ones, which is not necessarily difficult, but a pain at best. Additionally, Groovy Modules will no longer be supported. While JavaScript DOES have direct access to the JVM, the implementation isn't as clean as many would like. For example, all Type declarations are done with Java.Type, instead of a direct reference. This shouldn't be a problem, but I can see many people finding it cumbersome. These modules will also have to be sandboxed to avoid variable conflicts, as I suspect many developers won't have their Modules contained in an object.
Mitigation
Legacy Support for Groovy may have to be implemented. This can be done through a Legacy module, or perhaps through checking if the Groovy SDK is loaded into the classpath. Either way, it won't be easy to do cleanly.