Комментарии 25
Я не автор статьи, но могу сказать, что когда-то использовали MVEL, но отказались из-за его плохого масштабирования под нагрузкой и глючности. Может с тех пор что и изменилось...
Тогда перешли на JXPath, но со временем стало понятно, что и у него тоже под нагрузкой всё печально. Так что теперь опять приходится искать альтернативу.
Ну и как бы, если вы уже решили интерпретировать выражения (вы же их интерпретируете, скорее всего?) — то о какой производительности вообще речь? Тогда надо брать в руки что-то типа asm, и компилировать в байт код, хотя бы.
Ситуации бывают разные. У нас есть места где никакого байткода не хватит. Да и устраивало бы всё в JXPath, если бы не было косяков с синхронизацией.
А мерить да надо. Просто была мысль написать свою балалайку. А тут глядь — уже кто-то сделал. Ну и стало интересно.
Впрочем, здесь же, в силу особенностей предложенного языка, кроется резерв — всегда можно заменить длинную медленную цепочку короткой, просто написав нужный метод в корневом классе.
С одной стороны вроде как и нет, а с другой стороны — выдвигает требования к архитектуре библиотеки, из-за которых даже тривиальные вещи становятся намного более громоздкими в выполнении.
Так что лично мне подход автора весьма импонирует.
Но если у вас camel — то тогда экономить на спичках уже смысла нету, да :)
В нем он является одним из компонентов. Цель — декларативная команда для какой части сложной структуры данных предназначается конкретный кусочек данных. Сами данные поступают асинхронно и в произвольной последовательности, возможно даже, из независимых источников.
Главная моя претензия к SE — этот язык не очень здорово подходит для динамического исполнения. Собственно, и создавался то для параметризации статичных XML файлов. У меня можно по выбору, либо включать литерал непосредственно шаблон пути — а это удобно если все просто, никогда не меняется и описывается короткими строками, либо можно передать все параметры в массиве и ссылаться на них как $1, $2, и т.д. Не надо мудрить с генерацией путей, как это пришлось бы делать с SE. Обратные ссылки, опять же. Не только this или root, а любой однажды возникший в контексте объект в порядке их появления.
Чего у меня нет — вкусностей при работе со списками, и не уверен, надо ли. Попробуйте меня переубедить.
Так же у меня нет именованных параметров. Думал об этом, но не сложилась пока общая картина. Скажем, вместо $2 написать $userEmail, как то так.
На счет обратных ссылок, SpEL это язык выражений. Фактически каждое выражение — функция без побочных эффектов. На входе какието данные и параметры — на выходе результат.
Работа с параметрами и обработка результатов вычисления выражений, или складывание их в параметры или контекст — это все снаружи или часть инфраструктуры — которую лучше на обычном языке писать.
Что мне в SpEL нравится, так это то что одни и те же выражения могут работать на разных входных структурах данных — Java модель, мапы мапов/списков, результат из DB, XML DOM, и т.п.
Скажите, а это специально зависимость на JUnit не как тестовая добавлена?
Ну и использование в Maven диапазонов версий тоже приводит к весьма некомфортным последствиям, к сожалению: выкачивание всех доступных pom.xml, попадающих в указанный диапазон.
Читаемость кода, на мой взгляд, сильно падает. Плюс добавляется потенциальный источник глюков в духе: поле переименовали, а в строке на JavaPath забыли (в обычном коде вы это отловите в момент компиляции, а тут только при тестировании). Плюс нехилые тормоза добавляются (там ведь рефлекшены внутри, наверное?). И всё только ради избавления от лишних «if == null»?..
Для высокой скорости работы и статических проверок тут наверное можно использовать путь Lombok — генерацию нужных проверок и вызовов (тех, которые теперь не нужно писать руками) автоматически, со статической проверкой правильности всего сгенерированного на этапе компиляции.
Даже в вашем примере можно было бы написать (если бы Java, например, позволяла использовать имя класса / поля как текстовую константу, если в конце добавить знак #)
evalPath(user#name#,"Mike")
Скриптовый язык JavaPath для доступа к сложным структурам данных