5.03. История Java

ДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ

Разработчику Архитектору

История Java

В наше время, при знакомстве с большинством языков программирования, мы принимаем их как объектно-ориентированными, безопасными, высокоуровневыми и мультиплатформенными.

Сейчас можно большинство программ написать на почти любом языке и запустить где угодно, добавить классы, объекты, а также использовать качественную и безопасную систему управления памятью. Однако, так было не всегда - поначалу программирование подразумевало ручное управление памятью, профильность под определённые операционные системы и платформы, и работу на низком уровне.

Как раз Java можно считать одним из крупнейших по значимости языков, которые подарили нам современное состояние.

1. Предпосылки возникновения

К началу 1990-х годов доминирующими языками системного и прикладного программирования оставались C и C++.

Си обеспечивал близкую к железу производительность при высокой переносимости на уровне исходного кода; C++ — выразительную объектно-ориентированную модель, но ценой усложнённой семантики (множественное наследование, перегрузка операторов, ручное управление памятью) и фрагментации компиляторов.

В то же время наблюдался быстрый рост числа аппаратных платформ, от серверов SPARC и x86 до встраиваемых процессоров, бытовой электроники и прототипов интерактивных телевизионных приставок.

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

Одновременно назревал кризис в области безопасности. C и C++ изначально предполагали доверие к разработчику: возможность прямой адресной арифметики, отсутствие границ проверок массивов и неограниченный доступ к памяти делали программы уязвимыми к целому классу ошибок — buffer overflows, use-after-free, double-free. Эти уязвимости становились всё более критичными по мере роста сетевого взаимодействия устройств.

*Прямая адресная арифметика представляет собой возможность выполнять математические операции непосредственно над адресами памяти. Разработчик работает с указателями как с числовыми значениями, увеличивая или уменьшая их для перехода к соседним участкам памяти.

Адресная арифметика устроена вокруг базового типа данных — указателя. При добавлении целого числа к указателю компилятор автоматически умножает это число на размер типа, на который указывает указатель. Например, приращение указателя на целое число на четыре байта перемещает адрес вперёд на четыре байта, а приращение указателя на структуру размером 24 байта перемещает адрес на 24 байта. Такой подход позволяет эффективно обходить массивы и структуры данных, но требует от разработчика точного понимания расположения объектов в памяти. Ошибки в расчётах приводят к обращению к чужим участкам памяти без предупреждения со стороны системы.

Проверка границ массивов — это механизм контроля выхода индекса за пределы выделенного участка памяти при обращении к элементам массива. Система сравнивает запрашиваемый индекс с допустимым диапазоном и блокирует операцию при нарушении границ.

Механизм устроен как дополнительная инструкция, выполняемая перед каждым обращением к элементу массива. Среда выполнения или компилятор вставляет проверку: индекс должен быть не меньше нуля и строго меньше длины массива. При соблюдении условий происходит нормальное чтение или запись данных. При нарушении условий система прерывает выполнение программы или генерирует исключение. Языки с автоматической проверкой границ вставляют эти инструкции на этапе компиляции или интерпретации, что повышает безопасность ценой небольшого замедления работы.

Доступ к памяти — это операция чтения или записи данных по конкретному адресу в адресном пространстве процесса. Программа взаимодействует с оперативной памятью через загрузку значений из ячеек или сохранение значений в ячейки по расчётным или явно заданным адресам.

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

Buffer overflow — это состояние, возникающее при записи данных в буфер за пределами его выделенного размера. Избыточные данные переписывают смежные участки памяти, нарушая целостность структур данных или служебной информации.

Уязвимость устроена вокруг фиксированного участка памяти, выделенного под буфер. При копировании данных без проверки их длины содержимое выходит за границы буфера. Переписанные данные могут затронуть локальные переменные, параметры функции или служебные поля стека, включая адрес возврата. Злоумышленник подбирает входные данные так, чтобы переписать адрес возврата на свой код, размещённый в том же буфере или в другом контролируемом участке памяти. После завершения функции процессор передаёт управление по подменённому адресу, выполняя произвольный код в контексте уязвимой программы. Такой сценарий превращает ошибку программиста в точку входа для атаки.

Use-after-free — это обращение к участку памяти после его освобождения. Программа продолжает использовать указатель на объект, память которого уже возвращена системе управления памятью.

Механизм уязвимости устроен вокруг жизненного цикла динамически выделенного объекта. После вызова функции освобождения памяти участок становится доступным для повторного выделения. Указатель на этот участок сохраняется в программе, но его использование становится неопределённым. При повторном выделении памяти система может назначить тот же адрес новому объекту. Операции через старый указатель изменяют данные нового объекта, приводя к нарушению логики программы. Злоумышленник контролирует содержимое нового объекта, размещая в нём данные, интерпретируемые как код или критические параметры. Последующее использование старого указателя приводит к выполнению произвольных действий в контексте программы.

Double-free — это повторное освобождение одного и того же участка памяти без промежуточного выделения. Программа дважды вызывает функцию освобождения для одного указателя.

Уязвимость устроена вокруг внутренней структуры менеджера памяти. При первом освобождении участок добавляется во внутренний список свободных блоков. При повторном освобождении менеджер пытается добавить тот же адрес во второй раз, нарушая целостность списка. Это приводит к повреждению служебных структур управления памятью — связанных списков, деревьев или таблиц метаданных. Повреждённые структуры вызывают непредсказуемое поведение при последующих операциях выделения или освобождения. Злоумышленник использует последовательность выделений и освобождений для управления расположением объектов в памяти, создавая условия, при которых повреждение структур приводит к перезаписи критических указателей. Такая перезапись позволяет перенаправить выполнение программы на контролируемый злоумышленником код.

Всё это критично для корпораций, особенно в сфере финансов. Они требовали улучшения безопасности.

Именно в этом контексте в 1991 году в компании Sun Microsystems была запущена исследовательская инициатива под кодовым названием Green Project. Её официальной целью было создание программной платформы для «умной бытовой техники» — телевизоров, кофеварок, пультов управления, — но неявной, гораздо более амбициозной задачей стало выявление новых принципов построения языков и сред исполнения в условиях неопределённости платформы и повышенных требований к надёжности.

2. Green Project и рождение Oak

Green Project — исследовательская инициатива компании Sun Microsystems, начатая в 1991 году с целью создания программной платформы для нового поколения цифровых устройств. Проект ставил задачу разработать язык программирования и среду выполнения, способные работать на ограниченных по ресурсам устройствах: пейджерах, телевизионных приставках, портативных терминалах и других электронных гаджетах, которые прогнозировались как массовые в ближайшем будущем.

Проект устроен как междисциплинарная команда инженеров под кодовым названием «Green Team». Команда функционировала автономно от основных продуктовых направлений Sun, что позволяло экспериментировать с архитектурными решениями без привязки к существующим корпоративным стандартам. Основные компоненты проекта включали разработку нового языка программирования, создание виртуальной машины для кроссплатформенного выполнения, проектирование графической подсистемы для устройств с дисплеями и построение сетевого стека для взаимодействия устройств между собой. Green Project заложил основы архитектуры, которая позже трансформировалась в платформу Java после переориентации на веб-технологии.

Проект возглавил Джеймс Гослинг, чьи предыдущие работы в Sun (включая разработку Emacs-подобного редактора Gosling Emacs на C и создание оконной системы NeWS) давали ему уникальное понимание баланса между выразительностью, портируемостью и производительностью.

Gosling — фамилия Джеймса Гослинга, канадского программиста и системного архитектора, возглавившего разработку языка Oak, ставшего предшественником Java. Гослинг обладал глубоким опытом в создании языков программирования и системного программного обеспечения до начала работы над проектом Green.

Его профессиональный путь устроен через серию значимых технических достижений. Гослинг разработал первый вариант редактора Gosling Emacs, написанный на языке C с расширениями на собственном интерпретируемом языке Mocklisp. Он создал оконную систему NeWS, основанную на интерпретации языка PostScript на стороне сервера дисплея. Эти проекты сформировали его подход к проектированию языков: баланс между выразительностью синтаксиса, предсказуемостью выполнения и возможностью абстрагирования от аппаратных деталей. В рамках Green Project Гослинг выступил как главный архитектор языка, определивший ключевые принципы: отказ от опасных низкоуровневых конструкций, введение автоматического управления памятью и создание единой объектной модели.

Emacs — семейство расширяемых текстовых редакторов с архитектурой, построенной вокруг встроенного интерпретатора языка программирования. Emacs функционирует не только как инструмент редактирования текста, но и как платформа для создания специализированных приложений: почтовых клиентов, отладчиков, календарей и систем управления проектами.

Архитектура Emacs устроена по принципу «редактор как операционная система». Ядро редактора предоставляет базовые примитивы: управление буферами, окнами, точкой вставки и клавиатурными привязками. Все высокоуровневые функции реализованы на встроенном языке расширений — изначально Mocklisp в Gosling Emacs, позже Emacs Lisp в GNU Emacs. Расширения загружаются динамически, перехватывают события ввода, модифицируют поведение ядра и создают новые интерфейсы поверх текстового буфера. Такая организация позволяет адаптировать редактор под любую предметную область без изменения исходного кода ядра. Модель выполнения основана на интерпретации байт-кода Lisp, что обеспечивает переносимость расширений между разными платформами.

NeWS — сетевая расширяемая оконная система, разработанная Джеймсом Гослингом в Sun Microsystems в середине 1980-х годов. Система предназначалась для организации графического интерфейса на устройствах с ограниченными вычислительными ресурсами, передавая логику отрисовки на сторону сервера дисплея.

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

Архитектура оконной системы устроена по клиент-серверной модели. Сервер оконного менеджера владеет прямым доступом к видеопамяти и аппаратным ресурсам отображения. Клиентские приложения подключаются к серверу через межпроцессное взаимодействие и отправляют запросы на создание окон, отрисовку содержимого и получение событий ввода. Сервер выполняет композитинг: определяет видимые части каждого окна с учётом порядка наложения, пересылок и прозрачности, затем формирует финальное изображение кадра. Оконная система предоставляет абстракцию поверх аппаратных различий видеокарт, позволяя приложениям работать с единым интерфейсом независимо от конкретной реализации драйверов. Дополнительные компоненты включают менеджер окон для управления расположением и оформлением, а также подсистему обработки событий клавиатуры и указателя.

NeWS устроена вокруг интерпретатора языка PostScript, встроенного непосредственно в прошивку дисплейного процессора. Клиентское приложение отправляет серверу не набор низкоуровневых команд отрисовки, а фрагменты программного кода на диалекте PostScript. Сервер выполняет этот код локально, используя собственные вычислительные ресурсы для генерации изображения. Такой подход снижает сетевой трафик и нагрузку на клиентское устройство. Система поддерживает концепцию «умных окон»: каждое окно содержит собственный обработчик событий, написанный на PostScript, который реагирует на действия пользователя без обращения к клиенту. Несмотря на техническую изящность, NeWS уступила место более простой модели X Window System из-за сложности отладки распределённой логики и высоких требований к аппаратной поддержке PostScript.

Изначально команда рассматривала C++ как основу, однако быстро обнаружила, что даже "чистый" C++ не позволяет достичь требуемых целей:

Фрагментация компиляторов делала невозможным гарантировать одинаковое поведение кода на разных устройствах;
Отсутствие встроенной безопасности требовало написания специализированных статических анализаторов и рантайм-обёрток;
Сложность модели памяти и ручное управление ресурсами создавали высокий барьер входа для разработчиков встраиваемых систем, где часто не было опыта системного программирования.

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

В результате был создан собственный язык — Oak («дуб»), названный в честь дерева, росшего за окном офиса Гослинга. Oak представлял собой гибридную попытку: сохранить C-подобный синтаксис (чтобы упростить переход для существующих разработчиков), но радикально упростить модель времени выполнения.

C-подобный синтаксис — стилевая конвенция построения языков программирования, заимствующая ключевые элементы грамматики языка C: структуру операторов, правила объявления переменных, приоритет операций и формат управляющих конструкций.

Архитектура C-подобного синтаксиса устроена вокруг нескольких базовых паттернов. Блоки кода ограничиваются фигурными скобками {}, что позволяет группировать операторы без привязки к отступам. Условные конструкции и циклы используют ключевые слова if, else, for, while с обязательными круглыми скобками вокруг условия и фигурными скобками вокруг тела. Объявление переменной следует шаблону «тип имя», где тип предшествует имени переменной. Операторы выражений завершаются точкой с запятой ; независимо от контекста. Арифметические и логические операции сохраняют приоритет и ассоциативность, принятые в C: умножение выполняется раньше сложения, логическое И раньше логического ИЛИ. Такая организация снижает когнитивную нагрузку на разработчиков, имеющих опыт работы с C, C++ или другими представителями семейства, позволяя быстро освоить новый язык без изучения принципиально иной грамматической структуры.

Ключевые архитектурные решения Oak:

Отказ от препроцессора. Макросы в C позволяли создавать «доменные языки», но вносили неопределённость в отладку и статический анализ.
Механизм сборки мусора с поколениями (generational GC), адаптированный под ограничения памяти встраиваемых систем. Это исключало необходимость явного вызова free() и делало программы более детерминированными в плане утечек.
Модель памяти с проверкой границ. Каждый доступ к массиву сопровождался неявной проверкой индекса; при нарушении генерировалось исключение, а не произвольная порча памяти.
Первый вариант виртуальной машины, названный Oak VM. В отличие от современной JVM, она изначально компилировала байт-код в интерпретируемом и в нативном режиме (с прямой генерацией машинного кода), что было важно для устройств без ресурсов под интерпретацию.

Препроцессор — инструмент обработки исходного кода на этапе, предшествующем компиляции. Препроцессор преобразует текст программы по заданным правилам: заменяет макросы, включает содержимое внешних файлов, условно исключает фрагменты кода.

Детерминированность — свойство системы или алгоритма, при котором одинаковые входные данные всегда приводят к одинаковому результату выполнения за предсказуемое время. Детерминированное поведение позволяет точно воспроизводить сценарии работы программы и строить формальные доказательства корректности.

Проверка индекса — контрольная операция, выполняемая перед обращением к элементу массива или коллекции для подтверждения принадлежности индекса допустимому диапазону. Проверка предотвращает обращение к памяти за пределами выделенного буфера.

Тем не менее, коммерциализация Oak провалилась: рынок «умных» бытовых устройств в середине 1990-х не сформировался, а лицензионные ограничения на название Oak (существовала компания Oak Technology) вынудили к переименованию.

3. Переход к Java

В 1994–1995 годах в команде произошло осознание: хотя встраиваемые устройства не оправдали ожиданий, набирающая обороты технология World Wide Web нуждалась в интерактивных элементах, которые HTML 2.0 предоставить не мог. Браузеры тогда были статичными; плагины (например, для проигрывания видео) требовали установки, обладали низкой переносимостью и угрожали стабильности системы.

Команда Green Project перенастроила свои усилия: Oak был переработан под задачу «динамического контента в браузере». Новый язык получил название Java — нейтральное, запоминающееся, ассоциирующееся с энергией (кофеин), но не привязанное к технической семантике.

Термин Java изначально относился к платформе в целом — включая язык, виртуальную машину, библиотеки и среду исполнения. Это принципиальное отличие от C/C++, где язык и среда чётко разделены.

3.1. Философия «Write Once, Run Anywhere»

Принцип WORA часто неверно трактуется как свойство языка. На деле он — следствие трёхуровневой архитектуры:

Компилятор (javac) → генерирует байт-код (.class-файлы) — промежуточное представление, не зависящее от архитектуры процессора.
Java Virtual Machine (JVM) → абстрактная машина со стековой архитектурой, определяющая:
- формат класс-файлов,
- набор инструкций (около 200 опкодов, большинство — загрузка/сохранение, арифметика, вызовы, управление потоком),
- модель памяти (метод-область, куча, стек потока),
- механизм загрузки классов (class loading),
- систему безопасности (bytecode verifier, security manager).
Реализация JVM под конкретную ОС/архитектуру (HotSpot от Sun/Oracle, OpenJ9 от IBM, GraalVM и др.) — преобразует байт-код в машинный код либо интерпретацией, либо JIT-компиляцией, либо AOT-компиляцией (в новых версиях).

Таким образом, переносимость обеспечивается стандартизацией промежуточного слоя, а не языковых конструкций. Это позволило сохранить статическую типизацию и компиляцию до выполнения (в отличие от, скажем, Python), но избежать привязки к ISA.

3.2. Безопасность

Апплеты (мини-приложения, встраиваемые в HTML через <applet>) должны были запускаться на клиентской машине без ведома пользователя и без привилегий. Поэтому архитектура безопасности была заложена глубоко в JVM:

Bytecode verifier — статический анализатор, проверяющий байт-код до загрузки в JVM на соответствие контрактам: корректность стека, типобезопасность, отсутствие запрещённых инструкций (напр., jsr в определённых контекстах).
Security manager — динамический контроллер, отвечающий за проверку разрешений во время выполнения (доступ к файлу, сокету, системным свойствам). Политики задавались внешними файлами (java.policy).
Песочница (sandbox) — набор ограничений по умолчанию для неподписанных апплетов: запрет на запись в файловую систему, запрет на подключение к сторонним хостам (кроме домена, с которого загружен апплет), запрет на вызов System.exit().

Эти механизмы сделали Java одной из первых платформ, где безопасность рассматривалась как свойство среды исполнения, а не ответственность разработчика.

4. Java 1.0 (1996)

Релиз состоялся 23 января 1996 года. Пакет дистрибутива включал:

Компилятор javac,
Интерпретатор java,
Дебаггер jdb,
Библиотеку классов (около 210 классов в 8 пакетах: java.lang, java.io, java.util, java.net, java.awt, java.applet, java.awt.image, java.awt.peer),
Applet Viewer — автономную среду для тестирования апплетов без браузера.

Синтаксически Java 1.0 была уже близка к современному виду, но с рядом ограничений:

Отсутствие ключевого слова strictfp (добавлено в 1.2),
Нет коллекций — вместо List, Map использовались Vector, Hashtable, Stack (все синхронизированы по умолчанию),
Интерфейсы не могли содержать константы (хотя технически static final поля были разрешены, их использование считалось антипаттерном),
Исключения — только Throwable, Exception, RuntimeException, Error; собственная иерархия ошибок почти отсутствовала.

Особое внимание уделялось модель многопоточности: Java стала первым массовым языком, где потоки (Thread) были встроенными в язык (ключевое слово synchronized, методы wait()/notify() в Object). Это предвосхитило эпоху многопроцессорных систем и сетевых серверов.

5. Java 1.1 (1997)

Релиз 18 февраля 1997 года стал первым крупным обновлением. Здесь были устранены наиболее критичные ограничения 1.0:

Внутренние классы — позволили реализовывать замыкания (до появления лямбд) и удобные шаблоны (например, ActionListener как анонимный класс). Важно: внутренний класс не является просто синтаксическим сахаром — он порождает отдельный .class-файл и сохраняет неявную ссылку на экземпляр внешнего класса (this$0).
Рефлексия (java.lang.reflect) — механизм интроспекции типов во время выполнения. Впервые стала возможна загрузка классов по имени (Class.forName()), получение метаданных, вызов методов динамически. Это заложило основу для фреймворков (Spring, Hibernate), построенных на внедрении зависимостей и маппинге.
Сериализация — стандартный механизм преобразования объектов в поток байтов (Serializable), с возможностью кастомизации (readObject/writeObject). Хотя сегодня её считают устаревшей (из-за проблем безопасности и версионирования), в 1997 году это был прорыв для RMI и сохранения состояния.
RMI (Remote Method Invocation) — первая встроенная поддержка распределённых вычислений: вызов методов на удалённых объектах как локальных. Основан на сериализации и динамической загрузке классов.
Улучшенная AWT — новая событийная модель (delegation event model), заменившая унаследованную от C++ «модель наследования», где переопределялись методы вроде action().

Java 1.1 стала первой версией, в которой язык начал использоваться для реальных enterprise-проектов, несмотря на отсутствие официальной «Enterprise Edition». Многие паттерны, позже ставшие классическими (DAO, Factory, Observer в виде PropertyChangeListener), были реализованы именно на базе 1.1.

6. Java 1.2 и Java 2 Platform (1998–2000)

Выпуск Java 1.2 в декабре 1998 года ознаменовал стратегическую реконфигурацию всей платформы. Sun Microsystems официально представила концепцию Java 2 Platform, разделив экосистему на три независимые, но совместимые редакции:

J2SE (Java 2 Standard Edition) — целевая платформа для настольных и серверных приложений среднего масштаба;
J2EE (Java 2 Enterprise Edition) — надстройка над J2SE для распределённых, многопользовательских систем с требованиями к надёжности, масштабируемости и транзакционной целостности;
J2ME (Java 2 Micro Edition) — облегчённая версия для устройств с ограниченными ресурсами: сотовых телефонов, пейджеров, карманных ПК.

Такое разделение позволило избежать «раздувания» ядра: J2SE оставалась относительно компактной, в то время как J2EE и J2ME развивались автономно, адаптируясь к специфике своих доменов. Это также легитимизировало Java как универсальную технологию — от микроконтроллеров до мэйнфреймов.

6.1. Технические вехи Java 1.2

Система пакетов и JAR-файлов. Хотя пакеты существовали с 1.0, именно в 1.2 была стандартизирована иерархия java.*, javax.*, а также введён формат JAR (Java ARchive) — ZIP-контейнер с метаданными (META-INF/MANIFEST.MF), позволяющий упаковывать классы, ресурсы и зависимости в единый артефакт. Это стало критически важным для распространения библиотек и апплетов.
Swing — замена AWT. Абстрактная оконная библиотека Swing (javax.swing) была построена целиком на Java, без нативных вызовов («lightweight» компоненты), что обеспечило кросс-платформенную согласованность внешнего вида и поведения. Архитектура MVC (Model-View-Controller) была явно выделена: например, JTable разделяла модель данных (TableModel), отображение (TableCellRenderer) и обработку событий. Swing также представил Pluggable Look-and-Feel (PLAF) — механизм динамической смены оформления без перекомпиляции.
Just-In-Time (JIT) компиляция в HotSpot. Первая реализация HotSpot JVM (первоначально разработанная компанией Longview Technologies, приобретённой Sun в 1997) включала адаптивный JIT-компилятор, который анализировал профиль выполнения и оптимизировал «горячие» участки кода во время работы. В отличие от простых JIT-ов, HotSpot использовал интерпретацию на старте и отложенную компиляцию, что позволяло собрать статистику вызовов, типов аргументов и ветвлений — и на её основе применять агрессивные оптимизации: inlining, escape analysis, loop unrolling. Это сократило разрыв в производительности с нативными приложениями с 10–20× до 1.5–3×, сделав Java приемлемой для высоконагруженных серверов.
Коллекции (Collections Framework). Введённый в java.util фреймворк (List, Set, Map, Iterator) стандартизировал операции над структурами данных. Ключевым решением стало разделение интерфейсов и реализаций (ArrayList vs LinkedList, HashMap vs TreeMap), а также введение fail-fast итераторов, которые детектировали модификацию коллекции во время обхода и выбрасывали ConcurrentModificationException. Это значительно повысило предсказуемость поведения и облегчило отладку.
Управление памятью: Soft, Weak, Phantom References. Помимо StrongReference (обычное удержание объекта), появились классы SoftReference, WeakReference, PhantomReference, позволяющие тонко регулировать взаимодействие с GC. Например, WeakHashMap использует WeakReference для ключей — запись автоматически исчезает, когда ключ становится недостижимым, что идеально подходит для кешей.

6.2. J2EE

Хотя J2EE 1.2 вышел лишь в декабре 1999 года, его основные спецификации — EJB (Enterprise JavaBeans), JDBC (Java Database Connectivity), JNDI (Java Naming and Directory Interface), JMS (Java Message Service) — были объявлены ещё в рамках Java 1.2. Эти API заложили фундамент контейнерной архитектуры:

EJB — компонентная модель, где бизнес-логика инкапсулировалась в бины (Session Beans, Entity Beans), управляемые контейнером. Контейнер брал на себя: транзакции (@TransactionAttribute), безопасность (@RolesAllowed), пул потоков, пассивацию/активацию. Это был ответ на рост сложности распределённых систем, где разработчики тратили больше времени на инфраструктурные задачи, чем на бизнес-логику.
JDBC — унифицированный интерфейс к реляционным СУБД. В отличие от ODBC (C-based), JDBC был чисто Java, с чёткими уровнями изоляции транзакций (READ_COMMITTED, REPEATABLE_READ и т.д.) и параметризованными запросами, защищающими от SQL-инъекций. Драйверы реализовывались как JAR-файлы, подключаемые динамически через Class.forName().
JNDI — служба имён, позволяющая регистрировать и извлекать ресурсы (пулы соединений, EJB, очереди JMS) по логическим именам, а не хардкодить физические адреса. Это обеспечивало конфигурируемость без перекомпиляции.

На практике J2EE стал синонимом «тяжеловесной» архитектуры: разработка требовала генерации десятков XML-описаний (ejb-jar.xml, web.xml), разворачивания в application server (WebLogic, WebSphere), и сопровождалась значительным overhead’ом. Тем не менее, именно J2EE стандартизировал индустрию: появилось понятие Java-разработчика enterprise-уровня, а рынок серверов вырос многократно.

7. Эпоха Java 5 (J2SE 5.0, 2004)

После относительно скромных обновлений в Java 1.3 (2000) и 1.4 (2002) — в основном, расширение библиотек (java.nio, регулярные выражения, логгинг) и улучшение GC — релиз Java 5.0 (внутренний номер 1.5, но маркетингово — «5») стал крупнейшей эволюцией языка с момента 1.0. Sun осознала: бойлерплейт-код, ручное управление типами и отсутствие метапрограммирования тормозят продуктивность.

7.1. Дженерики (Generics)

Синтаксис <T> позволил сделать коллекции типобезопасными на этапе компиляции. Ранее:

List list = new ArrayList();
list.add("hello");
String s = (String) list.get(0); // ClassCastException при ошибке

Теперь:

List<String> list = new ArrayList<>();
list.add("hello");
String s = list.get(0); // проверка на этапе компиляции

Важно: дженерики реализованы через type erasure — информация о типе-параметре стирается при компиляции, и в байт-коде остаётся только List. Это гарантирует обратную совместимость (бинарную), но лишает рантайм-доступа к типу (например, new T() невозможно без рефлексии). Выбор в пользу erasure, а не reification (как в C#), был сделан сознательно: чтобы все существующие .class-файлы продолжали работать без перекомпиляции.

7.2. Аннотации (Annotations)

Механизм метаданных, внедряемых прямо в исходный код:

@Override
public String toString() { ... }

@Deprecated
public void oldMethod() { ... }

@Transactional
public void transfer() { ... }

Аннотации не изменяют семантику программы сами по себе — их интерпретируют процессоры: компилятор (проверка @Override), рантайм (через рефлексию — @Transactional в Spring), или внешние инструменты (JAXB, JPA). Это заложило основу для декларативного программирования: вместо императивного кода управления транзакциями — одна аннотация.

7.3. Автоматическая упаковка/распаковка (Autoboxing/Unboxing)

Устранение рутины при работе с примитивами и их объектными аналогами:

Integer i = 42;          // autoboxing: int → Integer
int j = i;               // unboxing: Integer → int
List<Integer> list = Arrays.asList(1, 2, 3); // без явных new Integer(...)

Под капотом компилятор вставляет вызовы Integer.valueOf() и intValue(). Кэширование значений от –128 до 127 (для Integer) обеспечивает экономию памяти и идентичность ссылок в пределах диапазона.

7.4. Перечисления (Enums)

До Java 5 использовались public static final int константы — с риском подмены значения и отсутствием типобезопасности. Новый тип enum:

public enum Day { MONDAY, TUESDAY, WEDNESDAY; }

public enum Status {
    PENDING(0), APPROVED(1), REJECTED(2);
    
    private final int code;
    Status(int code) { this.code = code; }
    public int getCode() { return code; }
}

— это полноценные классы: могут иметь поля, методы, реализовывать интерфейсы, содержать внутренние классы. Компилятор генерирует private static final экземпляры и запрещает наследование.

7.5. Пакет `java.util.concurrent`

До Java 5 многопоточность сводилась к synchronized, wait()/notify(). Это позволяло писать корректный код, но требовало глубокого понимания модели памяти и было подвержено deadlock’ам и livelock’ам.

Брайан Гётц и команда разработали высокоуровневые абстракции:

ExecutorService — пул потоков с управляемым жизненным циклом;
Future<T> и Callable<T> — асинхронные вычисления с возвратом результата;
ConcurrentHashMap, CopyOnWriteArrayList — потокобезопасные коллекции без глобальной блокировки;
ReentrantLock, Semaphore, CountDownLatch, CyclicBarrier — примитивы синхронизации, более гибкие, чем synchronized;
AtomicInteger, AtomicReference — операции compare-and-set (CAS) на аппаратном уровне.

Это стало фундаментом для масштабируемых серверов и реактивных систем.

8. Java 6 и Java 7

Java 6 (2006): в основном фокус на JVM и инструментарий. HotSpot получил улучшенный сборщик мусора (Parallel GC), поддержку отладки через JMX, интеграцию с нативными библиотеками (JNI improvements), и встроенную поддержку скриптовых языков (JSR 223 — ScriptEngineManager). Java стала платформой для интеграции.
Java 7 (2011): после пятилетнего перерыва (связанного с внутренними дискуссиями в Sun и переходом к Oracle) вышли умеренные, но практичные улучшения:
- Multi-catch и rethrow улучшённого типа:
```
try { ... }
catch (IOException | SQLException e) { ... } // один блок для нескольких исключений
```
- Try-with-resources — автоматическое освобождение ресурсов, реализующих AutoCloseable:
```
try (FileInputStream fis = new FileInputStream("data.bin");
     BufferedInputStream bis = new BufferedInputStream(fis)) {
    // ... 
} // fis и bis закрываются автоматически, даже при исключении
```
- Diamond-оператор (<>) — сокращение синтаксиса дженериков:
```
Map<String, List<Integer>> map = new HashMap<>(); // тип выводится из контекста
```
- NIO.2 (java.nio.file) — современный API для работы с файловой системой: Path, Files, WatchService (мониторинг изменений), поддержка символических ссылок.

Java 7 продемонстрировала смену приоритетов: от лингвистических инноваций — к инженерной надёжности, производительности JVM и улучшению developer experience (DX).

9. Java 8 (2014)

Релиз марта 2014 года стал, возможно, самым значительным после Java 5. Он изменил синтаксис и стиль программирования в экосистеме.

9.1. Лямбда-выражения

Синтаксис (args) -> body позволил писать код в декларативном, функциональном стиле:

button.addActionListener(e -> System.out.println("Clicked"));

List<String> names = users.stream()
    .filter(u -> u.isActive())
    .map(User::getName)
    .sorted()
    .collect(Collectors.toList());

Технически лямбды компилируются в статические приватные методы + вызов invokedynamic (инструкция байт-кода, добавленная в JVM в Java 7 специально для динамических языков и лямбд). Это обеспечивает низкий overhead по сравнению с анонимными классами.

9.2. Stream API

java.util.stream предоставил единый интерфейс для последовательной или параллельной обработки потоков данных:

Промежуточные операции (filter, map, sorted) — ленивые, возвращают новый Stream;
Терминальные операции (collect, forEach, reduce) — запускают вычисление.

Stream API не просто сокращает код — он позволяет JVM применять оптимизации: fusion (слияние map().filter() в один проход), loop unrolling, vectorization через ForkJoinPool.

9.3. Default и static методы в интерфейсах

Ранее интерфейсы могли содержать только абстрактные методы и static final поля. Java 8 разрешила:

public interface Comparator<T> {
    int compare(T o1, T o2);
    
    default Comparator<T> reversed() {
        return (o1, o2) -> compare(o2, o1);
    }
    
    static <T> Comparator<T> comparing(Function<T, ?> keyExtractor) { ... }
}

Это решило проблему эволюции интерфейсов: можно добавлять методы без нарушения совместимости с существующими реализациями. Default-методы также стали основой для поведенческого наследования (composition over inheritance).

9.4. Модель даты и времени — `java.time`

Устаревшие Date (изменяемый, без временных зон) и Calendar (громоздкий, непотокобезопасный) были заменены иммутабельными, потокобезопасными типами:

LocalDate, LocalTime, LocalDateTime — без временной зоны;
ZonedDateTime, OffsetDateTime — с зоной или смещением;
Duration, Period — для измерения интервалов;
DateTimeFormatter — неизменяемый, потокобезопасный парсер/форматтер.

Архитектура основана на JSR-310 (проект ThreeTen Брюса Тэка), вдохновлённом Joda-Time, но переписанном с нуля для интеграции в JDK.

9.5. Nashorn и `invokedynamic`

Встроенный JavaScript-движок Nashorn (заменяющий Rhino) использовал invokedynamic для JIT-компиляции скриптов в байт-код, достигая производительности, сопоставимой с V8. Хотя Nashorn был удалён в Java 15, его наследие — доказательство гибкости JVM как платформы для динамических языков.

10. Java 9 (2017)

Релиз сентября 2017 года стал поворотным по содержанию и по процессу: начиная с Java 9, компания Oracle (после приобретения Sun в 2010 г.) перешла к предсказуемому 6-месячному циклу выпусков, с обязательным релизом каждую весну (март) и осень (сентябрь). Одновременно была введена концепция LTS (Long-Term Support): каждая шестая версия (начиная с Java 11) получает коммерческую и community-поддержку в течение минимум трёх лет (для Oracle — до 8 лет при paid support), в то время как промежуточные версии поддерживаются лишь до выхода следующей.

Это решение отражало изменение экономики open source: enterprise-клиенты требовали стабильности, в то время как разработчики хотели быстрого доступа к новым возможностям. Модель LTS/interim позволила разделить эти потоки.

10.1. Project Jigsaw (JPMS — Java Platform Module System)

Наиболее амбициозное изменение с Java 5 — введение модулей через ключевое слово module и дескриптор module-info.java:

module com.example.app {
    requires java.sql;
    requires transitive org.slf4j;
    exports com.example.core;
    exports com.example.utils to com.example.web;
    opens com.example.config to com.fasterxml.jackson.databind;
}

Цели JPMS:

Явное управление зависимостями: модуль декларирует, какие другие модули ему требуются (requires), и какие свои пакеты он экспортирует (exports). Всё, что не экспортировано, недоступно извне — даже через рефлексию (если не указано opens).
Упрочнение инкапсуляции JDK: ранее все public классы в rt.jar были доступны. Теперь, например, sun.misc.Unsafe находится в модуле jdk.unsupported, и его использование требует явного --add-opens.
Сборка кастомных runtime-образов с помощью jlink: позволяет создавать минимальные JVM-дистрибутивы, содержащие только нужные модули (например, 30 МБ вместо 200 МБ), что критично для контейнеризации.

На практике внедрение JPMS оказалось сложным. Многие библиотеки (включая Spring и Hibernate) полагались на рефлексию и внутренние API JDK, что привело к необходимости широкого использования --add-opens и --add-exports. Тем не менее, JPMS заложил основу для масштабируемой архитектуры: сегодня Java поддерживает системы из сотен модулей (например, IntelliJ IDEA), где зависимости строго верифицируются на этапе компиляции и линковки.

10.2. Другие ключевые изменения Java 9

JShell — REPL (Read-Eval-Print Loop) для интерактивного выполнения Java-кода без создания классов. Стал незаменимым инструментом для обучения и прототипирования.
Улучшенная система логгирования JVM (-Xlog), унифицирующая вывод GC, JIT, class loading в единый формат с гибкой фильтрацией.
HTTP/2 Client (Incubator) — первый шаг к замене устаревшего HttpURLConnection. Позже стабилизирован в Java 11.

11. Java 10–16

Эти версии, хотя и не LTS, сыграли важную роль в адаптации платформы:

Java 10 (2018): ввёл Local-Variable Type Inference (var):
```
var list = new ArrayList<String>(); // тип выводится как ArrayList<String>
var stream = list.stream();         // Stream<String>
```
Важно: var — не динамическая типизация; тип фиксируется на этапе компиляции. Ограничения: недопустим в полях, параметрах, возвращаемых типах — только в локальных переменных с инициализатором.
Java 11 (2018, LTS): первый LTS-релиз по новой модели. Ключевые изменения:
- Удаление устаревших модулей: java.se.ee (CORBA, JAXB, JAX-WS), что отразило переход от monolithic J2EE к микросервисам и cloud-native.
- Стабилизация HTTP Client API (на замену Apache HttpClient и OkHttp в стандартной библиотеке):
```
HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder(URI.create("https://api.example.com"))
                                .header("Accept", "application/json")
                                .build();
HttpResponse<String> response = client.send(request, BodyHandlers.ofString());
```
- Поддержка TLS 1.3, Epsilon GC (no-op сборщик — для кратковременных задач и бенчмаркинга).
Java 12–13: инкубационные фичи: Switch Expressions (упрощение switch), Text Blocks (многострочные строки, """...""").
Java 14 (2020): Records — компактное объявление неизменяемых классов-носителей данных:
```
public record Point(int x, int y) {}
// Компилятор генерирует: private final поля, конструктор, equals, hashCode, toString
```
Records не являются «кортежами» или структурами — это полноценные классы, наследующие java.lang.Record, с возможностью добавления методов и реализации интерфейсов.
Java 15 (2020): Sealed Classes — контроль над иерархией наследования:
```
public sealed class Shape permits Circle, Rectangle, Triangle { ... }
// Только перечисленные классы могут наследоваться от Shape
```
Это позволяет компилятору проверять полноту instanceof-цепочек и обеспечивает закрытые домены типов — основу для будущего pattern matching.
Java 16 (2021): Pattern Matching for instanceof:
```
if (obj instanceof String s && s.length() > 5) {
    System.out.println(s.toUpperCase()); // s уже String, без каста
}
```
Устраняет шаблон String s = (String) obj; и повышает безопасность.

12. Java 17 (2021, LTS)

Java 17 стал первым LTS, собравшим все лингвистические инновации предыдущих версий (Records, Sealed Classes, Text Blocks, Pattern Matching частично) в стабильном виде. Это позволило enterprise-компаниям перейти с Java 8/11 на современный Java без рисков инкубационных API.

Особое значение имеет удаление Applet API — официальное признание конца эры клиент-ориентированных Java-приложений в браузере. Платформа окончательно сместилась в сторону серверной, облачной и data-intensive разработки.

Также в Java 17:

Strong encapsulation by default — модули JDK теперь строго закрыты; доступ к внутренностям требует явных --add-opens.
Новые алгоритмы шифрования (EdDSA, X25519), поддержка ZGC и Shenandoah GC (low-pause сборщики) как production-ready.

13. Java 18–21

13.1. Project Loom: виртуальные потоки (Virtual Threads)

Стабилизированы в Java 21 (2023, LTS). Традиционные потоки (java.lang.Thread) — это обёртка над нативными потоками ОС, которые дороги по памяти (1 МБ стека) и количеству (ограничены ядром). Виртуальные потоки — лёгкие потоки, управляемые JVM, с переключением в пользовательском пространстве:

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 10_000).forEach(i -> {
        executor.submit(() -> {
            // Каждая задача — в отдельном виртуальном потоке
            Thread.sleep(Duration.ofSeconds(1));
            return i;
        });
    });
}
// 10 000 параллельных задач на одном ядре

Это позволяет писать синхронный код для асинхронных I/O-нагруженных систем (веб-серверы, микросервисы), избегая callback-адского и реактивного бойлерплейта. Проект Loom меняет модель масштабируемости: от thread-per-connection → virtual-thread-per-request.

13.2. Project Panama: Foreign Function & Memory API (FFM)

Стабилизирован в Java 22 (но доступен с 19 как preview), FFM заменяет устаревший, небезопасный JNI. Он позволяет:

Вызывать нативные функции (C, C++, Rust) без генерации glue-кода;
Управлять off-heap памятью (например, для zero-copy обработки сетевых пакетов или работы с GPU);
Работать с MemorySegment, MemoryLayout, Linker — типобезопасно и без утечек.

Пример:

Linker linker = Linker.nativeLinker();
SymbolLookup stdlib = linker.defaultLookup();
MethodHandle printf = stdlib.find("printf").get()
    .asType(MethodType.methodType(int.class, MemorySegment.class));
try (Arena arena = Arena.ofConfined()) {
    MemorySegment str = arena.allocateUtf8String("Hello from Java %d\n");
    printf.invoke(str, 42);
}

Panama открывает Java для high-performance domain’ов: машинное обучение (интеграция с CUDA), системное программирование, embedded.

13.3. Project Valhalla: Value Types и Generic Specialization

Находится в активной разработке (preview в Java 21). Цель — преодолеть разрыв между примитивами и объектами:

Value Types (inline class) — объекты без идентичности (== по значению, а не по ссылке), размещаемые внутри других объектов («flattening»), что устраняет indirection и повышает кэш-локальность.
Generic Specialization — возможность параметризовать дженерики примитивами: List<int> вместо List<Integer>, без boxing/unboxing и аллокаций.

Это критично для научных вычислений, финансовых систем, игр — где каждый такт и байт важен.

14. OpenJDK, сообщество и конкуренция

С 2006 года, когда Sun открыл исходный код Java под GPL (OpenJDK), платформа перестала быть монополией одного вендора. Сегодня:

OpenJDK — reference implementation, поддерживаемая сообществом (Red Hat, SAP, Amazon, Microsoft, Alibaba).
Дистрибутивы: Adoptium (Eclipse Temurin), Amazon Corretto, Azul Zulu, Microsoft Build of OpenJDK — все совместимы, но различаются по GC, security patches, LTS-политике.
GraalVM — high-performance runtime с AOT-компиляцией (native-image), полиморфной JIT и поддержкой JavaScript, Python, Ruby, R на одной VM.
Конкуренция:
- Kotlin — язык на JVM, решающий многие боли Java (null safety, extension functions, concise syntax), официально поддерживаемый Google для Android.
- Go — для облачных микросервисов (лёгкие горутины, простой deployment).
- Rust — для системного кода (memory safety без GC).

Java адаптируется: ускоряется цикл фич, упрощается синтаксис, улучшается GC. Но её преимущество — в стабильности, зрелости библиотек и экосистемы: Spring, Jakarta EE, Quarkus, Micronaut, Kafka, Hadoop, Spark — всё это работает на JVM.

История Java​

1. Предпосылки возникновения​

2. Green Project и рождение Oak​

3. Переход к Java​

3.1. Философия «Write Once, Run Anywhere»​

3.2. Безопасность​

4. Java 1.0 (1996)​

5. Java 1.1 (1997)​

6. Java 1.2 и Java 2 Platform (1998–2000)​

6.1. Технические вехи Java 1.2​

6.2. J2EE​

7. Эпоха Java 5 (J2SE 5.0, 2004)​

7.1. Дженерики (Generics)​

7.2. Аннотации (Annotations)​

7.3. Автоматическая упаковка/распаковка (Autoboxing/Unboxing)​

7.4. Перечисления (Enums)​

7.5. Пакет java.util.concurrent​

8. Java 6 и Java 7​

9. Java 8 (2014)​

9.1. Лямбда-выражения​

9.2. Stream API​

9.3. Default и static методы в интерфейсах​

9.4. Модель даты и времени — java.time​

9.5. Nashorn и invokedynamic​

10. Java 9 (2017)​

10.1. Project Jigsaw (JPMS — Java Platform Module System)​

10.2. Другие ключевые изменения Java 9​

11. Java 10–16​

12. Java 17 (2021, LTS)​

13. Java 18–21​

13.1. Project Loom: виртуальные потоки (Virtual Threads)​

13.2. Project Panama: Foreign Function & Memory API (FFM)​

13.3. Project Valhalla: Value Types и Generic Specialization​

14. OpenJDK, сообщество и конкуренция​