Жаль, что в статье вы не коснулись проблем безопасности. Правильно настроить безопасность приложения с учётом всех возможных вариантов запросов очень сложно и это одно и самых слабых мест GraphQL.
Мы используем для улучшения производительности. Создавая Method handle единожды, избегаем постоянных проверок во время вызова, которые есть в java.lang.reflect.Method.
Текущая ситуация не располагает к использованию Oracle JDK. LTS спустя 6 месяцев после релиза теперь только за деньги. Более того, Oracle JDK = OpenJDK (с некоторыми патчами) для JDK 8+. Единственное важное отличие — Java FX было нивелировано тем, что Java FX больше не входит в JDK.
Я так понимаю, что более сложному и адекватному решению в JDK просто не нашлось места. У JVM нет стандартного инструмента сборки, есть только низкоуровневые утилиты.
Так нет такого пункта в AGPL. Там написано, что ты должен открыть исходники. Это компании предлагали купить при двойном лицензировании, чтобы использовать под коммерческой лицензией.
Резюмируя: разница в неявном и явном указании на купить.
Разница вот в чём:
— в AGPL не написано, что ты должен что-то купить. Написано — что должен открыть исходный код. Купить — это частное следствие из лицензии и вариант, который предлагают компании.
— в SSPL написано, что ты должен купить, если не выполняешь условия бесплатного использования.
Такие методы используются компилятором, чтобы улучшить жизнь разработчикам. Иногда, эта магия ломается (например, при несовместимости версий библиотек), поэтому полезно о ней знать.
Ваша программа слинкованная с JDK не становится GPL программой. Ровно до тех пор, пока вы не линкуетесь с нативным кодом JDK и пока используете публичные механизмы Java. Конечно же, вам разрешено наследовать классы JDK, тут ограничений нет.
YARG полностью независимый от платформы OSS продукт, с отдельным релиз циклом. Все его фичи доступны без платформы.
Модель вывода чуть проще, но благодаря этому мы поддерживаем много форматов вывода: DOC/DOCX, XLS/XLSX, PDF, HTML, CSV и множество вариантов загрузки данных: SQL/JPQL/Groovy/JSON/Custom.
До кучи, YARG можно запускать как микросервис, даже если вы не пишете на Java.
Многостраничная (с динамическим числом страниц) генерация в YARG пока возможна только в custom форматтерах, это направление пока только планируем развивать.
Не все любят генерировать код дополнительный, когда все эти сведения и так есть в коде сущностей. Согласитесь, если бы была поддержка компилятором — было бы всем лучше.
Да, это тоже нормальное решение, но получается, что мы генерируем ещё код по классам сущностей, дополнительный boilerplate. Это всё мог бы давать и компилятор, как в случае с C#.
Тут действительно автор этот момент не поясняет. Например, в C# nameOf используется для биндинга данных с учетом атрибутов свойства, а для их получения нужна рефлексия.
Найдите, пожалуйста, как это сделано в Guava для свойств. Статья ничего не говорит про класс литералы. Тут речь о том, чтобы получить доступ к аннотациям над полями, при этом типобезопасно. BeanValidation как раз нуждается в аннотациях, а не только в значении поля.