Замкнутая java замена скриптов для Nashorn - PullRequest
0 голосов
/ 23 марта 2020

Я использую Nashorn для awk-подобной массовой обработки данных. Идея состоит в том, что есть много входящих данных, приходящих строка за строкой, одна за другой. И каждая строка состоит из именованных полей. Эти данные обрабатываются пользовательскими сценариями, хранящимися где-то снаружи и редактируемыми пользователями. Сценарии просты, например if( c>10) a=b+3, где a, b и c - поля во входных строках данных. Количество данных действительно огромно. Код такой (пример для демонстрации варианта использования):

    ScriptEngine engine = new NashornScriptEngineFactory().getScriptEngine(
            new String[]{"-strict", "--no-java", "--no-syntax-extensions", "--optimistic-types=true"},
            null,
            scr -> false);

    CompiledScript cs;
    Invocable inv=(Invocable) engine;
    Bindings bd=engine.getBindings(ScriptContext.ENGINE_SCOPE);

    bd.remove("load");
    bd.remove("loadWithNewGlobal");
    bd.remove("exit");
    bd.remove("eval");
    bd.remove("quit");

    String scriptText=readScriptText();

    cs = ((Compilable) engine).compile("function foo() {\n"+scriptText+"\n}");
    cs.eval();


    Map params=readIncomingData();

    while(params!=null)
    {
        Map<String, Object> res = (Map) inv.invokeFunction("foo", params);
        writeProcessedData(res);
        params=readIncomingData();
    }

Теперь нашорн устарел, и я ищу альтернативы. Гуглил несколько дней, но не нашел точного соответствия моим потребностям. Требования:

  • Скорость. Там много данных, поэтому все будет очень быстро. Поэтому я также предполагаю, что прекомпиляция обязательна
  • Должна работать под linux / openJDK
  • Поддержка песочницы как минимум для доступа к данным / выполнения кода

Приятно иметь :

  • Простой, c -подобный синтаксис (не lua;)
  • Поддержка песочницы для использования процессора

До сих пор я обнаружил, что Rhino еще жив (последний выпуск от 13 января 2020 года), но я не уверен, что он все еще поддерживается и насколько он быстр - насколько я помню, одной из причин, по которой Java перешел на Nashorn, была скорость. И скорость очень важна в моем случае. Также найден J2V8, но linux не поддерживается. GraalVM выглядит немного излишним, также еще не понимал, как использовать его для такой задачи - может быть, нужно еще изучить, подходит ли он для этого, но похоже, что это полная замена jvm и его нельзя использовать в качестве библиотеки.

Не обязательно будет javascript, может быть есть другие альтернативы. Спасибо.

1 Ответ

1 голос
/ 24 марта 2020

GraalVM JavaScript может использоваться как библиотека с зависимостями, полученными как любой артефакт Maven. Хотя рекомендуемый способ его запуска - использовать дистрибутив GraalVM, есть некоторые объяснения , как запустить его на OpenJDK .

Вы можете ограничить доступ к сценарию, например, Java классы, создание потоков и т. Д. c:

Из документации :

The following access parameters may be configured:

* Allow access to other languages using allowPolyglotAccess.
* Allow and customize access to host objects using allowHostAccess.
* Allow and customize host lookup to host types using allowHostLookup.
* Allow host class loading using allowHostClassLoading.
* Allow the creation of threads using allowCreateThread.
* Allow access to native APIs using allowNativeAccess.
* Allow access to IO using allowIO and proxy file accesses using fileSystem.

И это в несколько раз быстрее, чем Нашорн. Некоторые измерения можно найти, например, в этой статье :

GraalVM CE provides performance comparable or superior to Nashorn with 
the composite score being 4 times higher. GraalVM EE is even faster. 
...