2015-09-21 1 views
2

Я хочу предоставить собственную реализацию JSObject, как описано здесь: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions JSObject находится в пакете jdk.nashorn.api. К сожалению, классы объектов, которые вы получаете в api-методах, не являются. Вы получаете NativeArray и JO4, которые являются частью внутреннего пакета. Мой вопрос: как мне обращаться с такими объектами? Рекомендуется ли использовать внутренние функции? Или можно ли отнести эти объекты на что-либо в api-пакете?Как избежать внутренних классов Nashorn в реализациях JSObject

Вот мой простой пример:

import javax.script.Invocable; 
import javax.script.ScriptEngine; 
import javax.script.ScriptEngineManager; 
import javax.script.ScriptException; 
import jdk.nashorn.api.scripting.AbstractJSObject; 

public class JacksonToJSObject extends AbstractJSObject { 

    final static ScriptEngine engine = new ScriptEngineManager().getEngineByName("nashorn"); 

    public static void main(String[] args) throws ScriptException, NoSuchMethodException { 
     String script = "var fun = function(obj) {obj.arrayField = [1,2]; obj.objField = {\"field\":\"test\"}};"; 
     engine.eval(script); 
     ((Invocable)engine).invokeFunction("fun", new JacksonToJSObject()); 
    } 

    @Override 
    public void setMember(String name, Object value) { 
     System.out.println(value.getClass().getCanonicalName()); 
    } 

} 

Это выход

jdk.nashorn.internal.objects.NativeArray 
jdk.nashorn.internal.scripts.JO4 
+0

1. Обычно внутренние двигатели возвращают объект, полученный из класса в контракте, и это нормально, его можно отнести к «базовому» классу. Отказ от ответственности: я не знаю, что это случай Yoyr, т. Е. J04 получается из JSObject –

+0

2. Я не знаю, как эффективно «подключить» ваш класс к двигателю (возможно, вы задали вопрос 2in1). В Groovy аналогичная работа имеет динамический характер. –

+0

К сожалению, внутренняя классы не подклассы JSObject, а также никакой другой класс в api. – Gregor

ответ

2

Я подал ошибку против JDK https://bugs.openjdk.java.net/browse/JDK-8137258, чтобы автоматически обрабатывать упаковку. В то же время, пожалуйста, используйте обходное решение, предложенное Аттилой Сегеди.

+0

Спасибо, я буду использовать обертку. – Gregor

2

Я думаю, что мы должны обернуть это автоматически для вас. Тем временем вы можете передать эти внутренние объекты в jdk.nashorn.api.scripting.ScriptUtils.wrap(Object) самостоятельно, чтобы вернуть JSObject. Этот метод является idempotent, если вы передадите ему что-то, что уже завершено, поэтому это решение не сломается, если мы исправим упаковку.

+0

Решение работает отлично, но опять-таки требует, чтобы я использовал внутренний класс: потому что метод setMember имеет значение Object, но для «wrap» требуется ScriptObject, значение должно быть явно выбрано, чтобы не получить ошибку компилятора. Таким образом, я получаю импорт jdk.nashorn.internal.runtime.ScriptObject. Во всяком случае, если обертка выполняется внутренне, как было предложено в отчете об ошибке, все будет хорошо. – Gregor

 Смежные вопросы

  • Нет связанных вопросов^_^