Comments 36
А ещë можно отключать верификацию байт-кода и подавать машине JVM любую дичь.
Причëм на любой JVM. Например, для Dalvik-а можно отключить (для Ведроида, чтобы по-быстрее работал телефон да и памяти жрал меньше).
https://xdaforums.com/t/get-more-ram-and-faster-responses-by-disabling-verify-bytecode.1263119/
Чем это чревато, надеюсь понятно...
Чем это чревато, надеюсь понятно...
Если честно то нет (ну кроме вылета JVM с каким-нибудь segfault), так что буду рад если раскроете тему.
И Далвика же больше нет, теперь это ART.
а у вас окружение на яве?)
так 3 задачка решаема (byte) + (char) - (int) + (long) - 1; 1 + 1 - 4 + 4 - 1
ой, а решаема 2 - 4 -2
только вот как это делает байт код машина я не скажу - не знаю
я лишь скромно надеюсь, что до использования такого кода на собеседованиях дело никогда не дойдет )
Этот трюк и в Си работает - https://onlinegdb.com/1mGliy0ho
Это последовательное преобразование типов .
1) (long)-1 -> 0xFF..FF
2) + 0xFF..FF -> 0xFF..FF
3) (int) 0xFF..FF -> 0xFF..FF
4) - 0xFF..FF -> 1
5) +(char)1 -> 1
6) (byte)1 -> 1
Т.е. куча унарных операций перемажающихся преобразованием типа. (byte) - (int) - 1 по идее даст тоже самое.
Как по мне, здесь чутка другая логика. Уберите касты, и у вас получится просто число
+-+-1 что равносильно единице. А так как последний каст будет лонгом, то и единица отображается верно
Нет, самый банальный Xfce )
https://en.wikipedia.org/wiki/A_Commentary_on_the_UNIX_Operating_System там внизу тоже прикольная цитата )
Но никаких упоминаний трюка с обфрускацией на его сайте найти не удалось.
Код приводится в самой книге, где упоминается IOCCC и сишный код, который вы в своем блоге показывали ("have fun"). Сам код немного другой и вместо Hi! выводит Hello, World!
Автор магии не раскрыл, просто сказал, что написал это на первое апреля и добавил:
You should be pretty good at reading Java code at this point, so I won't spoil your fun.
По ссылке код и цитата из книги на одном из форумов. Тут первые два абзаца того раздела из книги.
И это я ни разу не Java программист, но язык, в котором возможна такая дичь и допускаются невидимые идентификаторы это просто бомба!
Побуду душнилой и скажу, что никто ведь не обещал, что Java - это идеальный язык, в котором невозможно творить дичь. Это всё равно творение рук человеческих, и, как и в любом из них, в Java можно найти дыры и уязвимости (и более серьёзные, чем описаны в статье).
Но по сравнению с ...
В четвертом примере IDE (VS Code) ломает все веселье - даже подсказки работают )
P.S. Java безопасна и ожидаема относительно C/C++, но это не значит, что в ней нельзя творить разную дичь. Просто усилий надо чуть больше )
Круто, не знал что успели добавить - прогресс )
VS Code уже давно с Java работает - плагин от RedHat, eclipse под капотом (вероятно подпиленный).
Может поначалу и были проблемы с maven-проектами (особенно мультимодульными), да eclipse-специфичные файлы генерировались, что раздражало.
Но это все давно исправили и года 3-4 назад я полностью перешел на VS Code для Java - очень уж IDEA кажется тормозной после VS Code.
Пускай по возможностями и поддержке языка IDEA CE будет и лучше. Хотя... Уже несколько лет не запускал IDEA - не так уж эти возможности были востребованы у меня )
Зачем чувак на первой картинке сразу две сигареты курит, и почему одна из них горит, а не дымит? Это из-за программирования на Java?
Забавная статья. Стиль автора, обещающий жареных фактов, никуда не делся, но хоть себя не нахваливает, уже лучше.
«Безопасный язык» говорили они, «четкая спецификация» говорили они, «Java не даст вам выстрелить себе в ногу» и прочее в таком духе.
Ага, говорили. И это, конечно же, не было опровергнуто в статье.
Ну по сути два примера из всех показывают хоть сколько-то реальную небезопасность. Юникод на входе - я не понимаю, почему не запретили принимать таким образом символы из диапазона 0x20..0x7E плюс терминаторы строк (0x0A, 0x0C, 0x85). И кэш целых, непонятно, зачем допускать в него такой сторонний доступ. Остальные - общие алгоритмические трюки.
Если вам интересен вопрос безопасности в Java как платформе, то есть вот такая статья. Все же безопасность конструкций языка это несколько другое.
Еще подозреваю, что аналог кеша для чисел присутствует и в других языках, поскольку это логичный шаг для ускорения работы.
А вот эта КДПВ на 1.6MB - это необходимая часть статьи?
Как-то даже не заметил, извините.
21й век, пока браузер не подвиснет - размер картинок не уменьшают )
В соседней статье https://habr.com/ru/articles/875408/ рассказывают, как редакторы Хабра вручную с чек-листом сверяются, в том числе <400 КБ JPEG. @denis-19почему бы редактору текста автоматически не проверять такие банальности?
встроенного в JVM кеша для простых чисел.
Сначала удивился, что в джаве есть целый кеш для простых чисел. Потом перешёл по ссылке и увидел, что это всего лишь кеш объектов Integer (которые boxed).
На счёт жабы не скажу, но довелось мне тут случайно познакомиться с одной Российской импортозамечательной системой... Одна из замен САП-а. Так вот там для работы необходим справочник последовательных! натуральных! чисел! Который используется для нумерации строк в базе. И это реально справочник. Его надо создавать, заполнять и поддерживать. Поскольку с одной стороны он жрёт ресурсы (как я понимаю - не мало), с другой - если тебе не хватит его значений - в базе начнутся очень интересные спецэффекты. Так что нуже отдельный человек, который будет постоянно следить за его использованием и наполнением. Сама нумерация тоже становится процессом интересным, поскольку тебе надо каждый раз найти свободное значение в справочнике. Просто вывести все строки с нумерацией впринципе невозможно, поскольку таблица может быть на десятки тысяч строк, а справочник - на 100..500 значений. Да и сам процесс вывода весьма интересен с патологоанатомической точки зрения. Впрочем там вся система такая. Можно ткнуть в рандомное место и гарантировано найти крайне интересные технические решения и еще более интересные костыли, чтобы эти решения обойти.
Как известно, "Написать FORTRAN-программу можно на любом языке программирования".
Примеры весёлые, но это не тот случай когда ты можешь случайно словить такое поведение
Во втором примере про целые числа наверно речь, а не про простые
Думаю, Java создают на столько умные люди, что писать статью с её критикой - это дебилизм почти в любом случае.
Забавно, что ни один из примеров в статье не относится конкретно к Java. Разве что пример с кешем, хотя не уверен, что больше нет ЯП имеющих подобный кеш и аналог рефлексии.
Хотя на разбор процесса упаковки всех этих чисел в одно я бы посмотрел с интересом.
Собственно, упаковывается просто в обратную сторону, я бы сказал, даже проще, чем распаковывается. 26 латинских букв в 5 битов (32 значения) упаковать - обычное дело. Кодировка Base32 на этом принципе построена, хотя я в живую ее не видел ее использование, но Base64, которая на том же принципе построена - вот она везде в вэбе. Единственная тонкость здесь - пробел.
Дикая Java