Java Virtual Machine

Java Virtual Machine (скорочено Java VM, JVM) - віртуальна машина Java - основна частина виконуючою системи Java, так званої Java Runtime Environment ( JRE). Віртуальна машина Java інтерпретує Байт-код Java, попередньо створений з вихідного тексту Java-програми компілятором Java ( javac). JVM може також використовуватися для виконання програм, написаних на інших мовах програмування. Наприклад, вихідний код на мові Ada може бути откомпилирован в байт-код Java, який потім може виконатися за допомогою JVM.

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


1. Специфікація JVM

В 1996 -му році компанія Sun випустила першу версію документа "Блакитна книга JVM", в якому описана специфікація віртуальної машини Java, що став де-факто галузевим стандартом платформи Java. Завдяки цьому документу з'явилися альтернативні реалізації JVM, що є " розробками з чистого аркуша "( англ. clean room design ). В якості прикладу можна навести Kaffe.

Починаючи з версії J2SE 5.0 зміни в специфікації JVM виробляються у відповідності з формалізованими побажаннями зацікавлених сторін. Процес внесення змін до специфікації JVM називається Java Community Process.

JVM, доступна в вихідних текстах на Сі від фірми Sun називається KVM (Kilo Virtual Machine) і доступна на їхньому сайті.


2. Конкуренція між Sun і Microsoft

На початку розвитку платформи Java існували дві конкуруючі реалізації Java VM - одна від фірми Sun Microsystems, творця мови Java, для різних платформ ( Windows, Mac OS, Unix), і інша - від фірми Microsoft, орієнтована тільки на платформу Windows і, за твердженнями Microsoft, "спеціально оптимізована для швидкого виконання Java-коду на платформі Microsoft Windows".

Однак, Microsoft JVM була не повністю сумісна зі специфікацією, описаної Sun у блакитний книзі JVM, а також мала істотні проблеми з продуктивністю при роботі під великими навантаженнями (при великій кількості одночасно виконуваних потоків) і з безпекою. Компанія Sun порахувала таку ситуацію неприпустимою і вирішила, що Microsoft займається навмисної дискредитацією і профанацією платформи Java шляхом поширення своєї версії віртуальної машини Java, що володіє перерахованими вище недоліками. На цій підставі Sun неодноразово подавала до суду на Microsoft і домоглася спочатку того, що Microsoft втратила право називати свою реалізацію JVM Java VM. З цього моменту Microsoft стала називати свій продукт просто Microsoft VM. Потім Microsoft втратила право вбудовувати свою VM в браузери та операційні системи. Після цього Microsoft змушена була вилучити свою VM з постачання Windows і з пакету IE, але могла, згідно з рішенням суду, пропонувати її окремо для скачування на сайті. Потім Sun домоглася припинення розробки нових версій Microsoft VM і припинення випуску оновлень до неї, а потім і зняття Microsoft VM зі списку доступних для скачування програм на сайті Microsoft.

Деякі оглядачі комп'ютерних видань вважають, що жорстка позиція, зайнята Sun з питання Java, могла послужити додатковим стимулом для розробки компанією Microsoft власного Windows-платформного рішення - " . NET Framework ".


3. Розбіжності між Sun і IBM

У 2001 році, з метою розробки стандарту крос-платформних Desktop-додатків, IBM стартувала відкритий проект Eclipse.

Фреймворк Eclipse був заснований на попередній закритій розробці IBM VisualAge. IBM вдалося збалансувати інтереси вільного спільноти та інтереси бізнесу (свої інтереси) в ліцензії Eclipse Public License, визнаною організацією FSF.

Проект успішно розвивається, використовується в індустрії, в значній мірі відокремився від IBM в самостійний (див. Eclipse Foundation).

Sun залишається в опозиції до Eclipse Foundation, також як і Microsoft. Формально основною причиною протиріч залишається бібліотека SWT, яка суперечить Sun-концепції віртуальної машини і переносимості Java-додатків.


4. Середа виконання

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

Віртуальна машина JVM виконує файли. Class або. Jar, емуліруя інструкції, написані для JVM, шляхом інтерпретування або використання just-in-time компілятора ( JIT), такого, як HotSpot від Sun microsystems. У наші дні JIT компіляція використовується в більшості JVM в цілях досягнення більшої швидкості. Існують також ahead-of-time компілятори, що дозволяють розробникам додатків прекомпіліровать файли класів в рідній для конкретної платформи код.

Як і більшість віртуальних машин, Java Virtual Machine має stack-орієнтовану архітектуру, властиву мікроконтролерів і мікропроцесорів.

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