Экспертиза
Тестовый центр анализирует работу виртуальных машин Java
Питер Коффи (PC Week Labs)
Построить платформу для исполнения приложений, реализующую все обещанные достоинства Java, невероятно трудно.
Приступая к экспертизе какого-либо Java-приложения, мы, специалисты Тестового центра PC Week Labs, ожидаем увидеть удачное сочетание эффективного использования системных ресурсов, производительности при решении задач, требующих большого объема вычислений, безопасности исполнения кода, поступившего из источников с недостаточным уровнем доверия, и совместимости с постоянно меняющимися различными спецификациями Java.
Добиться согласованности этих факторов гораздо проще, если рассматривать Java лишь как еще один язык программирования, а не навязывать ему роль универсального межплатформного решения. Многие разработчики интересуются именно языком Java как таковым - их привлекают чистота и законченность его объектной ориентации, а также автоматизация таких критичных задач (которые нередко решаются с ошибками), как управление памятью.
Однако именно обещание абсолютной мобильности - “написано единожды, выполняется везде” - обеспечило Java невероятно быстрый успех, ранее не достигнутый ни одним языком программирования. Достижение этой цели зависит от наличия универсального механизма, способного безопасно и эффективно исполнить представленную в единообразном и четком виде программу на “информационных приборах” самого разного вида - от мощных серверов до бытовых электронных устройств.
Этот механизм, определяемый в виде набора кодов команд и соглашений о средствах хранения данных, может быть реализован как аппаратно, так и программно. В обоих случаях он называется виртуальной машиной Java (JVM, Java Virtual Machine).
Очень важно четко различать обещания, которые относятся к языку Java (производительность труда программиста и простота разработки) от тех, которые относятся к виртуальной машине (переносимость, безопасность и производительность выполнения приложений).
Создатели конкурирующих реализаций JVM добились успеха в разной степени (см. диаграмму эталонных тестов на рисунке).
Межплатформные ограничения
Когда Java используется в качестве инструмента межплатформных вычислений, написанный программистом Java-текст не компилируется в двоичные коды инструкций, распознаваемых и исполняемых арифметическим и логическим модулями процессора. Вместо этого операторы Java транслируются в файл Java-класса. Этот файл содержит некий поток байтов, называемых байт-кодами, предназначенный для обработки на этапе исполнения некой промежуточной программой, а именно JVM.
JVM может быть реализована аппаратно, в виде микросхемы, и IBM недавно лицензировала технологию фирмы Sun Microsystems, позволяющую решать именно эту задачу. Однако гораздо важнее то, насколько легко создать JVM для какого-либо “реального” типа компьютера.
Файлы байт-кодов Java могут исполняться на компьютере определенного типа только тогда, когда для него напишут его собственную версию JVM. Поток байт-кодов можно считывать из файла класса и преобразовывать в команды хост-машины точно так же, как файл электронной таблицы может быть загружен и пересчитан как на PC, так и на компьютере Macintosh.
Это, однако, накладывает на столь часто повторяемый принцип - “написано единожды, выполняется везде” - первое ограничение. Теперь его следует понимать как “написано единожды, выполняется везде, где есть реализация JVM”. Любое обещание эффективности, безопасности или других возможностей Java следует рассматривать через призму ограничений, присущих конкретной версии JVM.
Пользователи, запускающие приложения, которые выполняют большой объем вычислений, могут пожелать, чтобы JVM анализировала и оптимизировала код для достижения максимальной производительности - даже если такой режим компиляции (называемый just-in-time, JIT) увеличивает время запуска программы. Пользователи, работающие только с небольшими аплетами, естественно, хотят, чтобы те стартовали максимально быстро, так как глубокая оптимизация просто заставит несложный аплет больше времени тратить на ожидание реакции пользователя.
Вешаем Java-картинки на разные стены
Помимо программы JVM, на системе, где выполняется Java-программа, должен быть установлен набор файлов классов, которые в совокупности называются интерфейсом прикладного программирования (API) Java. И это, так сказать, “слабое звено” в основании Java. Классы API универсального ГИП, называемого Abstract Windowing Toolkit (AWT), представляют собой переносимый интерфейсный слой, требующий обращений к родному коду.
Когда Java-программе нужно, например, разместить на экране кнопку, программист может писать платформно-независимые операторы для создания и отображения этой кнопки - но, чтобы это стало реальностью, классы, “лежащие глубоко в основании”, используют скрытые связи с ОС хост-машины.
“Родные” средства заставляют Java-аплеты выглядеть привычно для их пользователей. При работе под Windows кнопки похожи на Windows-кнопки. На Macintosh они же выглядят, как типичные кнопки Mac. Внешний вид и поведение графических Java-приложений при выполнении на разных платформах становятся такими же, как у “родных” приложений этих платформ.
И тем не менее заявленный Java принцип ограничивается еще больше - теперь он звучит так: “Написано единожды, выполняется везде, где есть JVM и полный комплект классов API”.
Средства обеспечения безопасности не всегда переносимы
Наконец, исключительно на JVM возлагается выполнение динамических, многопотоковых приложений таким образом, чтобы обеспечить знаменитые гарантии безопасности Java.
JVM должна выполнять этап верификации байт-кода, который защищает Java-аплеты от наиболее распространенных последовательностей действий, применяемых при нападении зловредного ПО.
JVM также должна как-то управляться с потоком байт-кодов, не соответствующим гарантиям, предоставляемым языком Java. Некоторые из мер безопасности языка в таких условиях становятся невыполнимыми, хотя JVM может обеспечивать собственную дополнительную защиту на более глубоком уровне.
Из-за этих проблем крайне трудно решить сверхзадачу Java - обеспечить высокую степень защиты, большую производительность и эффективное использование системных ресурсов, одновременно предоставив пользователям всю мощь возможностей самого языка.
Испытания AWT на тестах JMark 2.0 демонстрируют лидерство IE for Windows среди оцениваемых JVM
Дополнительная информация о тестировании имеется на Web-узле журнала PC Magazine по адресу: www.zdnet.com/pcmag/features/java98/290325.html.
Источник: Тестовый центр PC Magazine Labs.
