Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Модули в Java 9 были сделаны для внутреннего использования, чтобы JDK перестала быть монолитной. Как итог — в JDK 11 довольно быстро были выпилены deprecated модули (аплеты, CORBA, JAXB). А вот идея сделать их фитчей для внешнего использования не прижилась, потому что была и несколько сырая по реализации, и не приносила какой-то реальной пользы программистам. Кроме того, в модулях есть требования, которые противоречат текущему положению дел (например, один пакет не может быть в разных модулях).

Если они сделаны только для внутреннего использования, то зачем выпускать публичный API, инструменты и т.д. И если посмотреть на ранний драфт, то изначально планировалась поддержка вменяемой версионности и не только. Но потом, как всегда, что то пошло не так :) Вот одна точка зрения, что там пошло не так.

З.Ы. что интересно, модули пили аж 11 лет. В оправдание такого долгого срока можно сказать, что сюда входило так же распил JDK на модули.

З.З.Ы. ну а по теме топика — на данном этапе я вижу только одно преимущество модулей — создание урезанного JDK.

Эти все вопросы скорее не ко мне, а к разработчикам из Oracle. У модулей есть и преимущества — например, инкапсуляция на уровня модуля, чего раньше не было, и в принципе это полезная фитча.

инкапсуляция на уровня модуля, чего раньше не было

в OSGi это было уже лет 10 как

не уверен, что можно сравнивать «инкапсуляцию» на класспасах (OSGi) с реальной инкапсуляцией модулей

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

На уровне OSGi при импорте в мой модуль пакета p1 модуля M, я без проблем получу доступ к классам «интернального» пакета p2 того же модуля. А вот при иcпользовании модулей у меня это может быть и получится, но токо через reflection (не уверен, что получится, т.к. глубоко в модули не вникал).

OSGi давно умерло, к чему здесь его упоминать ?

Я бы не сказал, что он умер. Например, последние релизы Apache Felix и Equinox этого года.

Я не имел в виду, что его разработка остановлена. Но кто сейчас использует OSGi, особенно в новых проектах? Специально сделал поиск на ДОУ в разделе вакансии. Spring требуется в 196 вакансиях, OSGi встречается в двух.

Ну а сейчас в принципе проекты в основном и так состоят из модулей, правда не Java 9, а Maven или Gradle.

В этом и есть главный вопрос — зачем нужны «новые» java9 модули, если всех устраивали «старые» maven.

JDK вполне можно было бы распилить на maven модули, не изобретая новый синтаксис, и не ломая совместимость.

Откуда вообще это берется? У нас тоже такие понаехали. Крайне неудобно.

Модульность штука хорошая, если ей правильно пользоваться. Но проблема в том что архитектура должна быть рассчитана на это. Например, в андроиде аналог модульности существует уже давно и обычно в модули выносят редко изменяемый код — сетевые запросы, БД и т.д. Это позволяет сосредоточиться на том что изменяется чаще (ui, ux, и т.д). Но если архитектура не предназначена для использования модулей, то это превращается в треш, угар и содомию.

Есть у кого-нибудь удачный опыт применения Java 9+ модулей?

Как там в вакансии: новый стек технологий, интересные проекты. :)

Вопрос больше касается не вакансий, а хочется до конца понять, куда движется развитие джавы. Слежу за ней где-то с версии 1.5. С моей точки зрения большентсво вазжных новых фичей языка какие-то не доработанные (часто не обоснованно):
* дженерики — стирание типов, отсутствует вменяемая поддержка вариантности
* аннотации — не поддерживается наследование, типа это что-то там усложнит ¯\_(ツ)_/¯
* лямбды вроде из ФП мира, но нет нормального определения функций. У меня такое ощущение, что это просто упрощенный синтаксис реализации анаонимных классов.
* модули — вроде бы нужная вещь — решает проблемы инкапсуляции на уровне модуля, между несколькими модулями. Но вот незадача — при указании зависимости версия модуля не учитывается, а делегируется каким-то внешним интсрументам, которые далеки от стандарта.

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

Ну и если я бы делал какую-нибудь библиотеку с нуля, то да, уже как модуль. Потому что фарш не провернуть назад, и модули — новая данность.

А вообще с модуляризацией еще есть проблемы — например у сваггера, который в springfox.

Ну и если я бы делал какую-нибудь библиотеку с нуля, то да, уже как модуль. Потому что фарш не провернуть назад, и модули — новая данность.

Вот если бы вы выпустили новую версию либы в виде модуля, то как там будет разруливатьсяситуация при указании заисимости моего кода на вашу либу?

Вот более сложный вариант:

your lib 1.0   your lib 2.0
    |           |
lib C 1.0   lib B 2.0
         \ /
          |
        my App

Ну, во-первых:

Я еще сам не вникал особо в модуляризацию

Так что не могу предметно и точно на ваш вопрос ответить, увы.

Во-вторых, модуль — это всеголишь plain old .jar с + файликом module-info в корне пакетов.
Т.е. по сути, модуль в плане версионности во всем идентичен обычным библиотекам в джарниках, и ваш вопрос можно рассматривать вообще без привязки к Java9+ модульности.

А решением подобных конфликтов занимается Мавен.

Я еще сам не вникал особо в модуляризацию
А решением подобных конфликтов занимается Мавен.

Да вот и я как бы задумался, а стоит ли особо тратить на это время?

Т.е. по сути, модуль в плане версионности во всем идентичен обычным библиотекам в джарниках

Это и так понятно, что на уровне того же монолита с модулями в джаве 1.8- либо юзаем обычные джарники, без какой-либо инкапсуляции, но зато с нормальным разрешеним зависимостей (maven, ivy). А если уж так сильно нада поддержка инкапсуляции на уровне либы (модуля), то смотрим в сторону OSGi, с поддержкой как инкапсуляции, так и разрешением версий.

З.Ы. мне бы хотелось бы услышать реальный опыт использования jigsaw модулей — все равно, позитивный или негативный.

Java в целом бессмысленна, не только ее модули.

Евгений Ваганыч, разлогиньтесь уже

С таким подходом, любой высокуровневый язык, вцелом, бессмысленный. Надо изучать всякие там ООП, ФП и другие парадигмы, которые, по сути, чистый сахар. А вот ассемблер ...

Підписатись на коментарі