Comments 24
Может быть стоит запретить еще и Unsafe?
Так ведь уже запланировано?
Читал с удовольствием, узнал немало нового…
Вот только слово «хачим» режет слух, и ассоциации вызывает несколько не те, которые надо :)
И пусть «интуитивно понятно», что имел в виду автор, но может лучше не выпендриваться и написать «хакаем» хотя бы в заголовке?
Например, что я сделал сегодня для Хабры?
Проехал 67 километров на велике по каким-то лютым загородным дорогам, и даже вляпался в одну помойку.
Пруфы: https://www.strava.com/activities/973207781
Полученные от поездки силы обещаю потратить на еще какую-нибудь статью.
Согласен, что это очень странная логика, но в моем случае она иногда работает.
Прочитал на одном дыхании!
Чот вообще не верю :)
Человека с парой лет опыта работы с Java такое может удивить, остальным скорее должно быть просто интересно, что поменялось в девятке относительно такого использования reflection (и о чудо, все изменения ожидаемы, даже если не читать детали jigsaw), а уж у инженера, работавшего в Oracle где-то около JRE/JDK (ну и по совместительству лидера JUG.ru и организатора кучи Java конференций), эта статья наверн просто должна вызвать реакцию типа "опять пишут про то как менять циферки в Integer пуле" (:
Сама по себе статья норм though.
В даненом случае, цель была в маленьком победоносном примере, потому что обычно люди не хотят ввязываться в подробности, а хотят увидеть общий вывод, выраженный в три строчки.
Олег, у меня к статье никаких претензий, просто иногда личность автора важнее контента, а это убирает объективность из коммьюнити и приводит к печальке.
Причина моего первого комментария в том, что у мистера 23derevo (которого я, кстати, считаю оч интересным человеком, если что) огромный вес в русскоязычном Java комьюнити и вот такие комменты типа "Прочитал на одном дыхании! Олег, жаль, что ты не часто пишешь на хабре :)" это явный триггер другим "Хочешь рейтингов в статьях, одобрения от комьюнити и первые слоты на конференциях? Надо дружить с правильными людьми!".
У меня нет сомнений в вашей экспертизе, но хочется объективности, пишите лонгрид!
Я, конечно, слоупок, но вроде как вторая часть этого комментария только подтверждает мои слова :)
// Комментариям в этом треде оценки не ставил, если что.
Ну и хорошо тогда :)
Я не с целью обидеть или рассердить это пишу. Просто боюсь потерять хорошее русскоязычное Java комьюнити, последние несколько лет наблюдаю печальные трансформации в Android Dev мире (в основном зарубежном), где кучка "экспертов" оккупировала все конференции, дайджесты и тд, вот пытаюсь хоть тут это остановить.
Энивей, спасибо за хорошие конференции и вот это всё, просто не забывайте про объективность! (особенно по отношению к участникам Разбора-_Полетов, благо у них самоирония в порядке)
Конечно, уже не про набивший оскомину jigsaw, но тоже лонгрид по формату :)
Напоминаем, что Integer содержит приватный внутренний класс IntegerCache, содержащий объекты типа Integer, для диапазона от -127 до 128
А не наоборот? Из javadoc:
* Cache to support the object identity semantics of autoboxing for values between
* -128 and 127 (inclusive) as required by JLS.
Посмотрим, станет ли оно реальностью: http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-May/000874.html
void redefineModule(Module module,
Set<Module> extraReads,
Map<String,Set<Module>> extraExports,
Map<String,Set<Module>> extraOpens,
Set<Class<?>> extraUses,
Map<Class<?>,List<Class<?>>> extraProvides);
Более того, ClassFileTransformer API теперь умеет понимать Module
default byte[] transform(Module module,
ClassLoader loader,
String className,
Class<?> classBeingRedefined,
ProtectionDomain protectionDomain,
byte[] classfileBuffer)
throws IllegalClassFormatException;
Сами джава-агенты всё так же грузятся по класспасу без модуляризации, но это может измениться в будущем.
За дополнительными вопросами лучше всего обратиться к известному деятелю Rafael Winterhalter, он про это знает всё.
(Если интересна тема джава-агентов, у него есть на ютубе куча разных видео, в том числе для jugru, jpoint, joker. Запрос в ютуб не пишу, сам придумаешь :)
Какая практическая польза от описанных в статье манипуляций с IntegerCache?
Ещё есть волшебный ключик --permit-illegal-access.
Over time, as we've gotten closer and closer to the JDK 9 GA date, more
and more developers have begun paying attention to the actual changes
in this release. The strong encapsulation of JDK-internal APIs has, in
particular, triggered many worried expressions of concern that code that
works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
warning of this change was given in JDK 8.
To help the entire ecosystem migrate to the modular Java platform at a
more relaxed pace I hereby propose to allow illegal reflective access
from code on the class path by default in JDK 9, and to disallow it in
a future release.
In short, the existing «big kill switch» of the `--permit-illegal-access`
option [1] will become the default behavior of the JDK 9 run-time system,
though without as many warnings. The current behavior of JDK 9, in which
illegal reflective-access operations from code on the class path are not
permitted, will become the default in a future release. Nothing will
change at compile time.
Хачим IntegerCache в Java 9