Чем создание 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'ником, вертикально масштабируемым в рамках одного сервера приложений, а сейчас у меня даже не очень сложные должны быть распределёнными и использовать зоопарк технологий. Границы профессионализма с обеих сторон спектра раздвинулись. Вероятно, этим и объясняется снижение стабильности.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
