AuTA's criteria and grading system is extremely flexible: all results are checked by JavaScript functions that can export notes (in the form of tips, warnings, and failures) and can return a grade. This requires a JavaScript runtime; in AuTA 1.0 all scripts were sent to MongoDB for evaluation. While this made it possible to query the database during checking (for very simple benchmarking, for example), it also had an immense performance impact so bad that generating a report became Denial of Service.
J2V8
Enter J2V8. This library provides Java bindings for the very powerful V8 engine by Google. We chose this runtime over the following alternatives:
Use an entirely different language
One option considered was to use an entirely different language than JavaScript for these scripts. Alternatives could have been Lua, Python, or even eval'ed Java. This solution had two major drawbacks, however: first, all existing scripts had to be rewritten, which was a lot of work. Secondly, now the passing criteria scripts (which run inside the core) and the results formatting scripts (which may run in the browser) required different languages, which is very confusing for end users.
Rhino
The Rhino JavaScript engine by Mozilla runs natively in a Java application, which makes it a prime candidate, however the engine runs extremely slow compared to V8.
Nashorn
Nashorn is Oracle's answer to Mozilla's Rhino, but they deprecated it in Java 11. Shame.
SpiderMonkey
SpiderMonkey is Mozilla's JavaScript engine written in C++ with a rich history (going all the way back to the first version of JavaScript ever) which sounds very promising, but without pre-existing Java bindings J2V8 is the clear winner here.
Further alternatives
Quite surprisingly, even more alternatives exist. These include Jav8 and Zazl's V8 Java Bridge, but these libraries are 7+ years out of date.
Licensing issues
There is one catch to using J2V8: it is licensed under the Eclipse Public License v1.0 which is incompatible with AuTA's AGPLv3. However, under our interpretation of the EPLv1, the end user (as defined by the EPLv1 and not the AGPLv3, that is, the provider of the AuTA service and not the consumers of the service) can choose to install such software anyway as the restrictions posed by the EPLv1 as it is the end user's choice and not enforced by AuTA itself. Therefore, a plugin-style system to dynamically detect and load software that is not available under an AGPLv3-compatible license is legal as long as the bridging interface between the two products is compatible with both.
This is preferable over including an exception in AuTA's license because first, we are already bound to the exact AGPLv3, and secondly, introducing such an exception creates a new license that is, in and of itself, incompatible with the AGPLv3 because of the aforementioned reasons.
With this very exciting analysis out of the way, we created an interfacing library, the AuTA Script Runtime Facade (or AuTA-SRF for short) that is a lightweight, permissively-licensed common interface to be implemented by JavaScript runtime providers. Both AGPLv3-licensed and EPLv1-licensed code can legally link with this bridge. Then, AuTA can be given paths to libraries that implement this interface and load them at runtime, circumventing the need for an exception in AuTA's license.
Future concerns
The developer behind J2V8 has stated that he will focus on developing an Android, non-NodeJS platform. The available distributions from version 5 are already within this scope only. Fortunately, it is still possible to build the library on AuTA's target platform, namely non-Android non-NodeJS AMD64 Linux. We will continue to provide built libraries, but it may be up to us to keep builds working on that target platform. The author has stated that he will continue to accept pull requests in those situations.
In case an entirely new scripting runtime is desired, then the Script Runtime Facade can be used to easily replace the actual runtime used by the core.
A fallback on MongoDB
To make sure that the core functions at a baseline level without an external runtime provider, the core may decide to fall back on MongoDB's runtime features. The Security Agent will be set up to detect and warn about such situations, since aforementioned DoS possibilities.