Не знаю, как другие, я лично хотел бы видеть больше технических подробностей в статьях. Хабр вообще по сути золотая середина между чисто научными публикациями и научпопом (или по крайней мере должен ей быть) - понятный язык, свободный формат и техническая содержательность.
Что касается checked-исключений, это конечно древний костыль, но костыль легко обходимый без смены языка. В новом коде можно просто их не писать, а для вызова методов с throws существует zero-cost (ну, почти zero) хак:
Очень сумбурно, новички не поймут. От установки (почему только на макось-то? :) ) сразу к коммитам через ремоуты (wat?), а потом уже совсем к посторонним вещам.
Стоило бы дать краткий экскурс (зачем нам этот ваш гит-то вообще нужон), объяснить базовые принципы, ветвление, мерджи и далее по нарастающей.
Про установку имхо стоило ограничиться только ссылью на оф. сайт.
Также странным решением выглядит притянутый за уши гитхаб (+10 к путанице для начинающих) и постоянные прыжки между консолью и idea gui.
Выглядит так, как будто это была внутренняя дока компании/проекта, которую затем попытались превратить в статью.
Плюс, идентичного материала на хабре уже предостаточно (тык и тык).
Итого, как минимум статья нуждается в доработке, а как максимум в форме howto-гайда (особенно в текущем состоянии) является откровенным велосипедом.
P.S. Картиночек многовато. Логи из консоли можно было оформить как code-блоки, а скриншоты gui засунуть под спойлеры.
Не пройдёт - nested классы, чтобы считаться таковыми, должны входить в объявление родителя. Решения вроде задать классу имя Parent$Class очевидно не работают.
Можно воспользоваться java agent'ом, чтобы ловить момент первой загрузки класса, тобишь линковку, и подменять в нём нужные модификаторы на паблик (или вписать nested-классы).
В jeflect'е было реализована эта фича, но позже убрана, потому что работала не для всех классов (момент линковки "системных" классов перехватить изнутри невозможно) и плюс не все jvm разрешают работать с агентом полноценно.
Другим прикольным способом обойти проверки доступа будет загрузка dll, хукающую кишки машины, и изменение таким образом слинкованной информации, но тут тоже много подводных камней - можно что-то поломать, узнав об этом через несколько часов по падению прода с сегфолтом, и решение получается платформозависимым.
В целом обходов много, но универсальные вряд ли есть + подобный функционал нужен еще реже, чем прокси-генераторы.
Каким образом кэширование поможет ускорить рефлективные вызовы метода? Имхо, максимум можно кэшировать получение объекта java.lang.reflect.Method, но это даст выигрыш лишь в скорости подготовки вызова.
Если вы говорите о кэшировании сгенерированных прокси-классов, чтобы не создавать их заново для одной и той же связки класс-метод, то это уже по сути детали конкретной реализации, которые были опущены, чтобы не загружать обзорную статью.
P. S. Если имеется ввиду кэширование получаемой из метода информации, дабы предотвратить излишние вызовы, то это материал для совершенно другой статьи.
Про var handles не знал, спасибо. Что насчет jmh, в данном случае его использование показалось излишним, все измерения сводились к вызову нескольких методов, да и точности используемого подхода вполне хватает.
Не знаю, как другие, я лично хотел бы видеть больше технических подробностей в статьях. Хабр вообще по сути золотая середина между чисто научными публикациями и научпопом (или по крайней мере должен ей быть) - понятный язык, свободный формат и техническая содержательность.
Маловато технических деталей и не хватает сравнения с bdwgc, но как идея статьи - интересновое.
Что касается checked-исключений, это конечно древний костыль, но костыль легко обходимый без смены языка. В новом коде можно просто их не писать, а для вызова методов с throws существует zero-cost (ну, почти zero) хак:
И теперь можно откуда угодно делать
Вуаля, проблема решена. Ну, или можно пользоваться checked-фичей, как задумано. Тоже как вариант.
P.S. В случае с InterruptedException я бы даже сказал, что это плюс - такая себе жесткая напоминалка не забыть флаг прерывания.
Если код будет признан горячим, jit компилятор должен и так убрать повторные вызовы .size().
Сложение строк тоже давным давно превращается в билдер на уровне javac.
К библиотекам от апач тоже много вопросов из-за их любимых транзитивных зависимостей - джарник потом весит сотни метров.
И полностью отказаться от блокировок в пользу concurrent hash map в общем случае довольно сложно.
Там два минуса подряд
Плюс ещё сокращенный вариант аргумента -v можно использовать, чтобы меньше печатать было
Очень сумбурно, новички не поймут. От установки (почему только на макось-то? :) ) сразу к коммитам через ремоуты (wat?), а потом уже совсем к посторонним вещам.
Стоило бы дать краткий экскурс (зачем нам этот ваш гит-то вообще нужон), объяснить базовые принципы, ветвление, мерджи и далее по нарастающей.
Про установку имхо стоило ограничиться только ссылью на оф. сайт.
Также странным решением выглядит притянутый за уши гитхаб (+10 к путанице для начинающих) и постоянные прыжки между консолью и idea gui.
Выглядит так, как будто это была внутренняя дока компании/проекта, которую затем попытались превратить в статью.
Плюс, идентичного материала на хабре уже предостаточно (тык и тык).
Итого, как минимум статья нуждается в доработке, а как максимум в форме howto-гайда (особенно в текущем состоянии) является откровенным велосипедом.
P.S. Картиночек многовато. Логи из консоли можно было оформить как code-блоки, а скриншоты gui засунуть под спойлеры.
Вопрос хороший и не совсем тривиальный :)
Хорошее замечание, дополню
Не пройдёт - nested классы, чтобы считаться таковыми, должны входить в объявление родителя. Решения вроде задать классу имя Parent$Class очевидно не работают.
Можно воспользоваться java agent'ом, чтобы ловить момент первой загрузки класса, тобишь линковку, и подменять в нём нужные модификаторы на паблик (или вписать nested-классы).
В jeflect'е было реализована эта фича, но позже убрана, потому что работала не для всех классов (момент линковки "системных" классов перехватить изнутри невозможно) и плюс не все jvm разрешают работать с агентом полноценно.
Другим прикольным способом обойти проверки доступа будет загрузка dll, хукающую кишки машины, и изменение таким образом слинкованной информации, но тут тоже много подводных камней - можно что-то поломать, узнав об этом через несколько часов по падению прода с сегфолтом, и решение получается платформозависимым.
В целом обходов много, но универсальные вряд ли есть + подобный функционал нужен еще реже, чем прокси-генераторы.
Действительно, вы правы, про это я как-то забыл.
Спасибо, дополнил статью
Для наглядной демонстрации влияния создания массива на скорость вызова был создан вне цикла "константный" массив, содержащий 5 в качестве аргумента.
Каким образом кэширование поможет ускорить рефлективные вызовы метода? Имхо, максимум можно кэшировать получение объекта java.lang.reflect.Method, но это даст выигрыш лишь в скорости подготовки вызова.
Если вы говорите о кэшировании сгенерированных прокси-классов, чтобы не создавать их заново для одной и той же связки класс-метод, то это уже по сути детали конкретной реализации, которые были опущены, чтобы не загружать обзорную статью.
P. S. Если имеется ввиду кэширование получаемой из метода информации, дабы предотвратить излишние вызовы, то это материал для совершенно другой статьи.
Про var handles не знал, спасибо. Что насчет jmh, в данном случае его использование показалось излишним, все измерения сводились к вызову нескольких методов, да и точности используемого подхода вполне хватает.