Comments 28
Ну а по сути то, в чем разница по сравнению с Rhino. К тому же есть DynJs.
Или это просто ребрендинг Rhino от Oracle?
Или это просто ребрендинг Rhino от Oracle?
Цель одна и та же — интерпретация JavaScript посредством JVM. Замеров производительности Rhino и Nashorn в сравнении не видел, но обещают повышение производительности в 20 раз. От DynJs как минимум выгодно отличается тем идёт out-of-the-box с JRE, но, как правильно замечает автор DynJS, его реализация — ПО с открытым исходным кодом в отличие от Nashorn.
Значит ли это, что в OpenJDK Nashorn не будет?
Судя по датам статей, на которые я дал ссылки в комментарии — будет. Интервью с разработчиком DynJS датируется октябрём 2011, а статья о Nashorn — ноябрём 2012. Извиняюсь что ввёл в заблуждение.
https://wiki.openjdk.java.net/display/Nashorn/Main
https://wiki.openjdk.java.net/display/Nashorn/Main
Не будет. Потому что уж есть: openjdk.java.net/projects/nashorn/
Читал, что оно будет использовать новые возможности JVM. Rhino в сущности интерпретатор, а эта штука сможет использовать JIT компиляцию JVM для динамического кода. V8 навряд ли догонит, но цифры хотя бы одного порядка должны быть.
>Зачем нужен JavaScript в Java? Например:
>Описывать бизнес-логику на более простом чем Java языке (привлекая к этому специалистов в предметной области с базовым навыком программирования)
Судя по листингам не проще. Реально зачем нужно? Кто пролоббировал?
>Описывать бизнес-логику на более простом чем Java языке (привлекая к этому специалистов в предметной области с базовым навыком программирования)
Судя по листингам не проще. Реально зачем нужно? Кто пролоббировал?
В листингах приведен Java-код для интеграции JS-движка.
Или вот это код сложный?
Или вот это код сложный?
var MyClass = Java.type("EvalScript.MyClass");
var my = new MyClass();
my.printMsg("Hello!");
Вот почему я так считаю. Это НЕ js, который можно проверить и отладить в браузере: здесь полно зависимостей на java-классы приложения. Это дает три проблемы:
1) js код нужно писать зная полные имена java-классов, а их может быть много.
2) при изменении сигнатуры классов или их переименовании, мы узнаем о проблеме только по тестам (если они есть),
3) этот js код не поддерживает ни одна IDE
3ий пункт можно разделить две части: когда код пишется разработчиком и когда он потом редактируется пользователем приложения по образу ручного редактирования SQL-запросов. Т.е. для пользователя нужен будет встроенный редактор такого js. Он заявлен? Почему тогда не дать пользователям писать на Java и генерить байт код «на лету»? Я понимаю, что для Java это сложнее, чем .net-аналог Reflection.Emit, но это возможно и намного проще, чем компилятор JS «c нуля».
1) js код нужно писать зная полные имена java-классов, а их может быть много.
2) при изменении сигнатуры классов или их переименовании, мы узнаем о проблеме только по тестам (если они есть),
3) этот js код не поддерживает ни одна IDE
3ий пункт можно разделить две части: когда код пишется разработчиком и когда он потом редактируется пользователем приложения по образу ручного редактирования SQL-запросов. Т.е. для пользователя нужен будет встроенный редактор такого js. Он заявлен? Почему тогда не дать пользователям писать на Java и генерить байт код «на лету»? Я понимаю, что для Java это сложнее, чем .net-аналог Reflection.Emit, но это возможно и намного проще, чем компилятор JS «c нуля».
Ок. Отвечу по пунктам:
1) Знать имена java-классов и методов совершенно не нужно! Просто доступную для скриптования функциональность можно предоставить в виде глобальных js-функций и обхектов. И, разумеется, хорошая документация. Использовать
Вообще я не прослеживаю в этом вопросе логики: при написании js-кода нужно знать имена java-классов, а при написании java-кода уже нет. Код что, сам пишется?
2) Смотрите пункт 1. Документация, причем сделанная специально с расчетом на предметников. Если Вы намекаете на динамическую типизацию (мол не можем валидировать скрипт), то как в подобных случаях динамические языки себя показывают лучше (не отвлекают предметника на ненужные/непонятные ему вещи).
3) Этот js код поддерживает любая IDE. Например, его можно редактировать в Eclpise. А если неможно постараться, можно в Eclipse вообще встроить интеграцию со своей системой.
PS: кстати, а какой встроенный редактор для Java заявлен?
1) Знать имена java-классов и методов совершенно не нужно! Просто доступную для скриптования функциональность можно предоставить в виде глобальных js-функций и обхектов. И, разумеется, хорошая документация. Использовать
Java.type по-хорошему надо только для interop — этим определенно должны заниматься не предметники, но программисты.Вообще я не прослеживаю в этом вопросе логики: при написании js-кода нужно знать имена java-классов, а при написании java-кода уже нет. Код что, сам пишется?
2) Смотрите пункт 1. Документация, причем сделанная специально с расчетом на предметников. Если Вы намекаете на динамическую типизацию (мол не можем валидировать скрипт), то как в подобных случаях динамические языки себя показывают лучше (не отвлекают предметника на ненужные/непонятные ему вещи).
3) Этот js код поддерживает любая IDE. Например, его можно редактировать в Eclpise. А если неможно постараться, можно в Eclipse вообще встроить интеграцию со своей системой.
PS: кстати, а какой встроенный редактор для Java заявлен?
BTW, вместо Reflection.Emit для Java есть хорошая BCEL.
Лично меня пугает словосчетание «базовым навыком программирования» в фразе «привлекая к этому специалистов в предметной области с базовым навыком программирования».
Как бы это не вылезло в «переписали код заново из-за Васи с базовым навыком программирования».
Как бы это не вылезло в «переписали код заново из-за Васи с базовым навыком программирования».
По мне, так это изобретение велосипеда. На JVM есть много динамических ЯП, например clojure, groovy, scala, которыми можно воспользоваться для добавления скриптовой части. Не знаю точно про скалу, но первыми двумя можно. К тому же языки активно развиваются, имеют большое сообщество, и мне кажется куда более надёжные, чем новый движок.
Лично пробовал проделать подобное с использованием Groovy. Работает. Groovy более приятен для пользователя и менее строг по сравнению с Java.
Scala отметается сразу: он не динамический, весьма сложный. Не забываем, что говорим мы о «специалистах в предметной области с базовым навыком программирования». По этой же причине отметается Clojure (еще не хватало специалистов-предметников основам ФП обучать).
Groovy лучше, но его никто не знает. Да и язык на самом деле совсем не простой.
А вот JS нынче знают многие. И, в случае чего, JS-код с бизнес-правилами можно с очень большой долей вероятности переиспользовать, хоть в браузере, хоть в другой системе.
Groovy лучше, но его никто не знает. Да и язык на самом деле совсем не простой.
А вот JS нынче знают многие. И, в случае чего, JS-код с бизнес-правилами можно с очень большой долей вероятности переиспользовать, хоть в браузере, хоть в другой системе.
Да, скала не динамическая, это я ошибся. Я имел ввиду возможность использовать скалу, как скриптовый язык для задание каких-то конфигураций или правил. Скалисты же гордятся, что на скале очень круто DSL'и писать, как и кложуряне.
Ну про переиспользование в браузере — мне кажется это скорее сказки. А так я бы предпочёл использовать какое-то более хорошо документированное и известное решение, чем какой-то внутренний движок, непонятный движок. Мне кажется, что если специфическая задача, то будешь что groovy/clojure под них подпиливать, что nashorn. Т.е. есть задача «Хотим сделать удобное задание бизнес-правил.» и всё равно будешь делать свой мини-dsl, что на clojure, что на javascript.
Ну про переиспользование в браузере — мне кажется это скорее сказки. А так я бы предпочёл использовать какое-то более хорошо документированное и известное решение, чем какой-то внутренний движок, непонятный движок. Мне кажется, что если специфическая задача, то будешь что groovy/clojure под них подпиливать, что nashorn. Т.е. есть задача «Хотим сделать удобное задание бизнес-правил.» и всё равно будешь делать свой мини-dsl, что на clojure, что на javascript.
Это все конечно так. Но предлагаю взглянуть на статистику: сколько людей знает (на уровне «могу что-то писать») JS, а сколько Clojure/Scala/Groovy. Думаю, эти цифры многое прояснят.
Вообще, я не призываю использовать JS (недолюбливаю всякие server-side-js). Но все же считаю, что у JS-движка на Java найдется достаточно применений, дабы такой движок создавать.
Вообще, я не призываю использовать JS (недолюбливаю всякие server-side-js). Но все же считаю, что у JS-движка на Java найдется достаточно применений, дабы такой движок создавать.
>А вот JS нынче знают многие.
Видели какие-нибудь серьезные исследования на эту тему? Доля вопросов по js на stackoverflow не превышает долю вопросов по java: hewgill.com/~greg/stackoverflow/stack_overflow/tags/#!java+javascript
Видели какие-нибудь серьезные исследования на эту тему? Доля вопросов по js на stackoverflow не превышает долю вопросов по java: hewgill.com/~greg/stackoverflow/stack_overflow/tags/#!java+javascript
Rhino, например, используется для компиляции coffeescript в maven-задаче с использованием официального компилятора кофескрипта: github.com/iron9light/coffeescript-maven-plugin (есть мой форк этого плагина с поддержкой более свежей версии компилятора и source maps).
Удалено. Перепутал кнопки «ответить» и «написать комментарий».
Штука хорошая, но проблема в том, что в реальных проектах нужно еще и безопасность обеспечивать, а также тонкий контроль выполнения кода. Rhino без обвязки позволяет всякие штуки типа ClassShuttrer. Плюс гибкий контроль над компиляцией кода. Стандарт jsr же все это скрывает, и делает весьма бестолковым использование js в реальных проектах.
Сам я разрабатываю PaaS для client/server приложений на js, поэтому в теме довольно плотно нахожусь…
Сам я разрабатываю PaaS для client/server приложений на js, поэтому в теме довольно плотно нахожусь…
Sign up to leave a comment.
Введение в Nashorn