OSDev

"относительно вменяемым" будет и текст на голом ассемблере. Вопрос только в приемлемости такой вменяемости.

Компиляторы неспроста не производят существенную оптимизацию при компиляции в байткод. И совсем неспроста в байткод введены возможности хранить названия функций, перменных и прочего. Всё это есть тот самый высокий уровень байткода, против которого первым стал возражать Yoda. И при машино-независимом байткоде это реально единственный правильный путь, ведь если бы компилятор выкидывал много лишней по его мнению информации из байткода, то следующий обязательный этап JIT компиляции на разных платформах страдал бы от отсутствия нужной информации, а разработчики не получали бы понятной отладочной информации.

Речь не о специфических инструкциях. Хотя в байткоде они есть (в виде кучи данных о названиях, например). Но дело началось с того, что Yoda решил назвать байткод низкоуровневым представлением, доказывая несостоятельность моих доводов о преимуществах Java. Ну и я в ответ показал высокоуровневые возможности байткода на примере компиляции-декомпиляции. И при этом ни про какие специфические инструкции не упоминал.

Это не только информация для отладки. Есть куча применений этих самых имён под общим названием introspection. То есть данные о именах после их введения оказались очень даже нужными и многими активно используются в чистой воды логике кода. И далее на этой основе в язык введены аннотации, что ещё более повысило важность всяческих имён. Так что имена - очень даже важный аргумент, правда непонятно в каком споре, ведь что вы собственно пытаетесь доказать ? Что ассемблер более понятен чем байткод ?

Есть так называемые обфускаторы, которые не только заменяют имена на всякий бред, но и меняют набор действий программы таким образом, что бы конечный результат алгоритма сохранялся, но внутреннее его содержимое оказалось бы максимально сложным для понимания. Но, естественно, подобные чудеса ни коим образом не относятся к разговору об уровне абстракции в байткоде и возможностях компиляторов.

Можно пример ? Вы сейчас по сути заявили, что байткод содержит неверный логический код, не соответствующий ожиданиям программиста. Это весьма смелое заявление, поэтому хотелось бы каких-то подтверждающих данных.

Нет, я всего лишь заявил, что генераторы байт-кода зачастую создают такой код, который очевидным образом не декомпилируется. Конкретный файл привести не могу, ибо NDA, однако таких файлов множество. Зачастую декомпиляторы выдают код, к примеру, следующего вида:

И это без всякой обфускации. Угадайте, что это было в начале. А что иногда (не часто) начинается при сложных условиях, особенно для циклов, с учетом ленивости вычислений - смотреть страшно.

Хорошо. Возьмем все имена, заменим на численные идентификаторы. Код будет продолжать работать. Многие обфускаторы меняют, и все работает.
Теперь. Возьмем строки чисел и заменим реально на числа. Все то же самое. А чем это отличается от связывания по адресам? Да, по сути своей, ничем; при динамической линковке в DLL адреса точно также можно вычислять с использованием индексов функций и подставлять, все продолжает работать. Единственное - буквы читать удобнее, чем какие-то чиселки и идентификаторы.
А также вы в курсе, что спецификация, к примеру, Dalvik, косвенно рекомендует писать код так, чтобы аннотации не значили по сути ничего, кроме той же самой удобной при отладке информации? Вернее сказать, что там написано так: "аннотации описаны в таком-то формате для того, чтобы файлы для более поздних версий DVM всегда работали на более старых". Да, аннотации можно просто вырезать, и программа будет работать. Я так делал на работе сотни раз (один мой инструмент для простоты игнорирует аннотации при обработке файла и, как следствие, выносит их при сохранении).

Я уже описал, что эта информация почти бесполезна компилятору, имеет смысл она только для разработчика. Высокоуровневостью же в байткоде жабы не пахнет и близко. Просто потому, что тут нет никаких конструкций, кардинально отличающих его от любых ассемблеров. Те же самые push/pop/add/mov/jmp, к которым добавили еще пару вариаций new. Вызов метода по имени, как я уже сказал, запросто мог бы быть заменен на идексы/адреса, и все бы работало так же; виртуальные функции делаются с помощью массивов индексов/адресов. В то время как высокоуровневый язык отличается в первую очередь тем, что имеет логические конструкции, а не просто массив команд с переходами по нему как заблагорассудится. То есть байткод был бы высокоуровневым, если бы, к примеру, строился только в виде дерева кода и в таком же виде и хранился. А так, как он есть - ассемблер ассемблером. Так что компилятор как раз-таки выкидывает огромное количество информации о логике кода, переводя его в низкуровневый язык, являющийся тупым массивом команд. Компилятор из байткода в машинный код уже не знает, где цикл, где условие. И нет, goto на адрес раньше текущего еще циклом не является.
Высокоуровневость присутствует в плане построения структуры дерева классов, т.е. архитектуры самой ВМ, и небольшой поддержки этого в байткоде. Однако это не очень сильный аргумент в пользу качественной компиляции, т.к. именно к переводу одного набора низкоуровневых команд в другой не имеет почти никакого отношения.

Теряюсь в догадках. Особенно "вставляет" наличие двух "мёртвых" фрагментов кода и отсутствие вообще чего-либо живого (то есть хоть что-то делающего с данными или осуществляющего переходы).

Если некий "декомпилятор" называет себя именно декомпилятором и выдаёт такое, то у меня есть сильное подозрение о грамотности авторов либо о неком дополнительном усложнении задачи вроде кривого перевода из далвиковского кода в стандартный Java-байткод. Гуглы они вообще те ещё "друзья программистов", от них вполне можно ожидать кастрации всего полезного в нормальном байткоде и превращение этого месива в "андроид".

Продолжать работать будет лишь в большинстве случаев. То есть тривиальное использование длины строки с названием метода уже всё портит. Хотя да, это редкость, потому и прокатывает замена обфускаторами, но до поры до времени. То есть опять имеем пример декомпилятора от начинающих студентов - да нафиг париться про какие-то там редкие варианты, ведь меня пока устраивает ...

Здесь вообще не понял - вы же уже заменили строки на числа выше. Зачем тогда введение никому ненужной сущности "строка чисел" ?

Зависит от того, что вы понимаете под связыванием по адресам. Если вы про адреса функций/методов, то в случае с JVM это никаким местом не относится к названиям методов. То есть вы просто путаете сладкое с длинным.

Вы же сами написали про обратную совместимость, о которой гугло-кодеры не захотели думать изначально, а теперь нагибают всех остальных думать за них. То есть вы привели пример убожества и предлагаете на его основе делать далеко идущие выводы. Вы поймите - если вы имели дело только с андроидом, вы совсем не стали знатоком Java, но лишь познакомились с кастрированной гуглами версией изначально гораздо более глубоко продуманной системы.

Ну дело ваше, но для моего компилятора информация очень даже нужна.

Ну так вы возможно и С с Java называете низкоуровневыми языками ? Те же mov/add/jс к которым добавили new. В чём вы видите признаки высокоуровневости ?

И как по вашему, можно назвать оператор switch в Си или Java логической конструкцией ? Если нет - то что же тогда есть логическая конструкция ? А если да, то вы должны признать байткод высокоуровневым по вашему собственному определению. Как бы похоже, что вы зарапотровались маленько

Ну опять заявление из серии "я не подумал". Или вы готовы привести пример на фортране с указанием развесистых деревьев и такой же формы хранения обычного текста в кодировке ASCII ?

В общем, я бы рекомендовал вам осмыслить предмет разговора и излагать не в виде нефильтрованного потока сознания, но всё же после прочтения ваших собственных аргументов хотя бы пару раз.

На все отвечать не буду, ввиду того, что читаете вы не очень внимательно и пытаетесь перевести стрелки на якобы мою некомпетентность, поэтому только ключевые моменты.

if, while - это и есть самые основные логические конструкции. Switch тоже, отчасти (в pascal - да, а вот в C/Java его принцип кривоват, основана на обычном goto, где case - это метки). И как раз по моему определению байткод жавы не является высокоуровневым.
Проблема в том, что в байткоде циклов нет вообще, условия только на уровне if + goto (сравните с jz/jnz в асм), а switch сводится к куче джампов (точнее, к одному джампу по переменному адресу, но не суть), благодаря чему код опять же становится беспорядочным месивом команд и переходов по ним.
Возвращаясь к моему примеру в самом начале, этот код на самом деле до компиляции выглядел так:

Неожиданно, да? И дело не в убогости разработчиков декомпилятора. Вот так это выглядит в, так сказать, псевдо-байткоде (недодекомпиляция для понятности):

Распишите a > b на push+push+if, а b = b + 5 в push push add pop (мне привычней в терминах обычной асмы), и получите реальный байткод метода. Такое я вижу очень часто. Java любит так делать.
А теперь финт ушами. Как, по вашему, будет выглядеть условие

? А как оно будет выглядеть, если это условие цикла? А если это условие для break/continue? Вот тут-то и всплывает главное отличие низкоуровневого кода от высокоуровневого. В низкоуровневом (байткоде жавы, асме и т.д.) это превратиться в raw-массив команд, осуществить качественный анализ которого и выделить логические блоки из беспорядочного лабиринта прыжков затруднительно. Во всяком случае из 5 опробованных мной декомпиляторов (jd, jad, fernflower, еще один какой-то и мой самопальный:) последний можно не учитывать) все периодически выдают бредовый код.

И нет, я занимаюсь не только андройдом, а преимущественно андройдом. В то же время работаю и с обычной жабой, и мой самопальный недодекомпилятор не для далвика, а для обычной жабы.

Ну я вас совсем не понимаю - если switch тоже, то почему "как раз по моему определению байткод жавы не является высокоуровневым" ? Если некий принцип "кривоват" в С, то почему он вдруг уже совсем не кривоват в паскале ?

Ну и если if по вашему мнению является логической конструкцией без оговорок, то вот вам тот же if из байткода:

Сравните эту запись с бэйсиком:

Ну да, нету слов then и goto, но для рускоговорящего начинающего программиста что then, что goto, что if_icmpgt - всё едино.

Ещё раз предлагаю сравнить с кучей языков высокого уровня (а ля бэйсик или фортран), где все эти goto цветут во всей красе.

То есть декомпилятор проигнорировал goto label1 и тем самым полностью извратил смысл программы. Разве можно назвать не кривым декомпилятор, который тупо удаляет часть инструкций из программы ?

Будет выглядеть вот так:

После декомпиляции jad-ом будет выглядеть вот так:

Сравните с начальным вариантом:

Очередной раз убеждаюсь, что всё прекрасно в мире нормальной Java и нормальных декомпиляторов.

Я, конечно, понимаю ваш внутренний бунт против "непонятности" байткода с первого взгляда. Но точно так же вам будет непонятен любой язык высокого уровня, где привычные if then goto заменены на что-то менее привычное. Например есть такой язычок от конторы 1С, он очень похож на бэйсик, но там все ключевые слова переведены на русский язык, так вот все кто сталкивается с этим язычком первым делом начинают возмущаться - ну что за уроды это придумали, ну что за убожество, ну и т.д. А всё потому, что просто в нём привычные ключевые слова заменены на непривычные.

Рад, что вы не на пустом месте заявления делаете, но даже свой декомпилятор создали. Ни чуть не ёрничаю.

Мда. Sii и Yoda явно были правы. Жаль.