How a Group of Developers Took Back Control from Enterprise Java | Spring: The Documentary (Рубрика #Software)

Посмотрел на выходных документалку про Spring. Я люблю такие фильмы про технологии: они показывают не только что появилось, но и какую боль технология изначально пыталась снять. История Spring особенно хорошая: это не просто рассказ про популярный Java framework, а история про то, как разработчики устали от тяжелой enterprise-модели и начали возвращать себе контроль над кодом.

В начале 2000-х Enterprise Java выглядела очень солидно: спецификации, application servers, EJB, XML-дескрипторы, контейнеры, большие vendor'ы. Все как будто было устроено “по-взрослому”. Но для обычной разработки это часто означало медленный цикл обратной связи, сложное тестирование и ощущение, что простая бизнес-логика внезапно требует слишком много инфраструктурной магии.

Spring появился как ответ на это трение. Rod Johnson сначала сформулировал критику тогдашнего J2EE-подхода в книге "Expert One-on-One J2EE Design and Development", а код из приложения к книге постепенно превратился в Spring. Мне нравится, что альтернатива пришла не как очередная большая спецификация сверху, а как практичный набор инженерных принципов снизу: POJO вместо тяжелых компонентов, Dependency injection и Inversion of Control вместо жесткой связки с контейнером. Тестируемость как нормальное требование к дизайну. Композиция объектов вместо ощущения, что настоящая архитектура обязательно должна быть спрятана в application server. По сути, Spring сказал разработчикам: бизнес-логика снова может быть обычным Java-кодом. Ее можно читать, подменять зависимости, тестировать отдельно и постепенно встраивать в большую систему. Сегодня это звучит почти банально, но тогда в этом был сильный архитектурный сдвиг.

Отдельно интересно, что Spring не остановился на первой победе. Со временем он сам стал большим ecosystem, со своей конфигурацией, conventions и complexity. Следующим шагом стал Spring Boot: меньше ручной настройки, sensible defaults, embedded server, быстрый старт приложения. Boot хорошо попал в эпоху microservices, containers и cloud-native разработки, где старый подход “сначала собери всю enterprise-инфраструктуру вокруг приложения” снова стал слишком тяжелым.

Но у этой истории есть и вторая сторона. Когда технология выигрывает, она становится инфраструктурой. А инфраструктура обрастает legacy, версиями, upgrade cost, security-патчами, совместимостью и long-term maintenance. Spring начинался как способ вернуть контроль разработчикам, а теперь сам является частью огромного enterprise landscape, которым нужно управлять аккуратно. Забавно, что главный спонсор этого фильма - компания HeroDevs, которая саппортит код legacy приложений, которые живут на фреймворках и библиотеках, что давно уже вышли из цикла поддержки, но никто не готов переписывать сами бизнес-приложения. В итоге, ребята из HeroDevs занимаются таким maintenance и фиксят в основном уязвимости в старой кодовой базе.

Для меня главный вывод такой: сильные технологии часто появляются не из желания “сделать еще один framework”, а из желания убрать трение между идеей, кодом, тестом и production. Они побеждают не только фичами, а тем, что меняют повседневный опыт разработчика.

#Software #Java #Spring #Architecture #Engineering #OpenSource #History

The Java Story: как язык стал долгоживущей платформой (Рубрика #Software)

Посмотрел вчера в прямом эфире документалку «The Java Story» от CultRepo про историю Java. В кадре были James Gosling, Joshua Bloch, Brian Goetz, создатели Tomcat, Spring, Hibernate и Kotlin, а также инженеры Java-экосистемы. Но для меня это не столько история просто языка, скорее это история про целую технологическую платформу, что пережила собственные ошибки, смену владельца и попытки объявить её мёртвой. И кажется, что причина в том, что эта платформа научилась меняться, не разрывая экосистему. Совместимость, управление платформой и сообщество оказались важнее красоты отдельных языковых решений.

Изначально java называлась Oak и ее создавали для бытовых вычислительных устройств. Интерактивное телевидение не взлетело, команда переключилась на веб, а настоящий масштаб Java в итоге нашла на сервере. Уже здесь видна повторяющаяся схема: технология сохраняет ядро, но меняет рынок и задачу вокруг него.

Даже знаменитое мотто write once, run anywhere в фильме постепенно перестаёт быть рекламным лозунгом. Конфликт Sun с Microsoft показан как борьба за то, кто контролирует платформенный контракт. Если реализация Java под Windows становится несовместимой с остальными, переносимость исчезает, а вместе с ней - и сама причина существования платформы. Здесь Microsoft тех лет представлен в виде гиганта, что греб все под себя:)

Но одной защитой совместимости экосистему не построить. Java Community Process формализовал участие компаний и сообщества в развитии спецификаций. Tomcat показал Sun, что открытый код не обязательно ведёт к хаосу. Позже OpenJDK закрепил ещё более важную мысль: платформу можно открыть, не отказываясь от общего контракта.

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

А когда после Java 5 развитие языка замедлилось, сама виртуальная машина Java (JVM) не опустела. Scala, Clojure и Kotlin предложили более современные модели, сохранив библиотеки, инструменты и среду выполнения Java. Это сильная платформенная конструкция: недовольство языком не обязательно означает уход из экосистемы. Иногда новая идея сначала появляется рядом, а затем заставляет основную платформу двигаться.

Полезно сопоставить эту линию и с .NET. В фильме Microsoft сначала выступает угрозой из мира закрытой Windows-платформы. Но позднее C# и .NET сами прошли путь к открытому коду и кроссплатформенности. Получается не простая история «Java против Microsoft», а две разные траектории к одной задаче: как удержать разработчиков, не запирая их в технологическом тупике.

Современная Java продолжает ту же логику. Java 8 добавила лямбды и Stream API, не создавая отдельный «новый Java». Шестимесячный цикл отделил готовность конкретной возможности от большого редкого релиза. А virtual threads в Project Loom меняют внутреннюю механику потоков, сохраняя знакомые API и последовательную модель thread-per-request. Инженерно это красивая часть истории: заменить фундамент дома так, чтобы людям наверху не пришлось учиться ходить заново.

У фильма есть понятная оптика: его поддержали компании Java-экосистемы, а историю в основном рассказывают люди, которые эту платформу создавали. Поэтому я бы смотрел его как коллективную инженерную автобиографию, а не как независимое расследование. Особенно там, где участники оценивают решения Sun, Oracle или влияние отдельных проектов.

Для меня главный вывод такой: зрелая платформа - это не только язык, среда выполнения и API. Это ещё бюджет совместимости, правила принятия решений, инструменты, открытый код, выпуск обновлений и возможность сообщества исправить платформу, когда её владельцы ошибаются. Практически это означает, что архитектору платформы мало проектировать расширяемое ядро. Нужны путь миграции, предсказуемый цикл релизов и место для альтернатив. Java выжила не потому, что всегда выбирала правильно. Она выжила потому, что экосистема снова и снова получала возможность скорректировать курс.

Связанные разборы документалок в System Design Space:
- Spring: The Documentary
- IntelliJ IDEA и линия Kotlin
- C#, TypeScript и эволюция .NET
- Clojure как альтернативная линия JVM

А вот они же но просто в виде фильмов, если вы решите почилить и продолжить после истории Java просмотр остросюжетных документалок про Spring, IntelliJ IDEA, Clojure и Apache Tomcat

#Software #Java #JVM #Architecture #Engineering #OpenSource #History