Согласен, хотя WAF реализовать и легко, толково наполнить разрешениями уже посложнее. Просто у меня перед глазами мой маленький проект с небольшим числом гуляющих по сети классов. Не люблю я энтерпрайз-решения.
Я так понимаю, проблему не тяжело пофиксить через Security Manager, или кастомный class loader. Общая практика — надо описать разрешённые для загрузки классы (именно загрузка, а не сериализация) и запретить все остальные. Мало ли в какой библиотеке, какая дырка ещё не найдена.
Я так понимаю, тех. лид и может быть тем самым «старшим». Ведь без формального бейджика он может чувствовать себя не в праве уделять багам меньше времени чем другие члены команды. Может не иметь формального права «ставить точку» в споре, который длится уже долго, а какое-то (пусть и плохое) решение — будет лучше чем ещё один день в митинге. И ещё разные моменты есть.
Отличные вопросы!
1. в System.out можно увидеть какой именно код отдаётся на видеокарту. Он похож на код в Groovy, но исполняется как просто отдельно написанный, и с Groovy или JVM никак не связан. Никакого GC, конечно.
2. свои объекты создать нельзя, хотя у меня есть планы это реализовать (но там магия, и у меня сейчас нет задачи нуждающейся в таком). Сейчас можно использовать только то, для чего есть аналоги в glsl — примитивы, вектора, матрицы, текстуры.
3. например, строчка vector1 = vector2 — в Groovy означает копирование указателя, а в glsl означает копирование значений. Поэтому при исполнении этой строчки в Groovy и в glsl будет разный эффект. Но хочется мочь запускать тесты, поэтому для нахождения таких мест и сообщения об ошибке я использую анализ синтаксического дерева, о котором и есть эта статья.
4. Да, код синтаксически очень похож. Насчёт Java->С++, — чтобы провернуть такую компиляцию, надо либо имплементить GC на таргет платформе, либо в Java в явном виде использовать деструкторы или пулы. Либо использовать какую-то её ограниченную версию, как в моём подходе.
1. AST дерево я получаю из Groovy (ну, это понятно)
2. трансляции в glsl, Groovy metaprogramming никак не поможет. Мне нужна на выходе вполне конкретно оформленная строчка. Вот это оформление и описано в «перегруженных функциях». Ещё можно было бы использовать Visitor-pattern, но это уже дело вкуса. Кода и так и так не много.
3. анализ кода. Получение данных о том, какой параметр (или его поле) в качестве какого аргумента передаётся. Как используются поля (или уже ИХ поля). И т.п. На эту тему в приведённой вами документации ничего нет.
Так а что там про анализ? Там всё про AOP и кодогенерацию. Разве что GroovyCodeVisitor, но про него я написал. Буду рад узнать если что-то упустил из виду!
Проблемы роста, проблемы архитектуры, неудачных решений, непредвиденных технологий, обратной совместимости, и много чего ещё. В программировании эти все грабли известны, изучены и классифицированы.
Но главное — если с такими проблемами не может справиться, например, десктопное приложение — его обгоняет конкурент, который молод, который другой, которому удаётся принять и похендлить новые вызовы. А в интернете, к сожалению, кто-то решил что конкуренция платформ не нужна, а всем хватит одного стандарта.
Согласен, Kotlin был бы в трэнде :) Тоже смотрел на него, но не могу выделить время чтобы разобраться как из него AST выдрать. На stackoverflow не знают. Если умелец найдётся — соберём за пару дней.
Рад что не только мне это интересно!
Сейчас версия шейдера — 130. Да, хочется поддерживать разные версии, и геометрический шейдер — хороший повод :)
Я абсолютно не представляю что можно рассказать об истории разработки. Может перечислите что было бы интересно услышать лично вам?
Я так понимаю, проблему не тяжело пофиксить через Security Manager, или кастомный class loader. Общая практика — надо описать разрешённые для загрузки классы (именно загрузка, а не сериализация) и запретить все остальные. Мало ли в какой библиотеке, какая дырка ещё не найдена.
1. в System.out можно увидеть какой именно код отдаётся на видеокарту. Он похож на код в Groovy, но исполняется как просто отдельно написанный, и с Groovy или JVM никак не связан. Никакого GC, конечно.
2. свои объекты создать нельзя, хотя у меня есть планы это реализовать (но там магия, и у меня сейчас нет задачи нуждающейся в таком). Сейчас можно использовать только то, для чего есть аналоги в glsl — примитивы, вектора, матрицы, текстуры.
3. например, строчка vector1 = vector2 — в Groovy означает копирование указателя, а в glsl означает копирование значений. Поэтому при исполнении этой строчки в Groovy и в glsl будет разный эффект. Но хочется мочь запускать тесты, поэтому для нахождения таких мест и сообщения об ошибке я использую анализ синтаксического дерева, о котором и есть эта статья.
4. Да, код синтаксически очень похож. Насчёт Java->С++, — чтобы провернуть такую компиляцию, надо либо имплементить GC на таргет платформе, либо в Java в явном виде использовать деструкторы или пулы. Либо использовать какую-то её ограниченную версию, как в моём подходе.
2. трансляции в glsl, Groovy metaprogramming никак не поможет. Мне нужна на выходе вполне конкретно оформленная строчка. Вот это оформление и описано в «перегруженных функциях». Ещё можно было бы использовать Visitor-pattern, но это уже дело вкуса. Кода и так и так не много.
3. анализ кода. Получение данных о том, какой параметр (или его поле) в качестве какого аргумента передаётся. Как используются поля (или уже ИХ поля). И т.п. На эту тему в приведённой вами документации ничего нет.
Но главное — если с такими проблемами не может справиться, например, десктопное приложение — его обгоняет конкурент, который молод, который другой, которому удаётся принять и похендлить новые вызовы. А в интернете, к сожалению, кто-то решил что конкуренция платформ не нужна, а всем хватит одного стандарта.
Сейчас версия шейдера — 130. Да, хочется поддерживать разные версии, и геометрический шейдер — хороший повод :)
Я абсолютно не представляю что можно рассказать об истории разработки. Может перечислите что было бы интересно услышать лично вам?