Java Core | Java 8 and OSGi Modularisation | Tim Ellison & Neil Bartlett
0 likes1,646 views
The document discusses the introduction of a module system in Java 8, highlighting its need for managing complexity in the Java Runtime Environment (JRE) and improving software engineering practices. It contrasts the new modularization approach with the existing OSGi framework, addressing issues like dependency management and platform-specific code handling. The document concludes with insights on the interoperation between Jigsaw (the new module system) and OSGi, aiming to leverage the strengths of both systems.
More Related Content
Similar to Java Core | Java 8 and OSGi Modularisation | Tim Ellison & Neil Bartlett (20)
Java Core | Java 8 and OSGi Modularisation | Tim Ellison & Neil Bartlett
- 1. Java 8 and OSGi modularization Tim Ellison, IBM UK Labs Neil Bartlett, Paremus Ltd
- 2. What is a module? Why do we need a module system? • Modules facilitate software engineering & enhanced runtime capabilities – Decomposition of complex systems – Software assemblies of pre-built modules – Provisioning / deployment, including module repositories – Versioning and configuration management • The module system is used to manage the modules, including installing, activating, resolving module requirements and conflicts. • Interacting with the module system provides a higher level abstraction than the language provides directly. 2
- 3. Modules in Java • The module as a unit of encapsulation... • The Java language already has two kinds of module: classes and packages. – classes encapsulate fields and methods – packages encapsulate classes and resources • Problem: neither of these is a deployable unit (too granular, too tightly coupled). • Java's unit of deployment is the JAR file. – No encapsulation, therefore not a module! • Problem: need an entity that is a deployable unit of encapsulation. 3
- 4. Desirable characteristics of a module • A module should be highly coherent. • A module should be loosely coupled to other modules. • A module should be explicit about what it provides to other modules. • A module should be explicit about what it depends on from other modules. 4
- 5. Why modules for the Java runtime (JRE)? • Presently the JRE is a monolithic entity – in general the runtime must assume your application will use anything and everything – class loaders provide runtime type definition and isolation – download time and start-up time are directly impacted by the number of types available in the runtime • Application start-up time includes a linear search through the class path to find system and application code – e.g. Oracle 1.7 Windows bootclass path contains nearly 20k classes – resources.jar rt.jar jsse.jar jce.jar charsets.jar – rt.jar index alone is ~1Mb • To the JRE, your application's jars’ indexes are disjoint & unsorted – there are JRE implementation 'tricks' like look aside tables and shared classes that can help – class loading is a BIG time hog to amortize over the length of the run 5
- 6. Why modules for the Java runtime (JRE)? - cont. • Dependency management – avoid “JAR hell” → trying satisfy competing requirements by simple path ordering – type name space comprising (unversioned) package name is often insufficient – e.g. my app depends upon foo-v2.jar and bar-v2.jar but foo-v2.jar depends upon bar-v1.jar -classpath foo-v2.jar; bar-v2.jar; bar-v1.jar –> my app “wins” -classpath foo-v2.jar; bar-v1.jar; bar-v2.jar –> foo “wins” • Module level visibility – public, protected, private and package-private level visibility means some implementation types (com.sun.) need to be marked public to be called by java. APIs. – convention asks people not to depend upon them... – • Version control – ability to define the compatibility of a module based on numbering scheme – different module versions for different target devices / resource goals 6
- 7. Introducing Project Jigsaw • Project Jigsaw is an effort at OpenJDK – defining a simple module system for Java – modularizing the JRE itself – originally intended as an implementation detail for the JRE / applications, but being adopted as a Java standard (JSR) • Working within constraints of backwards compatibility – existing Java APIs “cannot” be changed – Some packages contain wildly different functionality e.g. java.util contains collection hierarchy and Locale infrastructure • Introduces language changes to define modules src/com/example/myclass.java src/com/example/myclassimpl.java src/module-info.java module com.example @ 1.0 { requires jdk.base; requires foo @ 2.0; requires bar @ 2.0; } 7
- 8. What about OSGi? • Existing, mature, de facto modularity solution for Java applications. • Rich modularity model based on code-level (package) dependencies, module-level dependencies, and services. • First practical solution for effective component reuse – well supported by multiple implementations, tooling, etc. • Millions use applications built with OSGi – most application servers are based on OSGi Bundle-ManifestVersion: 2 • No language changes. Bundle-SymbolicName: com.ex.mybundle Bundle-Version: 1.0.0 – defines info in META-INF/MANIFEST.MF Import-Package: com.example.bar Export-Package: com.example.foo 8
- 9. Module dependency resolution • The module system must resolve bundle dependencies, possibly in the face of multiple valid alternatives – e.g. my app depends upon (foo-v2.jar and (bar-v1.jar or bar-v2.jar)) and foo-v2.jar depends upon bar-v1.jar – if my app touches bar first, the module system may chose bar-v2.jar – if my app touches foo first, the module system will chose bar-v1.jar • OSGi's dynamic dependency resolution always finds the best fit for currently invoked bundles at runtime – Modules are apparent at runtime – Runtime activation lifecycle: installed, resolved, starting, active, stopping, uninstalled • Jigsaw resolves module dependencies during build, installation, or runtime – Gives opportunity for load time optimizations such as pre-verify, indexing, etc. 9
- 10. OSGi Dependency Model • OSGi best practice is to depend on APIs. • APIs are defined in terms of packages. • Read almost any JSR. It defines the package(s) that the JSR specifies, e.g.: – JSR 112 → javax.resource.spi, cci – JSR 173 → javax.xml.stream – JSR 315 → javax.servlet (3.0) 10
- 11. OSGi: As Simple As Possible... • The primary unit of sharing is the package. • Bundle A exports a package – Export-Package: api • Bundle B imports a package – Import-Package: api 11
- 12. But No Simpler! • Module-to-module dependencies also supported – Require-Bundle: A • Most OSGi devs consider Require-Bundle to be deprecated. 12
- 15. Import-Package vs Require-Bundle • Import-Package directly reflects reality • Can be derived straight from the code! • Require-Bundle is a parallel dependency system => manually maintained, hard to statically verify. 15
- 16. Don't Split the Packages! • In OSGi, the package is king. • Import-Package will resolve to exactly one export of that package, and this is a good thing!! • Require-Bundle can be used when packages are split for legacy/stupid reasons. 16
- 17. More On Split Packages • Java packages were never meant to be split across deployment units. • Even plain Java provides a way to enforce this: Sealed Packages. • You wouldn't split a method across classes... or a class across packages... 17
- 18. Handling platform-specific code • The JRE contains many classes and native code that are specific to an OS / CPU architecture • “Universal modules” – Contain code for all platforms – Requires download of unused code, and new revisions that are not relevant • “Platform-specific sub-modules” – Put platfom-specific code in a separate module – Many of the differences are in the native code only, so requires a native module • “Native package” – Hooks into the OS packaging system, so that dependencies can be handled by the OS (e.g. .deb file) 18
- 19. Handling platform-specific code – OSGi style • OSGi allows you to deliver platform-specific native code in a bundle JAR file. Bundle-NativeCode: libfoo.so; osname=Linux; processor=x86, foo.dll; osname=Windows7; processor=x86 • The OSGi implementation of ClassLoader#findLibrary(“foo”) returns the path to the correct version. • Flexibility to structure as a universal module, or sub-module. http://www.osgi.org/Specifications/Reference 19
- 20. Modularising the JRE • JRE libraries evolved organically (haphazardly!) over 12+ years. • Many cyclic dependencies • Many weird/unexpected dependencies • In particular java.util is an incoherent mess (this always happens to general util packages!) • => Split packages are unavoidable 20
- 21. Can We Use OSGi? • OSGi does support split packages, through Require-Bundle • Works, though considered deprecated. • But that's not the whole story. 21
- 22. Single Boot Classloader Assumption • Many parts of the JRE assume a single boot classloader. • Private package (aka “default”) access assumes whole packages are in single classloader. • Therefore need to split some packages across modules but not across classloaders. => Need to break 1-to-1 module/classloader mapping. 22
- 23. But OSGi Supports Classloader Sharing! • True, through “fragments”. • Fragments share the CL of their “host”. • Dependency is in the “wrong” direction, i.e. fragment depends on host. • Can OSGi be modified to support host-to- fragment dependencies? • Almost certainly! 23
- 24. Refactoring Verboten • Normal and best solution: move classes to the correct, i.e. most logical package. • In the JRE is this impossible! • 9 million developers (Sun estimate, 2009) and billions of apps depend on this library. 24
- 25. Irrelevant Stuff • Let's not worry about: – Format of metadata – Location of metadata – Format of deployable modules • Differences here are surmountable • E.g. OSGi already supports WAR file deployment. 25
- 26. Less Important Stuff • Let's even not worry about versioning right now. • 3 numeric segments vs 20... • Qualifier ordering, snapshots... • Again, we can adapt. 26
- 27. Jigsaw Dependency Model • Modules require other modules by name (and optionally, version) module B @ 1.0 { require A @ [2.0,3.0); } 27
- 28. Jigsaw Dependency Model • Requirements can be “local”. • Target module is loaded in same classloader as present module. module B @ 1.0 { require local A @ [2.0,3.0); } 28
- 29. Jigsaw Dependency Model • Modules list their exports: at package and type level. • May include re-exported contents of required modules module B @ 1.0 { require A @ [2.0,3.0); export org.foo.ClassFoo; export org.bar.* } 29
- 30. Jigsaw Dependency Model • Modules can restrict which other modules are allowed to require them. • Compare: “friend classes” in C++. • Note that the permit clause is un-versioned. module A @ 2.0 { permit B; } 30
- 31. Jigsaw Dependency Model • Modules can logically “provide” other module names. • Compare: “virtual packages” in Debian. • Supports substitution, but unclear how it will support refactoring (splitting/aggregating). module com.ibm.stax @ 1.0 { provide jdk.stax @ 2.0; } 31
- 32. Jigsaw Versions • Jigsaw modules will be versioned • Module requirements use exact version or a range • Versions have no semantics besides ordering 32
- 33. Comparison • Whole-module dependencies are the biggest difference. • Jigsaw will suffer all the same problems seen in OSGi with Require-Bundle. • E.g. Eclipse Core Runtime refactoring hell. • While Jigsaw will achieve JDK modularity it will increase developer maintenance burden. 33
- 34. Both Are Here to Stay! • Try to get the best of both worlds! • OSGi is established and will continue to be used by millions • Jigsaw is underway and a key component in Java 8 plans (Summer 2013) • It need not be a zero-sum game 34
- 35. Project Penrose: Jigsaw / OSGi interop (proposed) • Level 0 : toleration – ensure that OSGi frameworks continue to run unmodified on a Jigsaw enabled runtime – creating modules / bundles that have both Jigsaw & OSGi metadata on the same JAR • Level 1 : interop of module info metadata – teach OSGi to read Jigsaw module info • mapping Jigsaw metadata into OSGi format for the framework to understand, e.g. requires ⇒ Require-Bundle: – resolve Jigsaw modules using the OSGi resolver 35
- 36. Project Penrose: Jigsaw / OSGi interop (proposed) • Level 2 : OSGi implementation exploit of Jigsaw modularity – Enhance OSGi to use Jigsaw publication repositories etc. • Level 3+ : Full interop – A blend of OSGi and Jigsaw cross delegation on module phases OSGi support It must be demonstrated by prototype to be feasible to modify an OSGi micro- kernel such that OSGi bundles running in that kernel can depend upon Java modules. The kernel must be able to load Java modules directly and resolve them using its own resolver, except for core system modules. Core system modules can only be loaded using the module system’s reification API. http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12 36
- 37. Project Penrose: results to date • Level 0 : toleration – ensure that OSGi frameworks continue to run unmodified on a Jigsaw enabled runtime – creating modules / bundles that have both Jigsaw & OSGi metadata on the same JAR • Achievement #1: pass the OSGi tests on a Jigsaw enabled runtime – Equinox 3.7 – the OSGi reference implementation – OSGi 4.3 Compliance Tests – with minor patch for test case error – Windows XP sp3, junit-3.8.2, java6u26, java7-ea-b145 • Achievement #2: run a Java application as either OSGi or Jigsaw modules – Took Java 2D demo – Broke it into multiple functional units, and run the demo as OSGi bundles OR Jigsaw modules 37
- 38. Project Penrose: next steps • Level 1 : interop of module info metadata – teach OSGi to read Jigsaw module info • mapping Jigsaw metadata into OSGi format for the framework to understand, e.g. requires ⇒ Require-Bundle: – resolve Jigsaw modules using the OSGi resolver • Goal #0: move the work into a new OpenJDK project • Goal #1: map Jigsaw module metadata to OSGi equivalents – discussions of how OSGi shall interpret Jigsaw directives • Goal #2: modify OSGi to use Jigsaw reification APIs – load a third-party module from the Jigsaw repository – resolve it using the OSGi resolver 38
- 39. Advice • Stop using internal APIs and implementation classes – You will be broken come Java 8 • If you need a modularity story that works before summer 2013 then the answer is OSGi – OSGi will continue to work beyond Java 7 too so it is the safest option • OSGi has greater expressiveness – While you may not need it now, do you want to change system when you do need it? • Think about how to interoperate with Jigsaw – Be modest in your API usage and we can likely help with a tailored JRE 39
- 40. Questions • Tim Ellison – [email protected] • Neil Bartlett – [email protected] 40