Java называют языком программирования. С формальной точки зрения это может быть и так. На практике картина более широкая: я считаю, что Java нужно рассматривать как целую программную систему для гибкой (Agile) разработки. В ней можно выделить четыре ключевых подсистемы, которые вместе образуют Java платформу:

1. Система ведения онтологии и моделирования бизнеса
2. Система верификации типов с правилами подстановки
3. Система среды исполнения динамического кода
4. Система модульной эволюции кодовой базы

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

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

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

Java называют языком программирования. С формальной точки зрения это может быть и так. На практике картина более широкая: я утверждаю, что Java — это целая программная система для гибкой (agile) разработки. В ней можно выделить четыре ключевых подсистемы, которые вместе образуют Java платформу:

1. Система ведения онтологии и моделирования бизнеса
2. Система верификации типов с правилами подстановки
3. Система среды исполнения динамического кода
4. Система модульной эволюции кодовой базы

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

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

После обширного анализа будет представлено видение направления развития Явы как платформы, получившей новую среду скриптовых языков GraalVM. Основным тезисом служит заявление, что Агиль методология требует строгой трактовки, дисциплины и продуманных инструментов, чтобы свобода разработчика не превратилась в её свободный полёт в пучину хаоса!

Всем хорошо известны интерфейсы — то есть контракты, которым должны соответствовать классы, однако мало кто слышал про универсалии, которые являются последним словом в дизайне ПО. С точки зрения философии, откуда это понятие исходит, универсалия — это свойство, которое присуще двум или более сущностям определенной категории, например свойство "цветной" присуще всем объектам, у которых может быть цвет: если бы мы моделировали Pencil, то есть карандаш, мы бы сказали, что Pencil implements IColorful, посколько он имеет цвет. Но интерфейсы — понятие широкое, которое также используется для описания поведения. Я же предлагаю ввести специальную категорию интерфейсов, называемых универсалиями, у которых есть всего 1 свойство, содержащее конкретный объект, для задачи внедрения зависимостей и уменьшению бойлерплейта.

Модельно-ориентированный метод (MDE) широко применяется во многих сферах современной инженерии; в программировании он позволяет разделить деятельность, направленную на создание универсального описания продукта, от деятельности по написанию кода, который бы эту модель воплощал в реальность. На практике, в мире Java эти деятельности по-сути совмещены воедино языком программирования, так как мы определяем интерфейсы на том же языке, на котором потом и пишем реализацию, поэтому грань между моделью и кодом может быть не так очевидна. Однако, она отчетливо проявляется, когда требуется интегрировать нашу программу в работу более сложных систем: например, я бы хотел запускать мою CLI утилиту как сервис, доступ к которому можно было бы получить через любой язык программирования по сокетам, сохранив при этом хороший Dev-X с автозаполнением полей и описанием опций. Сделаем это в 3 этапа под катом: во-первых, сконвертируем существующий Java-класс, который описывает флаги, в модельно-ориентированный XML, затем из него сгенерируем protobuf файлы для бинарного обмена данными и в завершение скомпилируем их для JavaScript и Java, обернув в приличный JSDoc. В конце обсудим все преимущества работы "на модель" и будущее роли дизайна при разработке ПО.

Google Closure Stylesheets -- это компилятор для CSS, написанный Гугл в рамках набора инструментов Closure для веб-разработки, который в свое время обладал внушительными функциями такими как экспансия браузерных префиксов, переменными и др. Прошло уже более 10 лет с начала этого проекта, и в прошлом году его архивировали. Я же продолжил вести свой форк, и сегодня собрал его как нативный binary с помощью Oracle GraalVM. Под катом рассказ о том, какие моменты пришлось проработать, а так же небольшие бенчмарки.