Давай пойдем издалека, какая у нас задача: 1. Получать результирующее актуальное

значение.

Варианты решения:
1. calculated field (не важно, свой java app, groovy runner whatever)
2. +1 custom field + listener

Разборы:
1. Зачем был придумано калькулируемое поле?
Итак, значение кастомных полей хранятся в БД и lucene index, а значения калькулируемых полей только Lucene index, а бд описание, то есть конфигурация.
Следовательно, при гипотетическом одинаковом коде количество тактов процессора побольше уйдет для кастомного поля.
2. Калькулируемое поле зло? При каждом *просмотре* реиндексируется.
Данное решение сложно реализовать потому что при классической инсталляции существует множество уровней кэширования. Что высока вероятно для триггера реиндекса.
Триггеры для реиндекса: по времени (cron-based) и изменение состояния.

3. Считаем, что код листенера имеет реиндексацию для актуальности данных для UI, а код калькулируемого не имеет:
3.1 Случай когда данные одинаковые и происходит валидный триггер на изменение поля:
В этом случае у листенера проверка на валидность проекта, типа (если запрограммировал инженер), а далее код одинаковый и происходит двойная индексация у листенера.
а калькулируемое поле сразу с общей реиндексацией задачи. (но стоит иметь ввиду бывает 3 вариации и комбинации к ним реиндексации: задачи, ворклог, комментариев и следовательно их вариации это 3 факториал вариантов)
3.2.Случай не валидный (например другой проект):
В этом случае не триггерит листенер, потому что первично срабатывает условие, что проект не валидный или контекст.
В калькулируемое поле триггерится, но при правильной настройке контекста поля не триггерится. Надо пинать админов тут.

4. Хранение данных в долгосрочной основе, так как значения в индексах только у калькулируемого то при первичных стартах нужен реиндекс, также как у листенера, но с оговоркой для проверки данных с бд, а в первом для расчета. Следовательно, реиндекс при холодных стартах дольше.
Но на в остальных случаях нет.

4.1. Хранение данных в БД кастомного поля:
тут используется EAV модель, но в версиях от 8 немного улучшение, для получения более плотной разреженной матрицы
Но это дорого в объеме: Описание тут
https://community.atlassian.com/t5/DevOps-Articles/Why-SysOps-DevOps-don-t-like-to-add-custom-fields-on-large/ba-p/1313834
4.2. Хранение в Lucene index:
в данном случае, если реализация плохо сделана для калькуруемого поля, то поле может иметь большой объем, и иметь не эффективные индексы,
тут надо смотреть конкретно по случаям
https://community.atlassian.com/t5/Confluence-articles/The-same-full-text-search-engine-for-different-products/ba-p/1319832

+ пока читаю, плюсану

Не, оно не так работает

Короче я прочитал и понял. Ловите разработчика из атласиан!!

Гончик, я про это статью сделаю. Там же все неправильно написано.

5.5. реализация калькулируемого поля в основном базируется на следующем интерфейсе: https://docs.atlassian.com/software/jira/docs/api/8.5.0/com/atlassian/jira/issue/customfields/impl/CalculatedCFType.html