10

In my Java application a small put important feature is to be able to rename audio files based on their metadata (e.g album/artist -title) and the mask is specified using Javascript, this makes for a very flexible and powerful renaming feature.

I knew Javascript was being deprecated but it now seems it is actually going to be removed from Java 15 onwards. This loss of functionality could be a major problem for me so I ask even if it is officially removed is there a way I can continue to use Javascript within a Java 15 application, i.e will it be available as an opensrc plugin that I can use at my own risk. The fact that development has stopped at Ecmascript 5.1 is not a major issue for me.

There was mention of using GraalVM but without explanation how to do this and I don't see that fits in with my scenario, specifically my application is available on some 32bit Arm environments and GraalVM is not available for 32bit.

I have already moved from Java 11 to Java 14 to resolve some other issues, so I cannot really go back to Java 11, and since Java 14 is not a LTS release I cannot really stick with Java 14 over long period of time.

This is the bulk of my Javascript code

try
{
    mask = includeUserDefinedFunctions(mask);
    ScriptEngine engine = manager.getEngineByName("JavaScript");
    for(SongFieldName next:SongFieldName.values())
    {
        if(next.getScriptVar()!=null && next.getSongFieldKey()!=null)
        {  
            engine.put(next.getScriptVar(), cleanValue(song.getFieldValueSpaceSeparatedOrEmptyString(next.getSongFieldKey()), song));
        }
    }
    String result = (String)engine.eval(mask);
    return result;
}
catch(ScriptException se)
{
    throw se;
}
ZhekaKozlov
  • 36,558
  • 20
  • 126
  • 155
Paul Taylor
  • 13,411
  • 42
  • 184
  • 351

2 Answers2

7

You can run GraalVM's JavaScript Engine on any JVM as a bunch of dependencies pulled from Maven central. Here's an example: https://github.com/graalvm/graaljs/blob/master/docs/user/RunOnJDK.md

It will be slower without the GraalVM compiler, because the language implementation framework for GraalVM needs certain api from the compiler which afaik is not in other JITs.

If you will look into migrating your application to use GraalVM's JavaScript, if you use certain Nashorn features it might not work out of the code, consider starting with the --nashorn-compatibility-mode (here are more details about it: https://github.com/graalvm/graaljs/blob/master/docs/user/NashornMigrationGuide.md).

Oleg Šelajev
  • 3,530
  • 1
  • 17
  • 25
  • ok, thankyou the performance warnings are worrying, but maybe in my case it doesnt really matter as tiny part of application. I see you are a Graal developer, perhaps I can ask some other questions: 1>Will Graal Javascript support ECMA 6 ? 2> Why it easier to maintain Javascript for Graal rather than Nashorn > 3> Will Nashorn continue to be available in some unsupported way with Java 15 ?, 4> Will GraalVM ever be available for 32bit architectures such as armv7 ? – Paul Taylor Jun 09 '20 at 08:47
  • 5
    developer advocate, but on the team so I'll try to answer the questions. 1. it supports ES6 (actually 20.1 enables ES 2020 features by default): https://kangax.github.io/compat-table/es6/ 2. GraalVM language support requires creating an interpreter which will be JIT compiled very efficiently. This is much easier than creating an optimizing compiler manually. And effort to maintain was one the main reasons for Nashorn deprecation announced in the JEP I think. 3. don't know, better question for OpenJDK mailing list. 4. Honestly don't know, better ask in a GitHub issue github.com/oracle/graal – Oleg Šelajev Jun 09 '20 at 09:04
  • 2
    I also added a line and a link about the nashorn compatibility mode which I think might ease migration and it wasn't in the original question, but a very useful bit of info. – Oleg Šelajev Jun 09 '20 at 09:08
6

You can use a standalone version of Nashorn: https://github.com/openjdk/nashorn.

Nashorn is a JPMS module, so make sure it and its transitive dependencies (Nashorn depends on several ASM JARs) are on your application's module path, or appropriately added to a module layer, or otherwise configured as modules.

While standalone Nashorn is primarily meant to be used with Java 15 and later versions, it can also be used with Java versions 11 to 14 that have a built-in version of Nashorn too. See this page for details on use when both versions are present.

ZhekaKozlov
  • 36,558
  • 20
  • 126
  • 155
  • Great, I have just tried and it worked with minimal change, just needed to add depednendency to my maven pom.xml and instantiate the right ScriptEngine Also still working with Java 11 as well as when run with Java 15 – Paul Taylor Mar 24 '22 at 16:37