Модули Java 9. Почему не OSGi?

В Java 9 появляются модули. Кого-то это мало волнует, кого-то пугает, кто-то искренне недоумевает: зачем, ведь у нас уже больше 15 лет есть OSGi, который решает ровно те же проблемы, что и модули?

В этом докладе мы попробуем разобраться, какие проблемы пытается решить OSGi, как он их решает и решает ли в действительности. Затем разберёмся, какие проблемы, которые пытается решить OSGi, Jigsaw совсем не решает и почему, а какие проблемы решает и как. Ну и в конце поговорим, какие проблемы Jigsaw при этом привносит в экосистему Java и что с этим делать.

Transcript

1. Java 9 Модули. Почему не OSGi? Никита Липский Excelsior LLC 1
3. Модули в IDE 3
4. Модули в Maven com.foo app 1.0 com.foo parse-api 2.0 com.foo persist-api 3.0 org.apache commons 2.1 org.apache commons-io 3.1 4
5. Модули в Maven com.foo App 1.0 com.foo parse-api 2.0 com.foo persist-api 3.0 org.apache commons 2.1 org.apache commons 3.1 5
6. OSGi 6
7. Почему не OSGi? Mark Reinhold (the Chief Architect of the Java PlaPorm Group): “…As it (OSGi) stands, moreover, it’s useful for library and applicaSon modules but, since it’s built strictly on top of the Java SE PlaVorm, it can’t be used to modularize the PlaVorm itself” 7
8. Почему не OSGi? Вопрос: почему наличие j.l.Object в спецификации языка Java, реализованного в свою очередь на языке Java, не приводит к bootstrap проблеме? Факт: Существует реализация Java SE, где OSGi поддерживается на уровне JVM (на уровне платформы). 8
9. Почему не OSGi? Вопрос: почему наличие j.l.Object в спецификации языка Java, реализованного в свою очередь на языке Java, не приводит к bootstrap проблеме? Факт: Существует реализация Java SE, где OSGi поддерживается на уровне JVM (на уровне платформы). 9
10. Кто знает про себя ? •  Инициатор проекта Excelsior JET –  работал над проектом более 17 лет –  как идейный вдохновитель –  компиляторный инженер –  руководитель –  и много в каких еще ролях •  twi{er: @pjBooms •  team blog: h{ps://www.excelsiorjet.com/blog 10
11. План доклада •  Почему OSGi •  Как OSGi •  Почему НЕ OSGi •  Почему Jigsaw не OSGi •  Jigsaw мантра •  Проблемы Jigsaw 11
12. Где OSGi? OSGi – это стандарт OSGi aliance (IBM, Adobe, Bosch, Huawei, NTT, Oraсle) Реализации: •  Equinox –  Eclipse IDE, Eclipse RCP, IBM Websphere •  Apache Felix –  Oracle WebLogic, Glassfish, Netbeans 12
13. Почему OSGi? 13
14. Почему OSGi? •  Модульность –  Снижение сложности (Reduced complexity) –  Инкапсуляция (Hide internals) –  Управление зависимостями и легкость развертывания (Easy deployment) •  Динамические обновления (Dynamic updates) •  Версионирование (Versioning) •  Ленивая активация модулей (Lazy) •  Simple, fast, small, secure, etc. h{ps://www.osgi.org/developer/benefits-of-using-osgi/ 14
15. Модульная система OSGi 15
16. Модульная система OSGi OSGi модуль – Bundle (бандл): •  Jar или директория •  Импорт/экспорт задается в манифесте бандла META-INF/MANIFEST.MF. Пример: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-SymbolicName: B Bundle-Version: 1 Bundle-Name: B Bundle Export-Package: org.bar Import-Package: org.foo;version=“[1,2)” 16
17. Модульная система OSGi •  OSGi бандл импортирует и экспортирует – пакеты (Import-Package/Export-Package) – сервисы (Import-Service/Export-Service). •  Может импортировать другие бандлы напрямую (Require-Bundle) – но это не приветствуется (менее гибко). 17
18. Модульная система OSGi 18 Bundle A Class A Bundle B Class B Bundle C Class C Export-Package: packageC Import-Package: packageA Export-Package: packageA I Import-Package: packageA, packageC
19. OSGi RunSme •  Разрешает Import/Export OSGi бандлов (wiring) •  Определяет жизненный цикл бандлов –  может стартовать (активировать) бандлы лениво –  позволяет обновлять бандлы без перезапуска всей системы (aka hot redeploy). 19
20. Jar/Classpath Hell App 1.0 Library Foo 2.0 Library Bar 3.0 Library Baz 2.1 Library Baz 3.1 20
21. Версионирование в OSGi •  OSGI решает JAR hell: – импорт/экспорт квалифицируется версией – если два бандла требуют библиотеки разных версий, загрузятся обе версии библиотеки 21
22. Почему OSGi? Итак, OSGi обещает: •  Модульность –  явные зависимости –  инкапсуляция •  Решение проблемы JAR Hell –  через версионирование •  Hot ReDeploy (обновления на лету) –  через возможность обновлять отдельный бандл динамически 22
23. Почему OSGi? Итак, OSGi обещает: •  Модульность –  явные зависимости –  инкапсуляция •  Решение проблемы JAR Hell –  через версионирование •  Hot ReDeploy (обновления на лету) –  через возможность обновлять отдельный бандл динамически 23
24. Почему OSGi? Итак, OSGi обещает: •  Модульность –  явные зависимости –  инкапсуляция •  Решение проблемы JAR Hell –  через версионирование •  Hot ReDeploy (обновления на лету) –  через возможность обновлять отдельный бандл динамически 24
25. Почему OSGi? Итак, OSGi обещает: •  Модульность –  явные зависимости –  инкапсуляция •  Решение проблемы JAR Hell –  через версионирование •  Hot ReDeploy (обновления на лету) –  через возможность обновлять отдельный бандл динамически 25
27. Как OSGi? 27
28. Версионирование в OSGi Вопрос: Как реализовать версионирование? Задача: Имеем модуль A, использующий библиотеку Lib (v1), и модуль B, использующий Lib (v2). Требуется, чтобы обе версии Lib работали и не конфликтовали. Решение: грузить обе версии библиотеки разными загрузчиками классов. 28
29. Версионирование в OSGi Вопрос: Как реализовать версионирование? Задача: Имеем модуль A, использующий библиотеку Lib (v1), и модуль B, использующий Lib (v2). Требуется, чтобы обе версии Lib работали и не конфликтовали. Решение: грузить обе версии библиотеки разными загрузчиками классов. 29
30. Версионирование в OSGi Вопрос: Как реализовать версионирование? Задача: Имеем модуль A, использующий библиотеку Lib (v1), и модуль B, использующий Lib (v2). Требуется, чтобы обе версии Lib работали и не конфликтовали. Решение: грузить обе версии библиотеки разными загрузчиками классов. 30
31. Версионирование в OSGi Таким образом, каждый OSGi бандл грузится своим загрузчиком классов: •  наследник java.lang.ClassLoader •  уникальное пространство имен классов •  нет конфликтов с классами других бандлов 31
32. Версионирование в OSGi 32 com.foo App 1.0 com.foo parse-api 2.0 com.foo persist-api 3.0 org.apache commons 2.1 org.apache commons 3.1 CL CL CL CL CL Разные версии apache commons могут одновременно жить в JVM Каждый бандл грузится своим загрузчиком
33. Инкапсуляция в OSGi 33
34. Инкапсуляция в OSGi src/com/foo/exported/A.java: package com.foo.exported; import com.foo.internal.B; public class A { B useB; } src/com/foo/internal/B.java: package com.foo.internal; public class B { } Как сделать класс B недоступным из вне модуля? 34
35. Инкапсуляция в OSGi Вопрос: как сделать внутренний класс модуля, объявленный публичным недоступным из вне? 35
36. Инкапсуляция в OSGi Вопрос: как сделать внутренний класс модуля, объявленный публичным недоступным из вне? Ответ: загрузчики классов (!) могут прятать внутренние классы. 36
37. Динамическое обновление Задача: заменить один (!) изменившийся модуль в уже запущенной программе, не останавливая программу 37
38. Динамическое обновление Задача: заменить один (!) изменившийся модуль в уже запущенной программе, не останавливая программу Решение: ЗАГРУЗЧИКИ КЛАССОВ! (отгружаем старый модуль, грузим новый модуль новым загрузчиком классов) 38
39. Жизненный цикл бандла 39
40. Ленивый старт Старт бандлов в OSGi сделан через механизм активаторов бандлов: •  Каждый бандл может иметь активатор –  директива манифеста Bundle-Activator –  реализация интерфейса с методами start(), stop() –  Аналог статического инициализатора для класса 40
41. Ленивый старт Старт бандлов в OSGi сделан через механизм активаторов бандлов: public interface BundleAcŸvator { void start(BundleContext context) throws ExcepŸon; void stop(BundleContext context) throws ExcepŸon; } 41
42. Ленивый старт •  Когда бандлы стартуют может задаваться конфигурацией OSGi окружения •  Если явно не задан момент старта бандла, то бандл стартует, когда потребуется другим запущенным бандлам 42
43. Ленивый старт Задача: стартовать (грузить) модули только когда они потребуются в работе программы 43
44. Ленивый старт Решение: ЗАГРУЗЧИК КЛАССОВ (опять!) … бандла реализован так, что перед тем как загрузить первый класс бандла, он вызывает метод start() активатора бандла Так как загрузка классов в JVM – ленивая, то и активация бандлов становится ленивой АВТОМАТОМ 44
45. Ленивый старт Решение: ЗАГРУЗЧИК КЛАССОВ (опять!) бандла реализован так, что перед тем как загрузить первый класс бандла, он вызывает метод start() активатора бандла Так как загрузка классов в JVM – ленивая, то и активация бандлов становится ленивой АВТОМАТОМ 45
46. Ленивый старт Решение: ЗАГРУЗЧИК КЛАССОВ (опять!) бандла реализован так, что перед тем как загрузить первый класс бандла, он вызывает метод start() активатора бандла Так как загрузка классов в JVM – ленивая, то и активация бандлов становится ленивой АВТОМАТОМ 46
47. Как OSGi? Семь бед – один ответ! 47
49. Почему НЕ OSGi? 49
50. Модульность? Bundle A Bundle B 50
51. Модульность? Bundle A Bundle B Bundle C 51
52. Модульность? Bundle A Bundle B Bundle C Bundle D 52
53. Модульность? Bundle A Bundle B Bundle C Bundle D 53
54. Модульность? Bundle A Bundle B Bundle C Bundle D 54
55. Модульность? Bundle A Bundle B Bundle C Bundle D 55
56. Модульность? OSGI позволяет циклы в графе зависимостей Упражнение: понять, почему это плохо A B C D 56
57. Обновления на лету? 57
58. Обновления на лету? 58 Bundle A Bundle B
59. Обновления на лету? Обновляем бандл B 59 Bundle A Bundle B
60. Обновления на лету? 60 Bundle A Bundle B
61. Bundle A Bundle B Обновления на лету? 61
62. Обновления на лету? 62 Bundle A NEW Bundle B
63. Обновления на лету? 63 Bundle A NEW Bundle B
64. Обновления на лету? Пройдет ли тот же фокус с бандлом A? 64 Bundle A Bundle B
65. Обновления на лету? 65 Bundle B Class B Bundle A Class А
66. Обновления на лету? Если бандл B импортирует бандл А, значит есть класс из B, ссылающийся на класс из A 66 Bundle B Class B Bundle A Class А
67. Разрешение символьных ссылок B.java: class B { A useA; int f1 = A.f; int f2 = A.foo(); } A.java: class A { staSc int f; staSc int foo(){}; } 67
68. Разрешение символьных ссылок 68 B.class … CONSTANT_Class: A CONSTANT_FieldRef: A.f@int CONSTANT_MethodRef: A.foo()I … A.class … Field: f@int Method: foo()I …
69. Разрешение символьных ссылок •  Класс ссылается на другие классы и поля, методы других классов символьно 69
70. Разрешение символьных ссылок •  Класс ссылается на другие классы и поля, методы других классов символьно •  В рантайме символьные ссылки разрешаются JVM на реальные значения 70
71. Разрешение символьных ссылок •  Класс ссылается на другие классы и поля, методы других классов символьно •  В рантайме символьные ссылки разрешаются JVM на реальные значения •  После первого разрешения ссылки, значение ссылки больше не меняется! 71
72. Обновления на лету? •  Если ссылка из класса B на класс A разрешилась, то класс А нельзя выгрузить из JVM без выгрузки класса B 72
73. Обновления на лету? •  Если ссылка из класса B на класс A разрешилась, то класс А нельзя выгрузить из JVM без выгрузки класса B •  Значит если бандл В импортирует бандл А, бандл А нельзя выгрузить без выгрузки бандла B 73
74. Обновления на лету? Обновляем бандл A 74 Bundle A Bundle B
75. Обновления на лету? Bundle A Bundle B 75
76. Обновления на лету? Bundle A Bundle B 76
77. Обновления на лету? Бандл A Bundle B 77
78. Обновления на лету? А теперь вспомним про циклические зависимости Упражнение: попробуйте обновить SWT бандл у работающего Eclipse A B C D 78
80. Обновления на лету? •  Обновления на лету в OSGi более менее работает, только для листовых бандлов, которые никто не импортирует – плагины 80
81. Обновления на лету? •  Обновления на лету в OSGi более менее работает, только для листовых бандлов, которые никто не импортирует – плагины •  Для реализации плагинов есть гораздо более простые способы, чем OSGi 81
82. Обновления на лету? Даже листовые бандлы не так просто выгрузить из JVM: •  После их выгрузки, принадлежавшие им классы могут остаться жить в JVM – Известная проблема: Classloaders Memory Leak 82
83. Нельзя просто так взять и выгрузить класс из JVM 83
84. Версионирование? 84
85. Версионирование? App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 85
86. Версионирование? App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 86
87. Версионирование? App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 A 87
88. Версионирование? App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 A A 88
89. Версионирование? App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 A A 89
90. Версионирование? App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 A A 90
91. Версионирование? App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 A A 91
92. Версионирование? App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 A A Я - “A”! 92
93. Версионирование? App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 A A Я - “A”! Нет, это я “A”! 93
94. Версионирование? App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 AAAAA! AAAAA! A A 94
96. Loading constraints •  Loading constraints запрещают двум разным классам с одинаковыми именами (fully qualified) появиться в области видимости одного класса 96
97. Loading constraints B.java: class B { T1 f1 = A.f; int f2 = A.m(t2); } A.java: class A { staSc T1 f; staSc int m(T2 t) Если B грузится загрузчиком L1, а A грузится L2, то JVM проверит, что (T1, L1) = (T1, L2) и (T2, L1) = (T2, L2) == 97
98. Версионирование? •  При нарушении loading constraints, JVM кидает java.lang.LinkageError 98
99. Версионирование? •  При нарушении loading constraints, JVM кидает java.lang.LinkageError •  В OSGi эта проблема адресуется с помощью, т.н. uses constraint 99
100. Uses constraints •  Export в OSGi может квалифицироваться директивами use – внешнии пакеты использующиеся экспортируемым пакетом •  если в один бандл пришел по импорту какой-то use-пакет из двух разных бандлов, то этот бандл не загрузится 100
101. Uses constraints •  Export в OSGi может квалифицироваться директивами use – внешнии пакеты использующиеся экспортируемым пакетом •  если в один бандл пришел по импорту какой-то use-пакет из двух разных бандлов, то этот бандл не загрузится 101
102. Проблемы uses constraints •  Use директивы не обязательны в OSGi •  Описывать их руками выше понимания большинства разработчиков •  Если ошибиться в их описании, получишь LinkageError от JVM •  Погуглите по словам OSGI и LinkageError, чтобы оценить масштаб проблемы 102
103. Проблемы uses constraints •  Use директивы не обязательны в OSGi •  Описывать их руками выше понимания большинства разработчиков •  Если ошибиться в их описании, легко получить LinkageError от JVM •  Погуглите по словам OSGI и LinkageError, чтобы оценить масштаб проблемы 103
104. Версионирование? Даже в поставке последних версий Eclipse есть бандлы, в которых есть потенциальные нарушения loading constraints и это никого не волнует! 104
105. Версионирование? Даже, если вам удалось корректно задать use директивы*, то ошибки нарушения uses constraints плохо диагностируемые, лечение – неочевидное: –  h{p://njbartle{.name/2011/09/02/uses- constraints.html * для этого даже есть автоматический инструмент – bnd 105
106. Версионирование? Вывод: OSGi не решает проблему JAR Hell, а переводит ее на новый изощренный уровень. 106
107. Версионирование? Вывод: Не используйте в одном приложении одну и ту же библиотеку разных версий! 107
108. Инкапсуляция? Вопрос: Ну хорошо, проблему инкапсуляции хотя бы OSGi решает? 108
109. ReflecSon – универсальная отмычка против инкапсуляции в Java Инкапсуляция? setAccessible(true) 109
110. Инкапсуляция? Вопрос: Ну хорошо, проблему инкапсуляции хотя бы OSGi решает? Ответ: OSGi не защищает от несанкционированного доступа через ReflecŸon* * можно выставить Security Manager, но вендоры библиотек не могут на это расчитывать 110
111. Ленивый старт? 111
112. Ленивый старт? 112
113. Ленивый старт? Бандл A Бандл B Бандл C Вопрос: В каком порядке активируются эти бандлы? 113
114. Ленивый старт? Порядок активации бандлов в OSGi напрямую зависит от порядка загрузки классов в JVM –  при ленивой активации бандл стартуют из loadClass() загрузчика классов бандла 114
115. Ленивый старт? Порядок активации бандлов в OSGi напрямую зависит от порядка загрузки классов в JVM –  при ленивой активации бандл стартуют из loadClass() загрузчика классов бандла Но порядок загрузки классов в JVM не определен! 115
116. Разрешение символьных ссылок Класс может иметь ссылки на другие классы и поля, методы других классов. JVM может разрешать ссылки: •  Лениво –  ссылки разрешаются при первом доступе •  Энергично –  разрешаются все ссылки какие возможно 116
117. Ленивый старт? Порядок загрузки классов в JVM зависит от схемы разрешения ссылок между классами: ленивой, не всегда ленивой, энергичной. 117
118. Ленивый старт? Активатор бандла B: class B implements BundleAcŸvator { public void start() { assert A.f!= null; } Активатор бандла A: class A implements BundleAcŸvator { staSc T f; public void start() { f = new T(); } } Стандартная ситуация: В думает, что А уже активирован, но по факту А может активироваться позже B 118
119. Ленивый старт? •  Cхема ленивой активации бандлов в OSGi – это мина замедленного действия: – стоит JVM начать разрешать ссылки между классами менее лениво, практически все OSGi приложения, использующую ленивую активацию, перестанут работать 119
120. Почему не OSGi? •  Модульность с циклами •  Hot Redeploy работает только для листьев •  Несколько версий одной библиотеки все еще приводит к проблемам •  Нет защиты деталей реализации библиотек от доступа через ReflecŸon •  Ленивая активация бандлов зависит от схемы разрешения ссылок в JVM 120
121. Jigsaw 121
122. Jigsaw 122
123. Jigsaw vs. OSGi OSGi – динамичен по своей сути – модули появляются только в ран-тайме 123
124. Jigsaw vs. OSGi Jigsaw сразу задумывался статичным. Практически весь JDK tooling знает про модули: –  javac: уважает области видимости в модулях –  jdeps: анализирует зависимости –  jar, jmod: пакуют модули –  jlink: изготавливает финальный образ для развертывания –  java: в рантайме модули конечно тоже есть 124
125. Пример модуля // src/java.sql/module-info.java module java.sql { requires transiSve java.logging; requires transiSve java.xml; exports java.sql; exports javax.sql; exports javax.transacŸon.xa; uses java.sql.Driver; } 125
126. Jigsaw vs. OSGi Jigsaw запрещает циклы в графе зависимостей (явных) Модули импортируют модули, а не пакеты. 126
127. Версионирование В первых драфтах Jigsaw версионирование было (аналогичное OSGi). 127
128. Версионирование В первых драфтах Jigsaw версионирование было (аналогичное OSGi). Но потом от него отказались … 128
129. Версионирование В первых драфтах Jigsaw версионирование было (аналогичное OSGi). Но потом от него отказались … Почему? 129
130. Версионирование Версионирование – немедленное означает: 1 модуль ßà 1 загрузчик классов 130
131. Версионирование Версионирование – немедленное означает: 1 модуль ßà 1 загрузчик классов И в первых версиях Jigsaw так и было! 131
132. Jigsaw и загрузчики Jigsaw – это не только модули, но и разбиение Java платформы на модули. 132
133. Jigsaw и загрузчики Проблема обратной совместимости: По спецификации getClassloader() == null для всех классов платформы. Что противоречит разбиению платформы на модули, где каждый модуль грузится своим загрузчиком 133
134. Jigsaw и загрузчики Проблема обратной совместимости: По спецификации getClassloader() == null для всех классов платформы. Что противоречит разбиению платформы на модули, где каждый модуль грузится своим загрузчиком 134
135. Jigsaw и загрузчики Проблема 2: Как защитить разработчика от нарушения loading constraints? 135
136. Версионирование Еще деталь: импорт в ранних версиях Jigsaw (как и в OSGi) специфицировался не просто версией, а диапазоном версий: –  Модуль мог декларировать, что может работать с зависимостями версий от и до 136
137. Версионирование Проблема 3: Оказалось, что разрешение зависимостей (wiring модулей) от диапазонов версий – это NP полная проблема! –  Сводится к 3-SAT 137
138. Версионирование … после чего версионирование в модульной системе Java приказало долго жить. 138
139. Версионирование … после чего версионирование в модульной системе Java приказало долго жить. Нет версионирования – не нужны загрузчики классов для модулей. 139
140. Jigsaw •  Динамических обновлений нет •  Версионирования нет 140
141. Jigsaw •  Динамических обновлений нет •  Версионирования нет А что тогда есть? 141
142. Jigsaw Mantra Reliable ConfiguraSon Strong EncapsulaSon 142
143. Reliable ConfiguraSon Такая ситуация в Jigsaw просто запрещена! App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 143
144. Reliable ConfiguraSon Такая ситуация в Jigsaw просто запрещена! App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 144
145. Reliable ConfiguraSon Правильная (reliable) конфигурация: App 1.0 Foo 2.5 Bar 3.0 Baz 3.1 145
146. Reliable ConfiguraSon Reliable configuraŸon это: •  Все зависимости модулей удовлетворены •  Нет циклических зависимостей •  Нет модулей экспортирующих одинаковые пакеты (split packages) Свойства проверяются на старте (wiring) 146
147. Strong EncapsulaSon setAccessible(true) 147
148. Strong EncapsulaSon Модули в Java 9 – это first class ciŸzens •  Определяют области видимости –  Через декларируемый эскпорт •  Доступа к не экспортируемой функциональности модуля из вне модуля нет даже через reflecŸon –  Не работает даже setAccessible(true) 148
149. Strong EncapsulaSon Модули в Java 9 – это first class ciŸzens •  Определяют области видимости –  Через декларируемый экспорт •  Доступа к не экспортируемой функциональности модуля из вне модуля нет даже через reflecŸon –  Не работает даже setAccessible(true) 149
150. Strong EncapsulaSon Модули в Java 9 – это first class ciŸzens •  Определяют области видимости –  Через декларируемый экспорт •  Доступа к не экспортируемой функциональности из вне модуля нет даже через reflecŸon –  Не работает даже setAccessible(true) 150
151. И что, у Jigsaw нет проблем? 151
153. Reliable ConfiguraSon? •  В ранних версиях Jigsaw рефлективный доступ между модулями запрещался, если между ними нет явных зависимостей •  Но с уходом загрузчиков из модульной системы от этого пришлось отказаться – так как Class.forName() должен работать по старому 153
154. Reliable ConfiguraSon? •  В ранних версиях Jigsaw рефлективный доступ между модулями запрещался, если между ними нет явных зависимостей •  Но с уходом загрузчиков из модульной системы от этого пришлось отказаться – так как Class.forName() должен работать по старому 154
155. Reliable ConfiguraSon? •  Однако, если у вас возможны рефлективные зависимости, не прописанные явно, где гарантия, что результирующая конфигурация reliable? 155
156. Reliable ConfiguraSon? Split packages запрещены, но как же контейнеры приложений (Tomcat, Java EE)? 156
157. Jigsaw Layers * Для контейнеров приложений введен механизм слоев (Layers): •  Локальная модульная система для каждого приложения в контейнере •  Разные модули с одинаковыми пакетами должны принадлежать разным слоям 157
158. Jigsaw Layers * * Картинка позаимствована из презентации Alex Buckley: Project Jigsaw Under the hood 158
159. Strong EncapsulaSon? 159
160. Strong EncapsulaSon? Платформа разбита на модули: •  Что означает, что приватные API действительно стали приватными 160
161. Strong EncapsulaSon? Платформа разбита на модули: •  Что означает, что приватные API действительно стали приватными •  Но а как же sun.misc.Unsafe ? 161
162. Strong EncapsulaSon? Ok, sun.misc.Unsafe Java сообщество (в неравной борьбе) отстояло! (не надолго) 162
163. Strong EncapsulaSon? А как же Dependency InjecŸon? 163
164. Strong EncapsulaSon? DI frameworks существенно зависят: •  от возможности рефлективного доступа в код, куда они внедряют зависимости •  в том числе в неэкспортируемый код 164
165. Strong EncapsulaSon? module my.module { exports my.module.pack; } 165
166. Strong EncapsulaSon? module my.module { exports my.module.pack; exports my.module.internal.public.morozov; } 166
167. Strong EncapsulaSon? module my.moduleO{ exports my.module.pack; } 167
168. Strong EncapsulaSon? open module my.module { exports my.module.pack; } 168
169. Strong EncapsulaSon? Для DI frameworks введены open modules: •  open module позволяет рефлективный доступ к своей неэкспортированной функциональности 169
170. Strong EncapsulaSon? Open module – это уже не совсем strong encapsulaŸon, но это лучше чем ничего. 170
171. Jigsaw Хорошо, ну а какая мне в конце концов от Jigsaw польза? 171
172. Польза Jigsaw Если все ваши зависимости сейчас перечислены в classpath, то постепенно мигрируя на modulepath вы улучшите архитектуру своего приложения: •  разберетесь с циклами в зависимостях •  split пакетами (уберете jar hell) •  с необоснованным доступом в детали реализации других модулей •  с зависимостями на JDK private API 172
173. Польза Jigsaw Если все ваши зависимости сейчас перечислены в classpath, то постепенно мигрируя на modulepath вы улучшите архитектуру своего приложения: •  разберетесь с циклами в зависимостях •  split пакетами (уберете jar hell) •  с необоснованным доступом в детали реализации других модулей •  с зависимостями на JDK private API 173
174. Польза Jigsaw Если все ваши зависимости сейчас перечислены в classpath, то постепенно мигрируя на modulepath вы улучшите архитектуру своего приложения: •  разберетесь с циклами в зависимостях •  split пакетами (уберете jar hell) •  с необоснованным доступом в детали реализации других модулей •  с зависимостями на JDK private API 174
175. Польза Jigsaw Если все ваши зависимости сейчас перечислены в classpath, то постепенно мигрируя на modulepath вы улучшите архитектуру своего приложения: •  разберетесь с циклами в зависимостях •  split пакетами (уберете jar hell) •  с необоснованным доступом в детали реализации других модулей •  с зависимостями на JDK private API 175
176. Польза Jigsaw Если все ваши зависимости сейчас перечислены в classpath, то постепенно мигрируя на modulepath вы улучшите архитектуру своего приложения: •  разберетесь с циклами в зависимостях •  split пакетами (уберете jar hell) •  с необоснованным доступом в детали реализации других модулей •  с зависимостями на JDK private API 176
177. Польза Jigsaw Для миграции на modulepath в Jigsaw придумана целая система: •  Old Classpath образует Unnamed Modulе •  Жары из classpath можно временно переносить в modulepath как Auto Module •  автомодулям можно постепенно добавлять модульную декларацию 177
178. Польза Jigsaw Для миграции на modulepath в Jigsaw придумана целая система: •  Old Classpath образует Unnamed Modulе •  Жары из classpath можно временно переносить в modulepath как Auto Module •  автомодулям можно постепенно добавлять модульную декларацию 178
179. Польза Jigsaw Для миграции на modulepath в Jigsaw придумана целая система: •  Old Classpath образует Unnamed Modulе •  Жары из classpath можно временно переносить в modulepath как Auto Module •  автомодулям можно постепенно добавлять модульную декларацию 179
180. Польза Jigsaw Для миграции на modulepath в Jigsaw придумана целая система: •  Old Classpath образует Unnamed Modulе •  Жары из classpath можно временно переносить в modulepath как Auto Module •  автомодулям можно постепенно добавлять модульную декларацию 180
181. Польза Jigsaw Но, к сожалению, для большинства enterprise Java разработчиков польза от Jigsaw сомнительна: •  Java EE EE4J стандарты пока не определяют как они собираются взаимодействовать с модульной системой •  Даже стандарт servlet контейнеров не знает пока про модули –  Зависимости в war файлах – это по сути тот же самый classpath! 181
182. Польза Jigsaw Но, к сожалению, для большинства enterprise Java разработчиков польза от Jigsaw сомнительна: •  Java EE EE4J стандарты пока не определяют как они собираются взаимодействовать с модульной системой •  Даже стандарт servlet контейнеров не знает пока про модули –  Зависимости в war файлах – это по сути тот же самый classpath! 182
183. Jigsaw в enterprise Тем не менее, для enterprise разработки Jigsaw можно уже сейчас использовать: •  В Tomcat и Je{y embedded и других фреймворках живущих на classpath (Play) –  если все зависимости живут в classpath, то можно мигрировать на module path •  Можно форкнуть ваш любимый app server, добавив модульный слой в его загрузчик приложений –  пример: h{ps://github.com/pjBooms/tomcat 183
185. Заключение •  OSGi – милая попытка дать разработчикам модули –  но к сожалению в OSGi есть много проблем –  в том числе фундаментальных •  Jigsaw – тщательно продуманная система без видимых фундаментальных проблем –  но с системой сдержек и противовесов –  есть проблемы принятия сообществом 185
186. Вопросы и ответы Никита Липский, Excelsior nlipsky@excelsior-usa.com twi{er: @pjBooms Team blog: h{ps://www.excelsiorjet.com/blog 186