Прямой корреляции нет, но косвенно, по количеству запросов, можно судить о востребованности языка. Статистика по гитхаб определят больше популярность языка в opensource. И ещё, в статистике не объём репозиториев, а их количество (поэтому на 1-м месте javascript с кучей мелких репозиториев), т.е. объём eclipse не играет роли. Действительно, репозиториев на c# возможно мало из-за того, что он не популярен в opensource. У c# и экосистемы .net узкая ниша разработки под платформы на базе windows (я знаю про mono), которая сейчас не так популярна, как в 2000-х.
Про развитие языка, я согласен с тем, что java по количеству вносимых фич давно отстала от c#, в этом есть как плюсы так и минусы. Тем кому нужны фичи и новые возможности мигрируют на другие языки, не меняя платформу jvm — scala, clojure, groovy.
С# я практически не знаю, но мне кажется по богатству возможностей scala его опережает. Тем не менее scala не так уж и популярна из-за своей сложности (высокий порог входа для новичков), т.е. простота языка java это в какой-то мере плюс.
1) При интенсивном выводе в stdout очень сильно тормозил браузер при просмотре лога работы тестов
2) При использовании кеширования (cache в gitlab-ci.yml) и одновременном запуске двух билдов похоже, что для второго билда кеш не используется (соответственно выкачивается всё что можно из интернета)
Может хочется странного, но хочется иметь «кнопку» для выпуска релиза — merge ветки в develop в master с интерфейса gitlab (с возможностью задать теги, комментарии). Сейчас релизы делаем или через merge request (develop -> master) в gitlab или вручную объединяем ветки и пушим в мастер.
А мы вот наоборот, потихоньку, мигрируем с jenkins на gitlab-ci. Основные причины — конфиг CI лежит в вместе с проектом, тестируем в контейнерах, для некоторых проектов свои контейнеры (например ffmpeg собранный с определенными ключами) и баджи с результатом билда в merge request-ах. С jenkins не получилось толком интегрировать gitlab ce (видимо для качественной интеграции нужен gitlab ee).
В моём случае структура базы данных как на промежуточных серверах, так и на центральном сервере абсолютно идентична, а значит у меня есть проблема — уникальность ключевых полей.
Проблему уникальности autoincrement идентификаторов можно решить настройкой сервера:
auto_increment_increment — с каким шагом прирастают идентификаторы, одинаковое значение на всех серверах, >= количеству серверов
auto_increment_offset — смещение внутри диапазона auto_increment_increment, уникальное для каждого сервера.
Решение не будет работать если не инициализировать ThreadLocal и будет если инциализировать, и это не связано с тем откуда у нас тред. То что у нас повсеместно треды переиспользуются, означает что крайне важно сбрасывать ThreadLocal когда он не нужен (и с точки зрения корректности и с точки зрения memory leak-ов).
2 — не верно.
С interrupted-тредами возможны два состояния
1) у треда стоит статус «interrupted»
2) выпал «InterruptedException» (или подобное исключение)
В первом случае с потоком исполнения ничего не происходит пока не произойдет вызов некоторых методов или блокирующего i/o. Вообще говоря тред может и не заметить что он «прерван» до вызова определенных методов. И в таком случае, после завершения try блока, произойдет нормальное исполнение finally блока.
Это одни из «корней», т.е. GC и не должен очищать объекты доступные по ссылкам из thread local/classloader.
Тут скорее возможность получить OOM, если бесконтрольно класть что-то в thread local или перезагружать классы/класслоадеры.
Другой частой причиной возникновения утечек является наличие циклических ссылок. В этом случае сборщик просто не может решить, нужны ли ещё объекты, перекрёстно ссылающиеся друг на друга.
GC спокойно справляется с этим, т.к. ищет из «корней» все достижимые объекты. Если некий набор перекрестно ссылающихся объектов недостижим, то он будет спокойно очищен сборщиком мусора.
У меня работает. В том числе и поиск по истории (ctrl+r), но у меня linux, возможно под windows не работает.
История хранится в /home/user/.groovy/groovysh.history
Про развитие языка, я согласен с тем, что java по количеству вносимых фич давно отстала от c#, в этом есть как плюсы так и минусы. Тем кому нужны фичи и новые возможности мигрируют на другие языки, не меняя платформу jvm — scala, clojure, groovy.
С# я практически не знаю, но мне кажется по богатству возможностей scala его опережает. Тем не менее scala не так уж и популярна из-за своей сложности (высокий порог входа для новичков), т.е. простота языка java это в какой-то мере плюс.
1) При интенсивном выводе в stdout очень сильно тормозил браузер при просмотре лога работы тестов
2) При использовании кеширования (cache в gitlab-ci.yml) и одновременном запуске двух билдов похоже, что для второго билда кеш не используется (соответственно выкачивается всё что можно из интернета)
Проблему уникальности autoincrement идентификаторов можно решить настройкой сервера:
auto_increment_increment — с каким шагом прирастают идентификаторы, одинаковое значение на всех серверах, >= количеству серверов
auto_increment_offset — смещение внутри диапазона auto_increment_increment, уникальное для каждого сервера.
Решение не будет работать если не инициализировать ThreadLocal и будет если инциализировать, и это не связано с тем откуда у нас тред. То что у нас повсеместно треды переиспользуются, означает что крайне важно сбрасывать ThreadLocal когда он не нужен (и с точки зрения корректности и с точки зрения memory leak-ов).
2 — не верно.
С interrupted-тредами возможны два состояния
1) у треда стоит статус «interrupted»
2) выпал «InterruptedException» (или подобное исключение)
В первом случае с потоком исполнения ничего не происходит пока не произойдет вызов некоторых методов или блокирующего i/o. Вообще говоря тред может и не заметить что он «прерван» до вызова определенных методов. И в таком случае, после завершения try блока, произойдет нормальное исполнение finally блока.
Лучше использовать ThreadLocal:
А run_user определяется по владельцу jar-файла:
Тут скорее возможность получить OOM, если бесконтрольно класть что-то в thread local или перезагружать классы/класслоадеры.
GC спокойно справляется с этим, т.к. ищет из «корней» все достижимые объекты. Если некий набор перекрестно ссылающихся объектов недостижим, то он будет спокойно очищен сборщиком мусора.
История хранится в /home/user/.groovy/groovysh.history