Чем создание JVM под конкретные платформы «лучше», «проще», «продвинутее», «правильнее» написания компиляторов под те же платформы?
В книгах и статьях о языке программирования Java всегда говорится о том, что идея компиляции байт-кода, который исполняет строго стандартизованная JVM, решила проблему переносимости, платформонезависимости, программ.
Мол, вместо того, чтобы писать компилятор для каждой платформы, что достаточно сложно и затратно, теперь достаточно написать виртуальную Java-машину для каждой платформы, что, подразумевается, гораздо проще. При этом я ни разу не встречал объяснения: а чем, собственно, проще?:)
Разные архитектуры процессоров, разные ос, инструкции и прочее. Чтоб упростить что либо, надо разделить сложное на мелкое, то есть есть машина и адаптер, адаптер как прослойка
Дмитрий, все-таки это общие слова. Компилятор - та же прослойка. И разделение "сложного на мелкое" совсем необязательно дает хороший результат.
Для разных архитектур процессоров, разных ос и прочего придется писать и разные компиляторы и разные виртуальные машины. В чем разница? Хотелось бы более конкретных примеров. Типа, вот как сложно это (что-нибудь) пришлось бы реализовывать в компиляторе, и вот как изящно и просто - в JVM.
BartonFink, ну так вся сложность что для каждой новой архитектуры нужно будет писать свои компилятор, а так сама виртуальная машина будет конкретно переводить код. Код один, платформ много. А не как в си куча дефайнов и проверять каждый чих
BartonFink, JVM напишет, образно говоря, один разработчик. А вот кучу дефайнов и кода под каждую из платформ придется писать каждому разработчику, который захочет чтобы его ПО работало не только на одной платформе, а потом еще скомпилировать под каждую платформу отдельным компилятором. А девиз Java ведь такой: «Написано однажды - работает везде». Чисто теоретически и очень утрированно - можно взять скомпилирвоанную программу на Java под ПК и запустить ее на каком-то старом мобильном телефоне, работающим на Java.
Сергей Горностаев, Дмитрий Шицков, Дмитрий, да, для прикладных программистов преимущества очевидны, здесь вопросов нет. Меня смущала сентенция в духе "теперь не надо писать компиляторы для каждой платформы". Будто виртуальные машины для них же писать не придется.
для прикладных программистов преимущества очевидны
И не только для прикладных. Ну и для конечных пользователей тоже очевидны, которым не придется страдать без их любимого ПО.
"теперь не надо писать компиляторы для каждой платформы".
Я такого бы не сказал, т.к. да, ваше утверждение верно - вместо отдельного компилятора для платформы пишется JVM. Насколько это более или менее затратно чем разработка компилятора - не могу сказать.
Дмитрий Шицков, Если рассуждать примерно как "JVM включает в себя компилятор из Java-bytecode в машинный код и ещё много разных других компонентов, которые тоже могут быть платформозависимыми", то JVM Будет сложнее чем обычный компилятор как раз на это "куча других компонентов"
Упрощения для разработчиков инструментальных средств - это тема очень непростая. Намного легче объяснить плюсы с позиции прикладного программиста и пользователей ПО. В 2003-м году я участвовал в разработке одной системы на Java EE. Написанный мной и другими разработчиками код был скомпилирован с помощью Java 1.4, упакован в war и развёрнут на сервере заказчика. Это был сервер с 32-битными процессорами Xeon Prestonia, работавший под управление FreeBSD. Позже это приложение в том же war-файле было перенесено на сервер Fujitsu PRIMEPOWER с процессорами абсолютно иной архитектуры - SPARC, и управляемый очень отличающейся операционной системой - Solaris. Сейчас оно крутится на IBM'овских блэйдах c процами POWER и под управлением AIX, на сколько мне известно. Не удивлюсь, если через некоторое время приложение перенесут на что-нибудь с ARM'ами и под Linux или HP-UX. Все эти миграции выполняются без перекомпиляции и без привлечения разработчиков. Если бы приложение было написано на чём-нибудь вроде C++, код приложения пришлось бы портировать на каждую платформу и перекомпилировать. Это было долго, сложно и очень дорого.
Сергей, а расскажи, как писались приложения в 2003? Как строилась разработка, какие архитектурные подходы применялись, писались ли юнит-тесты на все подряд или покрывался основной функционал? Мне кажется, что раньше приложения были стабильней, а трава зеленее и хочу понять, дело в программистах, в менеджменте или в моем восприятии.
Roman Kitaev, я тогда ещё зелёный был, всех нюансов не видел, но особой разницы в подходах энтерпрайза двадцатилетней давно и подходов современного не замечаю. Архитектурно разработка именно на Java EE не поменялась за прошедшие годы. Только теперь у нас есть IDE, не надо писать многокилометровые xml-конфигурации и наследоваться от многокилометровых интерфейсов. Что поменялось - в целом системы стали сложнее, а в частностях проще. Раньше от простого ковыряльщика web-слоя ожидалось знание сетей, протоколов и всего стандарта JEE в деталях, теперь развитое web-приложение может набомбить человек, смутно понимающий разницу между фронтом и бэком. Плюс, раньше сложное энтерпрайз-приложение могло ограничиваться одним war'ником, вертикально масштабируемым в рамках одного сервера приложений, а сейчас у меня даже не очень сложные должны быть распределёнными и использовать зоопарк технологий. Границы профессионализма с обеих сторон спектра раздвинулись. Вероятно, этим и объясняется снижение стабильности.
В теории, проще тем, что не нужно каждую программу перекомпилировать под все платформы. Ты получаешь один файл для каждой программы и запускаешь его везде, где есть jvm. Если разработчик программы с закрытыми исходниками не скомпилировал её под твою платформу, то ты эту программу никогда не запустишь.
На практике всё не так радужно, конечно.
Чтобы портировать например OpenJDK на любую платформу, потребуется изменить максимум 1% платформозависимого кода. Портирование чего-нибудь вроде GCC требует существенно большего количества работы.
Простой
