Комментарии 25
А чем это в принципе лучше, например MVEL, которому сто лет в обед?
Я не автор статьи, но могу сказать, что когда-то использовали MVEL, но отказались из-за его плохого масштабирования под нагрузкой и глючности. Может с тех пор что и изменилось...
Тогда перешли на JXPath, но со временем стало понятно, что и у него тоже под нагрузкой всё печально. Так что теперь опять приходится искать альтернативу.
В принципе, я ваш аргумент понял. Хотя применительно к данному продукту — его же надо сначала померять, чтобы убедиться, что он реально быстрый.
Ну и как бы, если вы уже решили интерпретировать выражения (вы же их интерпретируете, скорее всего?) — то о какой производительности вообще речь? Тогда надо брать в руки что-то типа asm, и компилировать в байт код, хотя бы.
Ну и как бы, если вы уже решили интерпретировать выражения (вы же их интерпретируете, скорее всего?) — то о какой производительности вообще речь? Тогда надо брать в руки что-то типа asm, и компилировать в байт код, хотя бы.
Ситуации бывают разные. У нас есть места где никакого байткода не хватит. Да и устраивало бы всё в JXPath, если бы не было косяков с синхронизацией.
А мерить да надо. Просто была мысль написать свою балалайку. А тут глядь — уже кто-то сделал. Ну и стало интересно.
Текущая версия 0.2 сфокусирована на стабилизации и развитии синтаксиса. Специально производительность не оптимизировалась и кое какие ресурсы здесь еще есть. Но, все верно, ожидать большего чем может предложить Java Reflection и родственные библиотеки не приходится.
Впрочем, здесь же, в силу особенностей предложенного языка, кроется резерв — всегда можно заменить длинную медленную цепочку короткой, просто написав нужный метод в корневом классе.
Впрочем, здесь же, в силу особенностей предложенного языка, кроется резерв — всегда можно заменить длинную медленную цепочку короткой, просто написав нужный метод в корневом классе.
Тем что намного проще. javaPath это язык для инлайновых инструкций. В нем нет управляющих конструкций
Ну, вообще мне например (а еще в рамках apache camel) ничего не мешает применять в качестве именно такого языка даже например groovy. Управляющих конструкций… дело в том, что если я их не использую — их для меня и нет. Используете только выражения — и там все почти так же. Ну то есть это (наличие чего либо) — ну не совсем аргумент.
С одной стороны вроде как и нет, а с другой стороны — выдвигает требования к архитектуре библиотеки, из-за которых даже тривиальные вещи становятся намного более громоздкими в выполнении.
Так что лично мне подход автора весьма импонирует.
Но если у вас camel — то тогда экономить на спичках уже смысла нету, да :)
Ну, я на самом деле про подход ничего плохого не хотел сказать — я всего-лишь пытаюсь лучше понять цели.
Вообще-то это офф-спринг другого, более масштабного проекта github.com/aegisql/conveyor/wiki — реактивного аггрегатора и строителя
В нем он является одним из компонентов. Цель — декларативная команда для какой части сложной структуры данных предназначается конкретный кусочек данных. Сами данные поступают асинхронно и в произвольной последовательности, возможно даже, из независимых источников.
В нем он является одним из компонентов. Цель — декларативная команда для какой части сложной структуры данных предназначается конкретный кусочек данных. Сами данные поступают асинхронно и в произвольной последовательности, возможно даже, из независимых источников.
Присоединяюсь к этому вопросу. Почему, например не SpEL из Spring? Он компилируется, поддерживает конструкции для работы с коллекциями, литералы для мапов и списков, расширяемый и поддерживает условные выражения…
Да собственно, можно вообще любой скриптовый язык задействовать. Хоть JavaScript, или Python. В данном случае, отказ от усложнения вполне сознательный. Ну и, не используется SPRING. Я, лично, даже не в курсе, можно ли каким-то естественным образом извлечь и использовать только один язык из всей монстроидной корневой библиотеки SPRING
Модуль называется spring-expression и это не скриптовый язык, а язык выражений.
Давно сам лично не работал с Spring Expression. Обновил знания.
Главная моя претензия к SE — этот язык не очень здорово подходит для динамического исполнения. Собственно, и создавался то для параметризации статичных XML файлов. У меня можно по выбору, либо включать литерал непосредственно шаблон пути — а это удобно если все просто, никогда не меняется и описывается короткими строками, либо можно передать все параметры в массиве и ссылаться на них как $1, $2, и т.д. Не надо мудрить с генерацией путей, как это пришлось бы делать с SE. Обратные ссылки, опять же. Не только this или root, а любой однажды возникший в контексте объект в порядке их появления.
Чего у меня нет — вкусностей при работе со списками, и не уверен, надо ли. Попробуйте меня переубедить.
Так же у меня нет именованных параметров. Думал об этом, но не сложилась пока общая картина. Скажем, вместо $2 написать $userEmail, как то так.
Главная моя претензия к SE — этот язык не очень здорово подходит для динамического исполнения. Собственно, и создавался то для параметризации статичных XML файлов. У меня можно по выбору, либо включать литерал непосредственно шаблон пути — а это удобно если все просто, никогда не меняется и описывается короткими строками, либо можно передать все параметры в массиве и ссылаться на них как $1, $2, и т.д. Не надо мудрить с генерацией путей, как это пришлось бы делать с SE. Обратные ссылки, опять же. Не только this или root, а любой однажды возникший в контексте объект в порядке их появления.
Чего у меня нет — вкусностей при работе со списками, и не уверен, надо ли. Попробуйте меня переубедить.
Так же у меня нет именованных параметров. Думал об этом, но не сложилась пока общая картина. Скажем, вместо $2 написать $userEmail, как то так.
В SpEL есть поддержка параметров. Они там называюстся переменными — #primes.?[#this > #maxValue]. Фактически передается мап значений.
На счет обратных ссылок, SpEL это язык выражений. Фактически каждое выражение — функция без побочных эффектов. На входе какието данные и параметры — на выходе результат.
Работа с параметрами и обработка результатов вычисления выражений, или складывание их в параметры или контекст — это все снаружи или часть инфраструктуры — которую лучше на обычном языке писать.
Что мне в SpEL нравится, так это то что одни и те же выражения могут работать на разных входных структурах данных — Java модель, мапы мапов/списков, результат из DB, XML DOM, и т.п.
На счет обратных ссылок, SpEL это язык выражений. Фактически каждое выражение — функция без побочных эффектов. На входе какието данные и параметры — на выходе результат.
Работа с параметрами и обработка результатов вычисления выражений, или складывание их в параметры или контекст — это все снаружи или часть инфраструктуры — которую лучше на обычном языке писать.
Что мне в SpEL нравится, так это то что одни и те же выражения могут работать на разных входных структурах данных — Java модель, мапы мапов/списков, результат из DB, XML DOM, и т.п.
Кстати, есть еще такая штука как Janino. Жив, курилка, лет 15 уже… Там тоже есть компилятор выражений, но язык Java — более многословно чем SpEL
Скажите, а это специально зависимость на JUnit не как тестовая добавлена?
Ну и использование в Maven диапазонов версий тоже приводит к весьма некомфортным последствиям, к сожалению: выкачивание всех доступных pom.xml, попадающих в указанный диапазон.
Пугающе.
Читаемость кода, на мой взгляд, сильно падает. Плюс добавляется потенциальный источник глюков в духе: поле переименовали, а в строке на JavaPath забыли (в обычном коде вы это отловите в момент компиляции, а тут только при тестировании). Плюс нехилые тормоза добавляются (там ведь рефлекшены внутри, наверное?). И всё только ради избавления от лишних «if == null»?..
Читаемость кода, на мой взгляд, сильно падает. Плюс добавляется потенциальный источник глюков в духе: поле переименовали, а в строке на JavaPath забыли (в обычном коде вы это отловите в момент компиляции, а тут только при тестировании). Плюс нехилые тормоза добавляются (там ведь рефлекшены внутри, наверное?). И всё только ради избавления от лишних «if == null»?..
Отказ от boilerplate кода — это хорошо. Но вот возможность увидеть ошибку только после запуска приложения и обращения к соответствующему методу — это ужасно. Тесты конечно должны покрывать всё… но гарантий в реальной разработке немного. Переименование методов и полей — это норма, я уже не говорю о более сложных рефакторингах, и каждое такое действие будет ломать формулы. В идеальном мире — я бы хотел просто повесить аннотацию на поле или getter / setter, что-то типа @AutoPath, после чего писать как обычно, но иметь нужное количество if-ов и создания отсутствующих объектов автоматически.
Для высокой скорости работы и статических проверок тут наверное можно использовать путь Lombok — генерацию нужных проверок и вызовов (тех, которые теперь не нужно писать руками) автоматически, со статической проверкой правильности всего сгенерированного на этапе компиляции.
Для высокой скорости работы и статических проверок тут наверное можно использовать путь Lombok — генерацию нужных проверок и вызовов (тех, которые теперь не нужно писать руками) автоматически, со статической проверкой правильности всего сгенерированного на этапе компиляции.
Ужасно, не ужасно, но это реальность с которой со-существует любая технология сериализации-десериализации. Приходится следить за актуальностью схемы.
Да, Java в части метаинформации — убогий язык. Была бы возможность ссылаться на имена элементов (классов, функций, полей, аргументов) непосредственно в коде с контролем компилятора — большинство библиотек бы выглядели совершенно по-другому.
Даже в вашем примере можно было бы написать (если бы Java, например, позволяла использовать имя класса / поля как текстовую константу, если в конце добавить знак #)
Даже в вашем примере можно было бы написать (если бы Java, например, позволяла использовать имя класса / поля как текстовую константу, если в конце добавить знак #)
evalPath(user#name#,"Mike")Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скриптовый язык JavaPath для доступа к сложным структурам данных