По поводу п.1 — это не совсем так. Точнее, это совсем не так. Jira предоставляет довольно обширный API для кастомизации. Другое дело, что документация у них одна из худших, что я видел. Но, при наличии нормальной Java IDE, это не является какой-либо серьезной преградой.
В кеше вполне может быть значение null и в этом случае ваш код будет всегда перекешировывать этот null. В «удобном» же варианте такого не должно происходить. Да и set метод скорее всего возвращает void.
JIRA имеет API для расширения как самого приложения, так и расширения поведения workflow.
В первом случае можно просто создать кастомный CustomField, и реализовать в нем комплексную валидацию.
Во втором случае мы имеем достаточный функционал для контроля всего жизненного цикла тикетов: триггеры, обработчики событий, превалидация форм, пост-функции workflow.
В оправдание вашего костыльного метода можно сказать, что JIRA и ее компоненты имеют отвратительную документацию, и, зачастую, устаревшую, если вы используете последнюю на данный момент версию (7.x).
В первом случае можно просто создать кастомный CustomField, и реализовать в нем комплексную валидацию.
Во втором случае мы имеем достаточный функционал для контроля всего жизненного цикла тикетов: триггеры, обработчики событий, превалидация форм, пост-функции workflow.
В оправдание вашего костыльного метода можно сказать, что JIRA и ее компоненты имеют отвратительную документацию, и, зачастую, устаревшую, если вы используете последнюю на данный момент версию (7.x).