Благодарю! Когда-то очень давно слышал про него, а потом напрочь вылетело из головы.
Насколько я понял из беглого прочтения README, если запускать через Maven-плагин или через CLI, наверное ему всё равно нужен доступный docker daemon. Да, с моим подходом можно заменить docker cli на jib cli, например, в первом образе.
Возможно, в течении пары недель попробую собрать им и посмотреть на разницу в итоговом образе со сборкой моим Dockerfile-ом.
Пару лет пользовался Rainbow brackets, но в последней версии IDEA заметил, что он тормозит, постоянно нагрузка на CPU. Выключил, Идея [относительно] полетела.
Всё равно в светлой теме от него не сильно проку :(
Так это в таком примере простом размер commited такой, потому что поток ничего кроме записи в консоль не делает. В реальной жизни большая вложенность стека, в том числе куча проксей, и в методах может быть куча аллоцированных на стеке данных.
Я лично в своих проектах (джава 15, к слову) уменьшаю Xss до 512 кб, потому что уменьшать дальше страшновато. То, что commited != max это понятно и замечательно.
Была похожая задача, по запросу API отдавали .xlsx, формируемый POI. В какой-то момент данных стало в разы больше, решили поменять формат на .csv. Из БД streamAllBy...(), тоже с какими-то хинтами (mysql), апачевский csv writer пишет в цикле сразу в httpResponse-овый outputStream. Ну да, у бизнеса нет форматирования колонок, им норм:) Зато быстро работает, не ограничен размером сверху и временных файлов на диске не требует.
Увы приходится. Продакшен, деньги, вот это вот все.
Конечно, я не знаю конкретно вашей ситуации, но в моей (аутсорс, финтех) тоже есть продакшен, от которого зависит и финансовое положение и репутационное заказчика. Обновляемся каждый раз до свежего релиза уже 2+ года спустя примерно месяц после его выхода.
неLTS это именно беты. Там в каждой есть критические баги.
Можно примеры таких багов?
Единственный баг, который реально словили за всё время — описан в этой статье (сами с ним не разобрались, а просто на бою накинули ресурсов). При этом наверняка были какие-то тонкости, которые время от времени решали, но это было быстро и незаметно.
Поэтому я всё-таки склонен считать, что релизы это именно релизы. Для достаточной уверенности можно не использовать preview features (я использую), и подождать хотя бы первого Update.
А вот как обосновать хотя бы пару недель два раза в год для пересаживания на неLTS с учетом потенциальных багов в ней я не знаю.
Ваши "2 недели 2 раза в год" — как-то очень завышено. В среднем это от 1 часа до 1 дня. Иногда (12 -> 13 и 13 -> 14) уходило по 5 минут на Find & Replace. Как раз то, что даже можно не пропихивать бизнесу, а просто взять и сделать, потому что обсуждать дольше (естественно, речь про один среднего размера проект на единицы микросервисов, а не "целый банк").
Единственное, что меня реально пугало бы в любом отдельно взятом проекте — миграция с 8 на 9+.
Обоснований куча. Для меня это шанс обновляться маленькими шагами, а не огромным скопом. Плюс возможность иметь фишки раньше. Не надо относиться к неLTS как к бетам.
А вы генератор или какой-то свой другой код не планируете выкладывать в открытый доступ?
9/19 "за", так и знал, что я не плюсовик! :)
Мне кажется, с Java 8 стоило хотя бы начинать. Это старьё уже никому не интересно и сотни раз расписано.
У них слишком маленький рынок
Благодарю! Когда-то очень давно слышал про него, а потом напрочь вылетело из головы.
Насколько я понял из беглого прочтения README, если запускать через Maven-плагин или через CLI, наверное ему всё равно нужен доступный docker daemon. Да, с моим подходом можно заменить docker cli на jib cli, например, в первом образе.
Возможно, в течении пары недель попробую собрать им и посмотреть на разницу в итоговом образе со сборкой моим Dockerfile-ом.
Люди делятся на два типа :))
Хипстеры и луддиты. Не важно, разработчики они или сисадмины, или кто-то ещё :) По каждую из сторон баррикад есть и те, и те.
П.с. Хипстеры 4евер!
Пару лет пользовался Rainbow brackets, но в последней версии IDEA заметил, что он тормозит, постоянно нагрузка на CPU. Выключил, Идея [относительно] полетела.
Всё равно в светлой теме от него не сильно проку :(
Так это в таком примере простом размер commited такой, потому что поток ничего кроме записи в консоль не делает. В реальной жизни большая вложенность стека, в том числе куча проксей, и в методах может быть куча аллоцированных на стеке данных.
Я лично в своих проектах (джава 15, к слову) уменьшаю Xss до 512 кб, потому что уменьшать дальше страшновато. То, что commited != max это понятно и замечательно.
Какие-то странные у Вас потоки, по 16 кб. А стек по умолчанию на 1 мб/поток?
Была похожая задача, по запросу API отдавали .xlsx, формируемый POI. В какой-то момент данных стало в разы больше, решили поменять формат на .csv. Из БД streamAllBy...(), тоже с какими-то хинтами (mysql), апачевский csv writer пишет в цикле сразу в httpResponse-овый outputStream. Ну да, у бизнеса нет форматирования колонок, им норм:) Зато быстро работает, не ограничен размером сверху и временных файлов на диске не требует.
Так у них полноценная поддержка, а не расширенная :)
Альфа и бета подразумевают нестабильность. Это полноценные релизы.
Для Вас это слишком быстро, несколько новых языковых фич за несколько лет?
Спасибо за ответы.
Конечно, я не знаю конкретно вашей ситуации, но в моей (аутсорс, финтех) тоже есть продакшен, от которого зависит и финансовое положение и репутационное заказчика. Обновляемся каждый раз до свежего релиза уже 2+ года спустя примерно месяц после его выхода.
Можно примеры таких багов?
Единственный баг, который реально словили за всё время — описан в этой статье (сами с ним не разобрались, а просто на бою накинули ресурсов). При этом наверняка были какие-то тонкости, которые время от времени решали, но это было быстро и незаметно.
Поэтому я всё-таки склонен считать, что релизы это именно релизы. Для достаточной уверенности можно не использовать preview features (я использую), и подождать хотя бы первого Update.
Ваши "2 недели 2 раза в год" — как-то очень завышено. В среднем это от 1 часа до 1 дня. Иногда (12 -> 13 и 13 -> 14) уходило по 5 минут на Find & Replace. Как раз то, что даже можно не пропихивать бизнесу, а просто взять и сделать, потому что обсуждать дольше (естественно, речь про один среднего размера проект на единицы микросервисов, а не "целый банк").
Единственное, что меня реально пугало бы в любом отдельно взятом проекте — миграция с 8 на 9+.
Обоснований куча. Для меня это шанс обновляться маленькими шагами, а не огромным скопом. Плюс возможность иметь фишки раньше. Не надо относиться к неLTS как к бетам.
Really? O_o
А можно подробности? У меня не такой случай (Xmx=Xms), но ваше заявление очень интересно. Спасибо.
Возможно, хаб Java тут лишний?
Действительно, my fault. Исправил.
(2021 — 1995) / 16 = новая версия каждые ~1.5 года, неплохо идёт! :))