Скорее спринг - монополист в области аутсорсинга или компаний с большим количество разных продуктов. Когда у компании есть команда и постоянная текучка проектов, то для компании намного удобнее научить команду клепать проекты на спринге, так как это наиболее популярный фреймворк и намного проще и дешевле найти спрингового человека в команду, ему сразу будет понятны все осталные проекты. А там, где есть один-два постоянных продукта, спринг выбирают не так часто.

https://youtu.be/m9lXNzyists?t=2264 — с таймкодом. Весьма интересно и познавательно

ага, есть китайский, корейский, японский.

т.е. плагины локализации,в  принципе, есть... Но написаны только для самых популярных стран для java)

Как можно в HQL провернуть фокус типо where table.date < current_date - 10 days, где table.date это java.util.date?

Можно попробовать сделать так LocalDate date = LocalDate.now().minusDays(10); и передать date как параметр
Единственный минус что в сигнатуре метода будет параметр хотя вроде по вашему случаю всегда должно вычитаться 10 дней

@dmsol ну ты бы оставил сообщение с ссылкой на рабочий чатик :)

😀 хорошо спасибо

Всем привет
Увидел как то на проде лог CodeCache is full. Compiler has been disabled.
Хорошо что смотрел доклад Владимира Ситникова)
Вопрос такой - можно как то вычислить подходящий размер для кодкэша? ПО каким то косвенным характеристикам приложения

По количеству кода, который собирается быть скомпилированным во время работы JVM)
Капитанство, конечно, но как точнее сказать?)

а как понять сколько будет скомпилировано?

Я вижу пока только 1 выход - увеличивать пока не станет понятно сколько нужно, но может есть еще способ

Ну это самый правильный способ. Думаю, в среднем размер код-кеша не является доминирующим в общем объёме потребляемой памяти, особенно в моменты, когда чувствуется его нехватка

а можно как то понять какие проблемы есть когда компиляция останавливается, если пока никаких видимых проблем нет?
я к тому, что с проблемами пока никто не прибежал, но они вполне могут быть. И если я знаю что кодкеш заканчивается и что какой то энв может тормозить, то могу я найти где и как он тормозит?

гляньте на этот проект https://github.com/AdoptOpenJDK/jitwatch

Ну смотрите: сама по себе остановка компиляции может и не быть проблемой. Некоторые приложения вообще запускают с -Xint и горя не знают.
Если всё-таки попробовать найти в этом какую-то проблему, то можно, наверное, найти несколько возможных причин.
- нестабильная компиляция. Т.е. JIT делает предположения, которые когда-то перестают быть верными. Например, проверка на null не возвращала true, а потом стала, а потом наоборот и т.д.
- есть генерируемый код, который активно вызывается. Если код будет постоянно появляться, использоваться, компилироваться, а потом выкидываться - Code Cache может наполняться очень активно.
- В качестве маловероятного сценария, но всё же - может быть утечка памяти в JIT, на которую вы наткнулись.

Чтобы это диагностировать, можно попробовать:  -XX:+PrintCompilation, -XX:+LogCompilation и подобное

+1
Может есть какой-то фрейворк, который генерирует код? Типа орики

Но принт компилейшн выдас очень много, так что готовьтесь )

есть, орика

О как я угадал )

Ну тогда памяти нужно на то количество мапперов чтв у вас есть