Java 9 Modules: The Duke Yet Lives That OSGi Shall Depose
Download as PPTX, PDFβ’4 likesβ’1,746 views
The document discusses the comparison between OSGi and Java 9's Jigsaw module system, highlighting OSGi's advantages like modularity, encapsulation, and hot redeploy capabilities, while pointing out its limitations such as issues with cyclic dependencies and loading constraints. It also emphasizes that Jigsaw is static compared to OSGi's dynamic nature and cites reasons why Jigsaw is not a comprehensive replacement for OSGi. The document presents technical details on versioning, bundle lifecycle, and encapsulation in the context of both module systems.
Java 9 Modules: The Duke Yet Lives That OSGi Shall Depose
- 1. Java 9 Modules. The Duke Yet Lives That OSGi Shall Depose Nikita Lipsky Excelsior LLC 1
- 2. 2
- 6. OSGi 6
- 7. Why Jigsaw is not OSGi? Mark Reinhold (the Chief Architect of the Java Platform Group): ββ¦As it (OSGi) stands, moreover, itβs useful for library and application modules but, since itβs built strictly on top of the Java SE Platform, it canβt be used to modularize the Platform itselfβ 7
- 8. Why Jigsaw is not OSGi? Question: why the presence of j.l.Object in Java Language Specification, implemented in Java in turn, does not lead to a bootstrap problem? Π€Π°ΠΊΡ: Π‘ΡΡΠ΅ΡΡΠ²ΡΠ΅Ρ ΡΠ΅Π°Π»ΠΈΠ·Π°ΡΠΈΡ Java SE, Π³Π΄Π΅ OSGi ΠΏΠΎΠ΄Π΄Π΅ΡΠΆΠΈΠ²Π°Π΅ΡΡΡ Π½Π° ΡΡΠΎΠ²Π½Π΅ JVM (Π½Π° ΡΡΠΎΠ²Π½Π΅ ΠΏΠ»Π°ΡΡΠΎΡΠΌΡ). 8
- 9. Why Jigsaw is not OSGi? Question: why the presence of j.l.Object in Java Language Specification, implemented in Java in turn, does not lead to a bootstrap problem? Fact: There is a Java SE implementation that supports OSGi at the JVM level (at the platform level). 9
- 10. Nikita Lipsky β’ 20+ years in software development β’ Excelsior JET project initiator β 16+ years of contributions β compiler engineer β team lead β product lead β etc. β’ Twitter: @pjBooms 10
- 11. Excelsior JET? β’ AOT-centric Java SE implementation β certified as Java Compatible since 2005 β’ AOT compiler + Java Runtime β mixed compilation: AOT + JIT β AOT support for custom classloaders (Eclipse RCP, Tomcat) β’ Toolkit β Startup Optimizer β Deployment 11
- 12. Agenda β’ Why OSGi β’ How OSGi does it β’ Why NOT OSGi β’ Why Jigsaw is not OSGi β’ Jigsaw mantra β’ Jigsaw problems 12
- 13. Where OSGi? Standardized by OSGi Alliance (IBM, Adobe, Bosch, Huawei, NTT, OraΡle) Implementations: β’ Equinox β Eclipse IDE, Eclipse RCP, IBM Websphere β’ Apache Felix β Oracle WebLogic, Glassfish, Netbeans 13
- 14. Why OSGi? 14
- 15. Why OSGi? β’ Modularity β Reduced complexity β Hide internals (encapsulation) β Dependency management and easy deployment β’ Dynamic updates β’ Versioning β’ Lazy β’ Simple, fast, small, secure, etc. https://www.osgi.org/developer/benefits-of-using-osgi/ 15
- 17. OSGi Module System OSGi module β Bundle: β’ Jar or directory β’ Import/export is defined in 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)β 17
- 18. OSGi Module System β’ OSGi bundle imports/exports β packages (Import-Package/Export-Package) β services (Import-Service/Export-Service). β’ May import other bundles directly β Require-Bundle directive β However it is not the best practice (less flexible) 18
- 19. OSGi Module System 19 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
- 20. OSGi Runtime β’ Resolves Import/Export of OSGi bundles (wiring) β’ Defines bundle life cycle β May start (activate) bundles lazily β Enables on-the-fly bundle updates without system restart (aka hot redeploy). 20
- 22. Versioning in OSGi β’ OSGI resolves JAR hell: β import/export is qualified by version β If two bundles require a library bundle of two different versions, both versions will be loaded 22
- 23. Why OSGi? So, OSGi promises: β’ Modularity β explicit dependencies β encapsulation β’ JAR Hell problem resolution β via versioning β’ Hot ReDeploy β via ability to update a separate bundle dynamically 23
- 24. Why OSGi? So, OSGi promises: β’ Modularity β explicit dependencies β encapsulation β’ JAR Hell problem resolution β via versioning β’ Hot ReDeploy β via ability to update a separate bundle dynamically 24
- 25. Why OSGi? So, OSGi promises: β’ Modularity β explicit dependencies β encapsulation β’ JAR Hell problem resolution β via versioning β’ Hot ReDeploy β via ability to update a separate bundle dynamically 25
- 26. Why OSGi? So, OSGi promises: β’ Modularity β explicit dependencies β encapsulation β’ JAR Hell problem resolution β via versioning β’ Hot ReDeploy β via ability to update a separate bundle dynamically 26
- 27. 27
- 28. How OSGi? 28
- 29. Versioning in OSGi Question: How to implement versioning? Task: For given A module importing Lib (v1) library, and B module importing Lib (v2), it is required that both versions of Lib working without conflicts. Solution: load the versions of the library by different classloaders. 29
- 30. Versioning in OSGi Question: How to implement versioning? Task: For a given module A importing library Lib (v1), and module B importing Lib (v2), it is required that both versions of Lib work without conflicts. Solution: load the versions of the library by different classloaders. 30
- 31. Versioning in OSGi Question: How to implement versioning? Task: For a given module A importing library Lib (v1), and module B importing Lib (v2), it is required that both versions of Lib work without conflicts. Solution: load versions of the library by different classloaders. 31
- 32. Versioning in OSGi Thus each OSGi bundle is loaded by its own classloader: β’ Subtype of java.lang.ClassLoader β’ Unique class namespace β’ No conflicts with classes of other bundles 32
- 33. Versioning in OSGi 33 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 Different versions of apache commons may simultaneously present in the JVM Each bundle has its own classloader
- 35. Encapsulation in 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 { } How to make the class B inaccessible from outside? 35
- 36. Encapsulation in OSGi Question: how to make an internal class of a module declared public inaccessible outside? 36
- 37. Encapsulation in OSGi Question: how to make an internal class of a module declared public inaccessible outside? Answer: classloaders (!) may hide internal classes. 37
- 38. Dynamic Updates Task: update one (!) changed bundle in a running program without stopping it 38
- 39. Dynamic Updates Task: update one (!) changed bundle in a running program without stopping it Solution: CLASSLOADERS! (unload old bundle, load new bundle by a new classloader) 39
- 41. Lazy start Start of bundles in OSGi is implemented via the bundle activators feature: β’ Each bundle may have an activator β Bundle-Activator manifest directive β Implementation of an interface with methods start(), stop() β Static class initializer analogue for bundles 41
- 42. Lazy start Start of bundles in OSGi is implemented via the bundle activators feature: public interface BundleActivator { void start(BundleContext context) throws Exception; void stop(BundleContext context) throws Exception; } 42
- 43. Lazy start β’ Bundle start can be defined by OSGi configuration β’ Otherwise the bundle starts when it is required by other started bundles 43
- 44. Lazy start Task: start (load) bundles only when they become needed for program execution 44
- 45. Lazy start Solution: CLASSLOADERS (again!) in OSGi invoke the start()method of the bundle activator right before loading of the first class of a bundle Since classloading in the JVM is lazy, bundle activation becomes lazy AUTOMATICALLY 45
- 46. Lazy start Solution: CLASSLOADERS (again!) in OSGi invoke the start()method of the bundle activator right before loading of the first class of a bundle Since classloading in the JVM is lazy, bundle activation becomes lazy AUTOMATICALLY 46
- 47. Lazy start Solution: CLASSLOADERS (again!) in OSGi invoke the start()method of the bundle activator right before loading of the first class of a bundle Since classloading in the JVM is lazy, bundle activation becomes lazy AUTOMATICALLY 47
- 48. How OSGi? All solved in one fell swoop! 48
- 49. 49
- 50. Why Not OSGi? 50
- 52. Modularity? Bundle A Bundle B Bundle C 52
- 53. Modularity? Bundle A Bundle B Bundle C Bundle D 53
- 54. Modularity? Bundle A Bundle B Bundle C Bundle D 54
- 55. Modularity? Bundle A Bundle B Bundle C Bundle D 55
- 56. Modularity? Bundle A Bundle B Bundle C Bundle D 56
- 57. Modularity? OSGI allows cycles in the dependency graph Exercise: understand, why that is bad A B C D 57
- 58. On the fly updates? 58
- 59. On the fly updates? Bundle ABundle B 59
- 60. On the fly updates? Bundle ABundle B Letβs update bundle B 60
- 61. On the fly updates? Bundle ABundle B 61
- 62. On the fly updates? Bundle A Bundle B 62
- 63. On the fly updates? Bundle A NEW Bundle B 63
- 64. On the fly updates? Bundle ANEW Bundle B 64
- 65. On the fly updates? Bundle ABundle B Does it work for bundle A? 65
- 66. On the fly updates? Bundle B Class B Bundle A Class Π 66
- 67. On the fly updates? Bundle B Class B Bundle A Class Π If bundle B imports bundle Π then there is a class from B that references a class from A 67
- 68. Symbolic references resolution B.java: class B { A useA; int f1 = A.f; int f2 = A.foo(); } A.java: class A { static int f; static int foo(){}; } 68
- 69. Symbolic references resolution 69 B.class β¦ CONSTANT_Class: A CONSTANT_FieldRef: A.f@int CONSTANT_MethodRef: A.foo()I β¦ A.class β¦ Field: f@int Method: foo()I β¦
- 70. Symbolic references resolution β’ A class references other classes and their fields/methods symbolically 70
- 71. Symbolic references resolution β’ A class references other classes and their fields/methods symbolically β’ JVM resolves those symbolic references with real values at runtime 71
- 72. Symbolic references resolution β’ A class references other classes and their fields/methods symbolically β’ JVM resolves those symbolic references with real values at runtime β’ Once a reference is resolved, the value of the reference is never changed! 72
- 73. On the fly updates? β’ If a reference from a class B to a class A is resolved then the class Π cannot be unloaded from the JVM without unloading the class B 73
- 74. On the fly updates? β’ If a reference from a class B to a class A is resolved then the class Π cannot be unloaded from the JVM without unloading the class B β’ Hence if a bundle Π imports a bundle Π then the bundle Π cannot be unloaded without also unloading the bundle B 74
- 75. On the fly updates? Bundle ABundle B Letβs update bundle A 75
- 76. On the fly updates? Bundle ABundle B 76
- 77. On the fly updates? Bundle A Bundle B 77
- 78. On the fly updates? ΠΠ°Π½Π΄Π» ABundle B 78
- 79. On the fly updates? Now letβs remember cyclic dependencies Exercise: try to update SWT bundle in running Eclipse A B C D 79
- 80. 80
- 81. On the fly updates? β’ On the fly updates in OSGi work, more or less, only for leaf bundles that are not imported by other bundles β plugins 81
- 82. On the fly updates? β’ On the fly updates in OSGi work, more or less, only for leaf bundles that are not imported by other bundles β plugins β’ There are much simpler ways than OSGi to implement plugins 82
- 83. On the fly updates? Even leaf bundles are not so easy to unload from the JVM: β’ The classes from leaf bundles can live in the JVM after their unloading β Known problem: Classloaders Memory Leak 83
- 84. One does not simply unload a class from the JVM 84
- 85. Versioning? 85
- 94. Versioning? App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 A A Iβm βAβ! No, Iβm βAβ! 94
- 96. 96
- 97. Loading constraints β’ Loading constraints prohibit two classes with the same fully qualified name to appear in the namespace of another class 97
- 98. Loading constraints B.java: class B { T1 f1 = A.f; int f2 = A.m(t2); } A.java: class A { static T1 f; static int m(T2 t) If B is loaded by L1 classloader and A is loaded by L2 then the JVM will check that (T1, L1) = (T1, L2) and (T2, L1) = (T2, L2) == 98
- 99. Versioning? β’ JVM throws java.lang.LinkageError on loading constraints violation 99
- 100. Versioning? β’ JVM throws java.lang.LinkageError on loading constraints violation β’ OSGi DOES NOT help developers to avoid loading constraints violation β Just google for βOSGIβ and βLinkageErrorβ to estimate the scale of the problem 100
- 101. Versioning? There are bundles in the latest Eclipse versions with potential loading constraints violations and nobody cares! 101
- 102. Versioning? Conclusion: OSGi does not solve JAR Hell but raises it to a new, more sophisticated level. 102
- 103. Versioning? Conclusion: Do not use two different versions of the same library in one application! 103
- 104. Encapsulation? Question: well, at least the encapsulation problem is solved by OSGi, right? 104
- 105. Reflection β universal countermeasure against encapsulation in Java Encapsulation? setAccessible(true) 105
- 106. Encapsulation? Question: well, at least the encapsulation problem is solved by OSGi, right? Answer: OSGi does not protect from unauthorized access via Reflection 106
- 107. Lazy start? 107
- 108. Lazy start? 108
- 109. Lazy start? Bundle A Bundle B Bundle C Question: in what order the bundles will be activated? 109
- 110. Lazy start? Bundle activation order in OSGi depends on classloading order directly β A bundle is started from loadClass() of the bundle classloader 110
- 111. Lazy start? Bundle activation order in OSGi depends on classloading order directly β A bundle is started from loadClass() of the bundle classloader However, class loading order is not defined by the JVM specification! 111
- 112. Symbolic references resolution A class may reference other classes and their fields/methods symbolically. A JVM may resolve references: β’ Lazily β Each reference is resolved on first access β’ Eagerly β All references are resolved at the time of class loading 112
- 113. Lazy start? The classloading order depends on the class reference resolution scheme in the given JVM implementation: lazy, less lazy, eager. 113
- 114. Lazy start? Bundle B activator: class B implements BundleActivator { public void start() { assert A.f!= null; } Bundle A activator: class A implements BundleActivator { static T f; public void start() { f = new T(); } Typical case: Π thinks that Π is already activated, but in fact Π can be activated after B, so assertion fails 114
- 115. Lazy start? β’ Bundle activation scheme in OSGi is a time bomb: β If the JVM starts to resolve class references less lazily, practically all OSGi applications will stop working 115
- 116. Why NOT OSGi? β’ Modularity with cycles β’ Hot Redeploy works for leaf bundles only β’ No protection from loading constraints violation β’ No protection of implementation details from reflective access β’ Bundle activation order depends substantially on class reference resolution scheme 116
- 117. Jigsaw 117
- 118. Jigsaw 118
- 119. Jigsaw vs. OSGi OSGi is dynamic essentially β modules appear at run time only 119
- 120. Jigsaw vs. OSGi Jigsaw was thought up as static from the beginning. Practically all JDK tools know about modules: β javac: respects modules visibility rules β jdeps: analyses dependencies β jar, jmod: pack modules β jlink: prepares final image for deployment β java: there are modules in runtime as well 120
- 121. Module example // src/java.sql/module-info.java module java.sql { requires transitive java.logging; requires transitive java.xml; exports java.sql; exports javax.sql; exports javax.transaction.xa; uses java.sql.Driver; } 121
- 122. Jigsaw vs. OSGi Jigsaw prohibits (explicit) cycles in the dependency graph Modules import modules and not packages. 122
- 123. Versioning There was versioning in the first drafts of Jigsaw (similar to OSGi). 123
- 124. Versioning There was versioning in the first drafts of Jigsaw (similar to OSGi). However versioning was removed later β¦ 124
- 125. Versioning There was versioning in the first drafts of Jigsaw (similar to OSGi). However versioning was removed later β¦ Why? 125
- 126. Versioning Versioning immediately means: 1 module οο 1 classloader 126
- 127. Versioning Versioning immediately means: 1 module οο 1 classloader It was exactly so in the first Jigsaw drafts! 127
- 128. Jigsaw and classloaders Jigsaw is not just modules, but also the Java SE platform split into modules. 128
- 129. Jigsaw and classloaders Backward compatibility problem: According to the specification getClassloader() == null for core platform classes.ΡΠΎ ΠΏΡΠΎΡΠΈΠ²ΠΎΡΠ΅ΡΠΈΡ That precludes splitting of the platform into modules, with each module loaded by its loader 129
- 130. Jigsaw and classloaders Backward compatibility problem: According to the specification getClassloader() == null for core platform classes.ΡΠΎ ΠΏΡΠΎΡΠΈΠ²ΠΎΡΠ΅ΡΠΈΡ That precludes splitting of the platform into modules, with each module loaded by its loader 130
- 131. Jigsaw and classloaders Problem 2: How to protect developers from loading constraints violation? 131
- 132. Versioning Another detail: import in early Jigsaw versions (as in OSGi) was qualified by not a single version but by Π° version range: β A module may declare that it can work with a dependency of βfromβ version to βtoβ version 132
- 133. Versioning Problem 3: Resolving dependencies (wiring modules) from version ranges is an NP-complete problem! β Reduced to 3-SAT 133
- 134. Versioning β¦ after that versioning in JPMS breathed its last. 134
- 135. Versioning β¦ after that versioning in JPMS breathed its last. No versioning β no classloaders for modules. 135
- 136. Jigsaw β’ No dynamic updates β’ No versioning 136
- 137. Jigsaw β’ No dynamic updates β’ No versioning So what does it have? 137
- 139. Reliable Configuration Π’Π°ΠΊΠ°Ρ ΡΠΈΡΡΠ°ΡΠΈΡ Π² Jigsaw ΠΏΡΠΎΡΡΠΎ Π·Π°ΠΏΡΠ΅ΡΠ΅Π½Π°! App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 139
- 140. Reliable Configuration Jigsaw simply prohibits this situation! App 1.0 Foo 2.0 Bar 3.0 Baz 2.1 Baz 3.1 140
- 141. Reliable Configuration Right (reliable) configuration: App 1.0 Foo 2.5 Bar 3.0 Baz 3.1 141
- 142. Reliable Configuration Reliable configuration: β’ All module dependencies are resolved β’ No cyclic dependencies β’ No modules containing the same packages (split packages) These properties are checked at startup (wiring) 142
- 144. Strong Encapsulation Java 9 modules are first class citizens β’ Define visibility access rules β via declared export β’ There is no access to non-exported functionality outside of the module even via reflection β Even setAccessible(true) does not work 144
- 145. Strong Encapsulation Java 9 modules are first class citizens β’ Define visibility access rules β via declared export β’ There is no access to non-exported functionality outside of the module even via reflection β Even setAccessible(true) does not work 145
- 146. Strong Encapsulation Java 9 modules are first class citizens β’ Define visibility access rules β via declared export β’ There is no access to non-exported functionality outside of the module even via reflection β Even setAccessible(true) does not work 146
- 147. So Jigsaw does not have problems? 147
- 148. 148
- 149. Reliable Configuration? β’ Reflective access was prohibited between modules without explicit dependencies in early Jigsaw drafts β’ However it had to be relaxed when classloaders had gone from JPMS β because Class.forName() has to work backward compatible 149
- 150. Reliable Configuration? β’ Reflective access was prohibited between modules without explicit dependencies in early Jigsaw drafts β’ Had to be relaxed when classloaders had gone from JPMS β because Class.forName() had to remain backward compatible 150
- 151. Reliable Configuration? However if you may have reflective dependencies that are not explicitly declared, where is the guarantee that the resulting configuration is reliable? 151
- 152. Reliable Configuration? Split packages are prohibited, but what about application containers (Tomcat, Java EE)? 152
- 153. Jigsaw Layers * To solve the application containers problem Layers feature was introduced in JPMS: β’ Local module system for each application in a container β’ Two modules containing the same package have to belong to different layers 153
- 154. Jigsaw Layers * * The picture is from Alex Buckleyβs presentation: Project Jigsaw Under the hood 154
- 156. Strong Encapsulation? The platform is split into modules: β’ Which means that private APIs become really private 156
- 157. Strong Encapsulation? The platform is split into modules: β’ Which means that private APIs become really private β’ But what about sun.misc.Unsafe ? 157
- 158. Strong Encapsulation? Ok, Java community (temporarily) defended sun.misc.Unsafe (in an unequal fight)! 158
- 159. Strong Encapsulation? But what about Dependency Injection? 159
- 160. Strong Encapsulation? DI frameworks essentially depend on: β’ reflective access to the code in which they inject dependencies β’ including non-exported code 160
- 161. Strong Encapsulation? module my.module { exports my.module.pack; } 161
- 162. Strong Encapsulation? module my.module { exports my.module.pack; exports my.module.internal.object.orgy; } 162
- 163. Strong Encapsulation? module my.moduleO{ exports my.module.pack; } 163
- 164. Strong Encapsulation? open module my.module { exports my.module.pack; } 164
- 165. Strong Encapsulation? Open modules were introduced to solve the DI frameworks problem: β’ An open module allows reflective access to its non-exported functionality 165
- 166. Strong Encapsulation? Open modules provide not-so-strong encapsulation, but it is better than nothing. 166
- 167. Jigsaw Well, but what benefits me in Jigsaw at last? 167
- 168. Jigsaw benefits If all your dependencies are on the classpath now, migrating to the modulepath would improve the architecture of your application by eliminating: β’ cycles in the dependencies β’ split packages (jar hell) β’ unsound access into implementation details of other modules β’ dependencies to JDK private API 168
- 169. Jigsaw benefits If all your dependencies are on the classpath now, migrating to the modulepath would improve the architecture of your application by eliminating: β’ cycles in the dependency graph β’ split packages (jar hell) β’ unsound access into implementation details of other modules β’ dependencies to JDK private API 169
- 170. Jigsaw benefits If all your dependencies are on the classpath now, migrating to the modulepath would improve the architecture of your application by eliminating: β’ cycles in the dependency graph β’ split packages (jar hell) β’ unsound access into implementation details of other modules β’ dependencies to JDK private API 170
- 171. Jigsaw benefits If all your dependencies are on the classpath now, migrating to the modulepath would improve the architecture of your application by eliminating: β’ cycles in the dependency graph β’ split packages (jar hell) β’ unsound reliance upon implementation details of other modules β’ dependencies to JDK private API 171
- 172. Jigsaw benefits If all your dependencies are on the classpath now, migrating to the modulepath would improve the architecture of your application by eliminating: β’ cycles in the dependency graph β’ split packages (jar hell) β’ unsound reliance upon implementation details of other modules β’ dependencies on JDK private APIs 172
- 173. Jigsaw benefits Jigsaw introduces a migration path to the modulepath: β’ Old classpath forms Unnamed ModulΠ΅ β’ Jars from classpath may be temporally moved as is to modulepath as Auto Modules β’ Module declaration can be added to auto modules later 173
- 174. Jigsaw benefits Jigsaw introduces a migration path to the modulepath: β’ Old classpath forms Unnamed Module β’ Jars from classpath may be temporally moved as is to modulepath as Auto Modules β’ Module declaration can be added to auto modules later 174
- 175. Jigsaw benefits Jigsaw introduces a migration path to the modulepath: β’ Old classpath forms Unnamed ModulΠ΅ β’ Jars from classpath may be temporarily moved βas-isβ to modulepath as Auto Modules β’ Module declaration can be added to auto modules later 175
- 176. Jigsaw benefits Jigsaw introduces a migration path to the modulepath: β’ Old classpath forms Unnamed ModulΠ΅ β’ Jars from classpath may be temporarily moved βas-isβ to modulepath as Auto Modules β’ Module declaration can be added to auto modules later 176
- 177. Jigsaw benefits Unfortunately, most Java developers wonβt benefit from JPMS immediately: β’ Java EE standards do not define how they will interoperate with JPMS yet β’ Even servlet containers standard knows nothing about modules so far β Dependencies in war ΡΠ°ΠΉΠ»Π°Ρ are essentially old plain classpath! 177
- 178. Jigsaw benefits Unfortunately, most Java developers wonβt benefit from JPMS immediately: β’ Java EE standards do not define how they will interoperate with JPMS yet β’ Even the servlet container standard knows nothing about modules so far β Dependencies in war files are old plain classpath in fact! 178
- 179. The birth is inevitable! 179
- 180. Conclusion β’ OSGi is a nice attempt to give modules to Java developers β but OSGi has many problems unfortunately β including fundamental β’ Jigsaw is a carefully designed system without visible fundamental problems β but with a system of checks and balances β there are community acceptance problems 180
- 181. Q & A Nikita Lipsky, Excelsior [email protected] twitter: @pjBooms 181