Применительно к jvm это справедливо только для массивов примитивных типов. Для простых целочисленных примитивов внутри jvm есть только два типа - int и long. Так что насчёт экономии памяти тут большие нюансы.
Владимир Коротенко, конечно, без прогнозов и планирования никакой новый проект не начинается. Однако, всё не предусмотришь и за всем не уследишь. И для более точных прогнозов неплохо бы знать предел возможностей платформы, изучением которого как раз и занимается ТС.
Василий Банников, в настоящем хайлоаде самые невероятные сценарии как раз срабатывают в первую очередь и если в коде размер коллекции явным образом не ограничен, то обязательно наступит момент, когда коллекция переполнится. Так что эксперимент ТС вполне себе практический и добытые знания пригодятся в будущем.
Перебалансировка не производится, если консюмер подписан на конкретные партиции вручную. Так что если агент упадет, то никто не перехватит его сообщения.
MiniDeveloper, соглашусь с Сергей Горностаев. Вот прям буквально - подберите список языков, которые вы предпочли бы изучить, зайдите на сайт с вакансиями, ограничьте поиск по своему городу, по порядку вбивайте каждый язык и приступайте к изучению того языка, на который выпало максимальное количество вакансий. Это что касается "дальнейшего трудоустройства".
Далее, как только изучите выбранный язык на хорошем уровне, то можно будет отвлечься и на другие языки. Проблем с этим быть не должно, так как все императивные языки похожи друг на друга и вам не нужно будет тратить время на освоение тысячи мелочей, одинаковых во всех языках, и можно сразу сосредоточиться на самом интересном. Реально сложный в изучении только первый язык. Причём неважно какой он будет.
Изучать непопулярный язык с целью заработать на нём - это лотерея. Если не повезёт и вас сразу не возьмут ни в одно из 5 мест, куда требуется rust, то с трудоустройством будут явные проблемы.
Я похожим образом выбирал фреймворк для PHP проекта - выбирал из самых популярных в моём регионе и не прогадал.
Мне казалось комментарий к коду вполне ясно описывает, что System.gc() не позволяет управлять gc. Но судя по вашему комментарию, мне это и правда только казалось...
Если быть точным, то не jvm решает, а сборщик мусора.
Hotspot, например, честно триггеритсборку (если не используется опция -XX:+DisableExplicitGC). Но вот произойдёт ли она на самом деле - зависит от сборщика.
Точно могу сказать, что при использовании сборщика epsilon вызов System.gc() никогда не приведёт к сборке :)
Раз запрос технически соответствует документации, значит проблема административная и решить её можно только запросом в техподдержку. Спросите у них почему с вашим токеном запросы отклоняются.
Roman Biz, с библиотекой всё так. Не так здесь про проброс docker сокета в контейнер. По уровню безопасности это как запускать скрипты от имени root прям на хосте.
Валентин, полагаю, автор вопроса не имеет контроля над приложением, но очень хочет отреверсить его протокол. Был бы доступ к нешифрованному участку (к серверу, по сути), то и вопроса бы не возникло.
3.1, 3.2. Берётся из оперативной памяти. Не бывает такого, что загрузилась только часть класса, а потом по мере надобности догружаются оставшиеся части класса. Класс либо загружается в память полностью и создаётся объект класса Class для него, либо не загружается вообще с генерированием соответствующего исключения - ClassNotFoundException, NoClassDefFoundError, VerifyError, LinkageError и др. Создавать объекты и вызывать методы (статические и нестатические) можно только на полностью загруженном классе.