Виртуальная java. JVM (виртуальная машина Java). Настройка переменной среды

Может быть откомпилирован в байт-код Java, который затем может выполниться с помощью JVM.

JVM является ключевым компонентом платформы Java. Так как виртуальные машины Java доступны для многих аппаратных и программных платформ, Java может рассматриваться и как связующее программное обеспечение, и как самостоятельная платформа, отсюда принцип "написанное однажды, запускается везде" (write once, run anywhere). Использование одного байткода для многих платформ позволяет описать Java Как "скомпилированное однажды, запускается везде" (compile once, run anywhere).

Спецификация JVM

Противостояние Sun и IBM

В 2001 году, с целью разработки стандарта кросс-платформенных Desktop-приложений, Eclipse.

IBM VisualAge. IBM удалось сбалансировать интересы свободного сообщества и интересы бизнеса (свои интересы) в лицензии Eclipse Public License, признанной FSF .

Проект успешно развивается, признан индустрией, в значительной степени отделился от IBM в самостоятельную Eclipse Foundation .

Wikimedia Foundation . 2010 .

Смотреть что такое "Виртуальная машина Java" в других словарях:

виртуальная машина Java - Основная часть исполняющей системы Java (Java Runtime Environment; JRE). Виртуальная машина Java интерпретирует и исполняет Java байт код, предварительно созданный из исходного текста Java программы Java компилятором. JVM может использоваться для … - разработан компанией JavaSoft. Web приложения, созданные с его использованием, могут выполняться естественным образом внутри операционной системы, или браузера Web, или внутри эмулирующей среды, известной как виртуальная машина Java … Словарь электронного бизнеса

- (JPF) свободный инструмент для проверки многопоточных Java программ. По своей сути это виртуальная Java машина (англ. Java Virtual Machine) на основе которой реализованы методы проверки моделей (англ. model checking). Это означает, что… … Википедия

виртуальная Java-машина - Интерпретатор байт кода Java программ. Виртуальная машина, предназначенная для исполнения Java аплетов. JVM встроена в большинство веб браузеров. Это позволяет исполнять на стороне клиента Java аплеты, вызовы которых предусмотрены в… … Справочник технического переводчика

Иное название этого понятия «Ява»; см. также другие значения. Не следует путать с JavaScript. Java Класс языка … Википедия

Необходимо проверить качество перевода и привести статью в соответствие со стилистическими правилами Википедии. Вы можете помочь улучшить эту статью, исправив в ней ошибки. Оригинал н … Википедия

JVM является ключевым компонентом платформы Java. Виртуальная машина Java интерпретирует и исполняет Байт-код Java, предварительно созданный из исходного текста Java-программы компилятором Java (javac).

Так как виртуальные машины Java доступны для многих аппаратных и программных платформ, Java может рассматриваться и как связующее программное обеспечение, и как самостоятельная платформа, отсюда принцип «написано однажды, запускается везде» (write once, run anywhere). Использование одного байт-кода для многих платформ позволяет описать Java как «скомпилировано однажды, запускается везде» (compile once, run anywhere).

Программы, предназначенные для запуска на JVM должны быть скомпилированы в стандартизированном переносимом двоичном формате, который обычно представляется в виде файлов.class. Программа может состоять из множества классов, размещенных в различных файлах. Для облегчения размещения больших программ, часть файлов вида.class могут быть упакованы вместе в так называемый.jar файл (сокращение от Java Archive).

Виртуальная машина JVM исполняет файлы .class или .jar , эмулируя инструкции, написанные для JVM, путем интерпретирования или использования just-in-time компилятора (JIT), такого, как HotSpot от Sun microsystems. В наши дни JIT компиляция используется в большинстве JVM в целях достижения большей скорости. Существуют также ahead-of-time компиляторы, позволяющие разработчикам приложений прекомпилировать файлы классов в родной для конкретной платформы код.

JVM, которая является экземпляром JRE (Java Runtime Environment), вступает в действие при исполнении программ Java. После завершения исполнения, этот экземпляр удаляется сборщиком мусора. JIT является частью виртуальной машины Java, которая используется для ускорения времени выполнения приложений. JIT одновременно компилирует части байт-кода, которые имеют аналогичную функциональность, и, следовательно, уменьшает количество времени, необходимого для компиляции.

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

Среда выполнения метода содержит информацию, необходимую для динамического связывания, возврата из метода и обработки исключений. Код класса (размещенный в области класса) обращается к внешним методам и переменным, используя символические ссылки. Динамическая компоновка переводит символические ссылки в фактические. Среда выполнения содержит ссылки на таблицу символов метода, через которую производятся обращения к внешним методам и переменным.

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

Информация обработки исключений содержит ссылки на секции обработки исключений в методе класса.

Через среду выполнения также происходят обращения к данным, содержащимся в области класса, в том числе, к константам и к переменным класса.

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

Тут дали уже много хороших и правильных ответов, но хотелось бы уточнить, что вот эта метафора:

Виртуальня машина 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, одного из первых настоящих интерпретируемых языков, обсуждают насущные проблемы языкостроения того времени. Если туго с английским, посмотрите хотя бы вступление... в тех железяках было меньше памяти и вычислительной мощности, чем в современной симке:)

Дизайн JVM разрабатывался на основе многолетнего опыта программирования на таких языках как С и С++. Это позволило создать такую структуру JVM, которая сделала жизнь программиста значительно легче:

• код приложения выполняется в контейнере,
• в наличии защищённая среда выполнения программы,
• уменьшилась до минимума возможность управления памятью программистом,
• среду исполнения сделали кроссплатформенной,
• стала использоваться рантайм (во время выполнения программы) информация для самоуправления.

Последний аспект позволяет JVM принимать более оптимальные решения при выполнении программы, основываясь на том как часто вызываются некоторые её блоки. Собственно виртуальная машина интерпретирует байт код скомпилированной джава программы, однако в JVM существует возможность компилировать часто вызываемые блоки программы в машинный код в рантайме. Эта технология называется Jast-in-time (JIT). Это не значит что машинный код сохранится в файл программы, он будет существовать только во время её выполнения в оперативной памяти. Таким образом производительность джава программы, после нескольких циклов работы, может стать выше чем у аналогичных программ компилируемых языков C и C++.

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

Фактически байткод не очень похож на машинный код который будет запущен на реальном процессоре. Специалисты называют байткод промежуточным представлением, адаптацией между исходным кодом и машинным кодом.

Конечная цель байткода иметь такой формат представления данных и управляющей информации, что бы быть эффективно исполненным JVM.

Почему его назвали байткодом?
Код инструкции (opcode код операции) это только один байт (некоторые операции имеют параметры которые следуют за байтом операции в виде потока байт), таким образом существует только 256 вариантов инструкций. На практике некоторые не используются, остаётся примерно 200 используемых, но некоторые из них не были задействованы в последней версии javac.

Является ли компилятором javac?
Обычно компилятор создаёт машинный код, а javac создаёт байткод, непохожий на машинный код. Однако class файлы немного похожи на объектные файлы (как в Windows *.dll или Unix *.so) и являются нечитабельными.

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

Таким образом в чистом виде javac не компилятор, однако в большинстве книг и статей можно увидеть такие словосочетания - компилятор исходного кода или javac компилятор. А собственно компиляцией занимается JIT, когда создаёт машинный код для оптимизации выполнения программы.

Является ли байткод оптимизированным?
Ранние версии javac создавали сильно оптимизированный байткод. Это оказалось ошибочным. С появлением JIT компиляции более важным стало быстрое получение машинного кода. Поэтому оказалось, что нужно создавать такой байткод, который бы легко компилировался JIT. Поэтому сейчас имеется компромисс между оптимальностью байткода и быстротой его JIT компиляции. В свою очередь некоторая часть байткода продолжает оставаться интерпретируемой.

Является ли байткод действительно машинно независимым? Как на счёт порядка байт?
Формат байт кода всегда один и тот же, не важно на какой машине он был создан, это всегда big-endian (от старшего разряда к младшему). Например целое число занимающее в памяти 4 байта, хранится там побайтно от старших разрядов к младшим.

Является ли джава интерпретируемым языком?
По существу JVM это интерпретатор (с JIT компиляцией, которая даёт прирост производительности). Собственно исходный код джава не поступает интерпретатору на исполнение, он компилируется в байткод, а уже байт код интерпретируется JVM.

Могут ли другие языки выполнятся на JVM?
Всё что компилируется в байткод, может быть выполнено на JVM. Примеры таких языков - Scala, Clojure, Kotlin и т.д.
Кроме того, есть возможность реализовать интерпретатор некоторого языка на джава. Как это сделано, например, для языка JRuby.

Чтобы увидеть байт код, достаточно открыть файл.class в простом текстовом редакторе. Он окажется явно не читабельным. Однако у нас есть возможность дизассемблировать его в мнемоники байткода, то есть в элементарные команды (которые можно прочитать) и данные.

Рассмотрим простую программу складывающую два числа.

Public class Main { /** * Метод складывающий два числа. * @param a первое слагаемое * @param b второе слагаемое * @return результат сложения двух чисел. */ private static int adding(int a, int b) { return a + b; } /** * Точка входа в программу. * @param args неиспользуемые параметры командной строки. */ public static void main(String args) { // первое слагаемое int x = 43; // второе слагаемое int y = 56; // сложение значений двух переменных и помещение // результата в переменную. int result = adding(x, y); // вывод на экран значения переменной result. System.out.println(result); } }

Для удобства, можно создать пустой проект в Idea, и поместить этот класс в папку src.
Запустите его на исполнение. Idea скомпилирует его, естественно используя для этого javac, создаст файл Main.class и запустит его на исполнение. Проверим что у нас всё получилось, в консоли должна появится сумма чисел.

Затем перейдём в терминале в папку вашего проекта, а затем в папку где должен быть создан файл class. Это должно быть в папке out/production.

Для дизассемблирования запустите следующую команду, а в качестве параметра передайте скомпилированный класс:

Javap -c -p Main.class

С - дизассемблирование,
-p - вывод информации о всех членах класса.

В терминале мы должны получить следующее:

Public class org.dart.Main { public org.dart.Main(); Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."":()V 4: return private static int adding(int, int); Code: 0: iload_0 1: iload_1 2: iadd 3: ireturn public static void main(java.lang.String); Code: 0: bipush 43 // литерал числа присвоенный первой переменной 2: istore_1 3: bipush 56 // литерал числа присвоенный второй переменной 5: istore_2 6: iload_1 7: iload_2 8: invokestatic #2 // Method adding:(II)I 11: istore_3 12: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 15: iload_3 16: invokevirtual #4 // Method java/io/PrintStream.println:(I)V 19: return }

Здесь можно увидеть много интересного, даже код который мы явно сами не писали. Например метод:

Public org.dart.Main(); Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."":()V 4: return

Это не обычный метод, это конструктор. Он добавился автоматически при компиляции. Почему он добавляется это отдельная история.

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

Рассмотрим метод складывающий два числа, с помощью комментариев поясним смысл операций:

Private static int adding(int, int); Code: 0: iload_0 // загрузка первого целого числа из параметра в стек 1: iload_1 // загрузка второго целого числа из параметра в стек 2: iadd // сложение двух чисел из стека и помещение результата в стек 3: ireturn // возвращение целого числа из метода

В данном случае все операции занимают строго по одному байту.
Со списком операций можно познакомится по этой ссылке:
список инструкций Java байткода

Из набора таких операции и их параметров состоит любая программа скомпилированная javac. В свою очередь JVM, при запуске программы, начинает интерпретировать команды, превращая некоторые блоки программы в машинный код с помощью JIT технологии.

Для эксперимента, можно посмотреть какой код получится для разных операций с разными типами данных. Так же можно проверить сколько байт будет отдаваться под данные для чисел превышающих один байт, то есть больших чем 255.