Суть виртуальной машины Java?

Объясните пожалуйста на пальцах, что представляет из себя среда выполнения Явы, почему большинство языков либо компилируемые, либо интерпретируемые, а у Явы что то не понятное...
Что обеспечивает кроссплатформеность? Я же правильно понял, что без дополнительного софта, программа на яве не запустится в той же винде...?
  • Вопрос задан
  • 3095 просмотров
Решения вопроса 3
ruFelix
@ruFelix
Предсказание будущего по руке, таро, кофе.
Ну смотрите процессор компьютера понимает опкоды, для разных процессоров свои опкоды, x86 , AMD64, ARM и т.д.

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

Интерпретируемые языки поступают иначе, они имеют в своём составе интерпретатор, который транслирует код программы в опкоды процессора. Соответственно реализовав один раз интерпретатор по разные платформы мы получаем кроссплатформенный язык.

Виртуальня машина java это тоже интерпретатор по сути, но ему на вход идёт не сама java программа, а её трансформированный вариант, т.е. уже проверенный и более удобный для VM.

Да вы всё правильно поняли, без JVM программа на java не запуститься не где. Замечу что например в симкарте вашего телефона есть процессор на котором запущена JVM и софт который на ней исполняется, это я к тому, что кроссплатформенность у java действительно широка.
Ответ написан
pi314
@pi314
Президент Солнечной системы и окрестностей
Тут дали уже много хороших и правильных ответов, но хотелось бы уточнить, что вот эта метафора:
Виртуальня машина java это тоже интерпретатор по сути

может направить по весьма ложному пути!

У слов в названиях есть достаточно точный смысл, и JVM называется именно машиной, а не интерпретатором, и не компилятором совершенно не случайно. Компилятор в Яве есть (javac), и он нужен не для выполнения программы, а именно для ее компиляции (в байткод). Имено поэтому он не входит в состав JRE (среды выполнения), а содержится в JDK (среде разработки). В самой JVM есть еще один, JIT-компилятор, который компилирует байткод в инструкции процессора во время выполнения программы, но это уже другая история, и его тоже никак не назвать интерпретатором.

По сути JVM - это процессор, только виртуальный. И как у любого процессора (железного, типа x86, или виртуального, типа CLR в .NET), у него есть свой набор опкодов, называемый байткодом. Так же точно, как на х86 может выполняться код, порожденный компилятором с C++, или Pascal, или Go, так же и на JVM может выполняться байткод, скомпилированный из Java, или Scala, или Kotlin (или даже написанный вручную), а .class -файл, это, по сути, тот же .exe (точнее .so), скомпилированный под "процессор JVM". В этом и заключается кроссплатформенность. Так же, как код, скомпилированный под х86 будет выполняться на процессоре от Intel или AMD, так же и байткод JVM будет выполняться на JVM от Oracle, IBM, OpenJDK и т.д. И даже наличие JIT, компилирующего байткод в опкод конкретного железного процессора во время выполнения, все еще не дает повода обзывать честную стековую (SUN) или регистровую (Dalvik) VM интерпретатором, пусть даже и по сути :)

Дело в том, что сама эта классификация (интерпретируемый/компилируемый ЯЗЫК) последние лет эдак 25 уже практически лишена смысла. Языкам, изначально ориентированным на реализацию в виде интерпретатора (с просто анализируемой лексикой, чтоб интерпретатор был поменьше и мог оставить самой программе достаточно места в ограниченной по объему памяти) типа APL или BASIC, сейчас (кроме, разумеется, очень узкоспециального применения) почетное место разве что в старых учебниках, из которых эту самую классификацию, с достойным лучшего применения упорством, продолжают дословно переписывать в новые. При этом, почему-то, забывают уточнить, что эти два понятия уже давно не про сами языки, а всего лишь про некоторые методы их реализации, и что с тех пор помимо этих методов появилось еще много других хороших и разных концепций на эту тему (типа VM, JIT, сборщиков мусора, да и хотя бы тех же OOП, разных видов типизации и еще миллион чего), которых в тех учебниках еще просто не было в силу их года издания. И что на сегодня уже даже для языков, принципиально заточеных для компиляции под регистровую архитектуру, типа С, есть пруд пруди интерпретаторов (раз, два, три)... которые, опять же, никто не называет виртуальными машинами, т.к. это все суть разные понятия. Короче, это все равно что пытаться понять, где в квантовой механике огонь, вода, земля и воздух, в том виде, как их понимали Платон и Аристотель :)

P.S. Чтоб осознать, когда эта классификация еще была актуальна, рекомендую вот это . Там создатели APL, одного из первых настоящих интерпретируемых языков, обсуждают насущные проблемы языкостроения того времени. Если туго с английским, посмотрите хотя бы вступление... в тех железяках было меньше памяти и вычислительной мощности, чем в современной симке :)
Ответ написан
saboteur_kiev
@saboteur_kiev Куратор тега Программирование
software engineer
Виртуальная машина ява - на пальцах это плеер для проигрывания программ на языке ява.

В результате ты можешь запустить программу там, где стоит плеер - на телефоне, на линуксе, на винде. Конечно отдельные вещи нужно писать отдельно для разных платформ, но не пользуясь специфическим, можно писать кроссплатформенное приложение.
Плюс к этому. код выполняется внутри плеера и контролируется, что позволяет избегать выполнения непредусмотренных операций, аудит и разграничение прав доступа.
Плюс сам язык java написан так, чтобы исключить множество проблем при работе с памятью (ад для сишников). Потеря производительности при этом вполне устраивает для определенного рода программ, которые пока на рынке востребованы крайне широко
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@vilgeforce
Раздолбай и программист
Объяснить на пальцах суть работы микропроцессора предлагаете? Хороший вопрос, но нет. Погуглите про P-Code и JIT
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
NGRS Москва
от 250 000 до 350 000 ₽
REMONT.IO Москва
от 120 000 ₽
Kotelov Санкт-Петербург
от 150 000 до 200 000 ₽
23 июн. 2021, в 01:42
50000 руб./за проект
23 июн. 2021, в 00:13
100 руб./за проект