Я давно работаю с платформой Java и прекрасно знаю её сильные и слабые стороны. В этой статье я хочу рассказать, как могла бы повернуться история, если бы не бы. Ведь мы могли бы вместо докер-систем использовать ява-машину. А сама ява-машина вполне могла целиком заменить ОС.
Это обзорная статья, я лишь изложу несколько соображений. Полный их разбор занял бы очень много места.
Итак Ява-машина — это ОС. Даже круче чем ОС местами. На самом деле это не такое уж заявление из ряда вон. Ведь всем прекрасно известен пример полноценной ОС, значительно основанной (изначально) на Ява – Андроид. Кроме того, существуют и ОС в классическом понимании полностью на базе JVM.
Итак, какие признаки ОС мы имеем у JVM? Управление памятью - несомненно. Управление потоками - да, но как правило на базе существующих местных потоков базовой ОС. Тем не менее, потоки являются важной неотъемлемой и очень развитой подсистемой машины, предоставляя гораздо больше сервисных средств, чем базовые потоки ОС.
Ввод-вывод также очень развит, если иметь в виду всю инфраструктуру Ява, со всеми серверами и библиотеками. В этом смысле ввод-вывод базовой ОС - примерно как старый Биос для последней, осуществляет низкоуровневые операции.
У Ява есть философия. Если в Юникс - всё файл, то в Ява всё (почти) есть объект.
Есть важная часть системы, про которую многие либо не знают, либо забывают. Ява – среда с мощнейшими средствами разграничения доступа. Именно поэтому в том числе её широко применяют в банковской сфере.
Наличие этих средств вкупе с полноценной многопоточностью на уровне языка создаёт предпосылки для создания многозадачной И многопользовательской среды исполнения. Про многопоточность знают многие. Что касается разграничения доступа, остановимся подробнее.
Во-первых, JVM – управляемая (managed) среда. Это не только означает безопасность исполнения кода. Это также модель разграничения, аналогичная выделению ядра в большинстве ОС в отдельный контекст привилегированного исполнения. Т.н. нативный контекст исполнения, в котором работает сама машина - прямой аналог реального (или подобного) режима исполнения процессором ядра ОС. Сама машина имеет полный контроль над всеми процессами внутри неё. Байт-коду достаётся уже сильно ограниченная, защищённая среда. Степень свободы загружаемого байт-кода определяется Ява-машиной и её рантайм-библиотекой.
Более того, сам механизм загрузки байт-кода (классов в первую очередь) иерархичен и подразумевает разделение прав и ответственности – ветвление прав. Это ветвление достигается за счёт применения отдельных загрузчиков классов. При этом создаётся иерархия областей видимости, код, загруженный в одном контексте не имеет доступа к другому независимому контексту. При этом нельзя получить указатель на произвольную область памяти, нет доступа к произвольным полям объектов, даже через механизм рефлексии, даже к целым отдельным объектам. Этот механизм встроен в язык (ключевые слова private, protected и т.п.) и в платформу – уже названные загрузчики и конечно менеджеры безопасности, о которых тоже не забудем. Такие механизмы обеспечивают разделение контекстов выполнения аналогично процессам классических ОС. Я бы даже сказал более строгое и надёжное разделение. Загрузчики классов совместно с менеджерами безопасности (SecurityManager) обеспечивают полный контроль над тем, что может попасть внутрь среды исполнения Ява, а что не может. Механизм этот необычайно гибкий. При этом, в отличие от нативного кода, загружаемый байт-код проходит полную проверку на валидность (он не может затем вызвать непредсказуемый сбой) и безопасность - так как возможные варианты поведения ограничены теми же загрузчиком+менеджером безопасности. Вы слышали когда-нибудь о вирусах на Яве?
Для больших систем вышеописанный механизм хорошо согласуется с модульностью и плагинным подходом. При этом, как я уже сказал, эта плагинная система значительно защищённее аналогов, т.к. плагины могут вести себя как отдельные приложения. Яркий пример - OSGi.
Здесь стоит отметить, что все вышеуказанные черты существуют в рамках всего одного процесса. Это позволяет не использовать сложные, рискованные и дорогие механизмы межпроцессного взаимодействия. С другой стороны есть один из главных недостатков ява-машины, до последнего времени неслабо портивший бочку мёда – большая общая куча со сборкой мусора. Но новое поколение сборщиков почти полностью устранило этот недостаток, позволяя запускать Ява машины с кучей в десятки гигабайт.
Круче чем кубер
Почему Ява-машина круче чем кубер? Потому что, как я уже сказал, она позволяет создавать множество независимых изолированных контекстов – читай пространств имён – на базе общего ядра Ява-машины и рантайм-библиотеки. И эти пространства могут настраиваться более гибко, обеспечивая различные уровни изоляции (доступа). Они могут дополнительно компоноваться. Отличным примером этого являются мощные сервера приложений. Они предлагают всё то, что обещает нам докер и его оркестраторы – отказоустойчивость, балансировка нагрузки, отличная модульность (суть микросервисности), сервисы и веб сервисы и даже самые микро и нано-модули – лямбды в виде супер легковесных ejb, решение проблем совместимости версий библиотек, удалённый вызов процедур в качестве альтернативы protoBuf & gRPC – RMI и его развития Corba & RMI-IIOP. И это всё в виде стандартов и множества реализаций.
Единственное, чего не хватает - красивых картинок и графиков (хотя тут от реализации зависит) и развёртывания инфраструктуры из нарисованной диаграммки. Но последнее и в коробку с Кубером никто бесплатно не положит.
И для иллюстрации посмотрим на стандартную модульность сервера приложений. Есть иерархия загрузки: система -> сервер -> приложение -> модуль приложения.
Что ж, на этом пока всё. Порадуемся выходу очередной версии Jakarta EE 9 и пожелаем им успехов.