Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

1

Modular Java 
Martin Toshev

2

BG JUG mailing list: 
https://groups.google.com/forum/# 
!forum/bg-jug

3

Agenda 
Modularity 101 
Modularity on top of the platform: OSGi 
Modularity of the platform: Jigsaw 
OSGi and Jigsaw interoperability: Penrose

4

Modularity 101

5

Modularity 101 
Standard Java libraries are modules - Hibernate, 
log4j and any library you can basically think of … 
Build systems like Maven provide transparent 
management of modules

6

Modularity 101 
Benefits of modularization: 
– smaller modules are typically tested easier than a 
monolithic application 
– allows for easier evolution of the system - modules 
evolve independently

7

Modularity 101 
Benefits of modularization: 
– development of the system can be split easier 
between teams/developers 
– increased maintainability of separate modules

8

Modularity 101 
The dependency mechanism used by the JDK 
introduces a number of problems that modular 
systems aim to solve: 
– The "JAR hell" problem caused by shortcomings of the 
classloading process

9

Modularity 101 
The dependency mechanism used by the JDK 
introduces a number of problems that modular 
systems aim to solve: 
– The lack of dynamicity in managing dependent 
modules 
– The lack of loose coupling between modules

10

Modularity 101 
Module systems aim to solve the mentioned 
problems and typically provide: 
• module management 
• module deployment 
• versioning 
• dependency management 
• module repositories 
• configuration management

11

Modularity on top of the 
platform: OSGi

12

Modularity on top of the platform: 
OSGi 
OSGi (Open Service Gateway iniatiave) provides a 
specification for module systems implemented in 
Java 
It is introduced as JSR 8 and JSR 291 to the Java 
platform

13

Modularity on top of the platform: 
OSGi 
Q: So what is an OSGi runtime ?

14

Modularity on top of the platform: 
OSGi 
Q: So what is an OSGi runtime ? 
A: An OSGi runtime (module system) makes use of the Java 
classloading mechanism in order to implement a container for 
modular units (bundles) and is based on the OSGi spec - a series 
of standards by the OSGi Alliance. Many application servers are 
implemented using OSGi as a basis - it is also used in systems 
from a diversity of areas

15

Modularity on top of the platform: 
OSGi 
Q: So what is an OSGi runtime ? 
A: An OSGi bundle is a just a JAR file that contains source code, 
bundle metadata and resources. A bundle may provide various 
services and components to the OSGi runtime. An OSGi runtime 
allows for bundles to be installed, started, stopped, updated and 
uninstalled without requiring a reboot

16

Modularity on top of the platform: 
OSGi 
Q: So what is an OSGi runtime ? 
A: The OSGi Core spec defines a layered architecture that 
determines what is supported by the runtime – each layer 
defines a particular functionality supported by the runtime and 
the bundles 
OSGi logical units: 
 bundles 
 services 
 services registry 
 life-cycle 
 modules 
 security 
 execution environment 
OSGi logical layers:

17

Modularity on top of the platform: 
OSGi 
Q: So what is an OSGi runtime ? 
A: Bundles may export packages for use by other bundles or 
import packages exported by other bundles - this dependency 
mechanism is referred to as wire protocol and is provided by the 
Module layer of OSGi.

18

Modularity on top of the platform: 
OSGi 
Q: So what is an OSGi runtime ? 
A: Bundles may publish services to the runtime and use already 
published services from the runtime – this dependency 
mechanism is provided by the Service layer of OSGI.

19

Modularity on top of the platform: 
OSGi 
Q: So what is an OSGi runtime ? 
A: The MANIFEST.MF file of the bundle’s JAR file describes the 
metadata of the bundle 
Manifest-Version: 1.0 
Bundle-ManifestVersion: 2 
Bundle-Name: Sample 
Bundle-SymbolicName: com.sample 
Bundle-Version: 1.0.0.qualifier 
Bundle-Activator: com.java2days.seminar.demo.Activator 
Bundle-Vendor: java2days 
Require-Bundle: org.java.jigsaw.core, 
org.java.jigsaw.extensions 
Bundle-RequiredExecutionEnvironment: JavaSE-1.7 
Service-Component: OSGI-INF/service.xml 
Import-Package: com.java2days.seminar.jigsaw.shared;version="1.0.0“ 
Export-Package: com.java2days.seminar.demo.utils

20

Modularity on top of the platform: 
OSGi 
Q: So what is an OSGi runtime ? 
A: The runtime may implement extensions based on the OSGi 
Compendium spec that extends the OSGi Core spec. These could 
be:  remote services 
 log service 
 HTTP service 
 device access service 
 configuration admin 
 metatype service 
 preferences service 
 user admin 
 wire admin 
 DMT admin service 
 IO connector service 
 provisioning service 
 UPnP device service 
 configuration admin 
 declarative services 
 event admin service 
 deployment admin 
 XML parser service 
 monitoring service 
 others

21

Modularity on top of the platform: 
OSGi 
OSGi continues to evolve …

22

Live Demo 
Modularity on top of the platform: OSGi

23

Modularity of the platform: 
Jigsaw

24

Modularity of the platform: 
Jigsaw 
When speaking of modularity we should also 
consider the entire runtime (rt.jar) and the JDK core 
libraries … 
… and built-in support for improved "OSGi-like" 
modules in the Java platform

25

Modularity of the platform: 
Jigsaw 
The JDK is monolithic …

26

Modularity of the platform: 
Jigsaw 
JDK 8 compact profiles provide smaller versions … 
(javac -profile <profile_name> or 
make profiles for an OpenJDK build) 
compact 1 compact 2 compact 3

27

Modularity of the platform: 
Jigsaw 
The aim of project Jigsaw is to provide a module 
system for the Java platform 
Although deferred to JDK 9 some additional effort 
such as Compact Profiles and removed/ deprecated 
inter-library dependencies have been introduced in 
JDK8 as an intermediate solution

28

Modularity of the platform: 
Jigsaw 
Modularization of the Java platform is a significant 
change that impacts the entire ecosystem - may 
even break existing projects

29

Modularity of the platform: 
Jigsaw 
Draft 3 of Jigsaw requirements states that 
application using only standard APIs must remain 
compatible 
Draft 3 of Jigsaw requirements also mentions that 
some JDK-specific APIs must remain compatible but 
no concrete JDK APIs are listed yet

30

Modularity of the platform: 
Jigsaw 
Q: So what is exactly project Jigsaw ?

31

Modularity of the platform: 
Jigsaw 
Q: So what is exactly project Jigsaw ? 
A: Jigsaw will provide the basis for a Java Module System JSR. 
Currently work on Jigsaw is being done for: 
JEP 200 - define JDK modules (in a modules.xml file in the JDK repo) 
JEP 201 - reorganize JDK sources into modules and modify JDK build 
JEP 220 - restructure JRE/JDK images to accommodate modules

32

Modularity of the platform: 
Jigsaw 
Q: So what is exactly project Jigsaw ? 
A: Structure of JDK sources as defined by JEP 201: 
old 
src/{share,$OS}/{classes,native}/$PACKAGE/*.{java,c,h,cpp,hpp} 
new 
src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java 
native/include/*.{h,hpp} 
$LIBRARY/*.{c,cpp} 
conf/*

33

Modularity of the platform: 
Jigsaw 
Q: So what is exactly project Jigsaw ? 
A: In the early exploratory phase of project Jigsaw there was a 
proof-of-concept implementation with JDK8 early-access builds 
(now dropped).

34

Modularity of the platform: 
Jigsaw 
Q: So what was exactly the exploratory phase of Jigsaw ? 
A: Jigsaw POC provided a modularized version of JDK along with 
additional tools and language support for creating Jigsaw 
modules. JDK8 early-access builds provided two types of JDK: 
 JDK modules image - all components are preinstalled as 
modules 
 JDK base image + jmod packages - base JDK installation along 
with additional Jigsaw modules of the JDK that can be 
installed on-demand using the jmod tool

35

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module ?

36

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module ? 
A: A collection of Java classes, native libraries and other 
resources along with metadata that provides name and version 
of the module and dependencies on other modules

37

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module ? 
A: Jigsaw resolves modules during build and installation. 
Jigsaw has no dynamics, no module lifecycle. The module system 
assumes the existence of a foundational module named 
java.base

38

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: Module can use ("require") other modules and additionally 
specify version or version ranges for the module dependency - 
modules are loaded with different module classloaders 
module org.bgjug.A @ 1.0 { 
requires org.bgjug.B @ [2.0, 3.0); 
} 
module org.bgjug.A { 
requires org.bgjug.B @ >= 1.0; 
requires org.bgjug.C @ < 2.0; 
}

39

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: Module versions are compared using a similar approach as the 
one used for Debian package versions … The intent is to be able 
to package a module as an OS-specific package (not applicable 
for Windows/Mac OS)

40

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: Modules can also "require" optional modules - meaning that 
compilation succeeds even if the required module is missing 
module org.bgjug.A { 
requires optional jdk-corba@8-ea; 
}

41

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: Modules can also "require" local modules - meaning that the 
local module is a kind of a "mixin" - it is loaded in the same 
classloader as the requiring module 
module org.bgjug.A @ 1.0 { 
requires local org.bgjug.B @ [2.0, 3.0);

42

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: A module may export packages and classes 
module org.bgjug.A @ 1.0 { 
requires org.bgjug.B @ [2.0, 3.0); 
exports org.bgjug.A.seminar.Sample; 
exports org.bgjug.A.seminar.samples.*; 
}

43

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: Modules can explicitly specify which other modules can 
"require" them 
module org.bgjug.A@ 2.0 { 
exports org.bgjug.A.seminar; 
permits org.bgjug.B; 
}

44

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: Modules can logically provide other module names (aliases): 
module com.bgjug.A @ 1.0 { 
provides com.bgjug.First @ 2.0; 
}

45

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: Modules can have a single entry point 
module org.bgjug.A @ 1.0 { 
permits org.bgjug.B; 
class org.bgjug.A.Main; 
} 
the main() method org.bgjug.A.Main is called when invoking: 
java -m org.bgjug.A

46

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: Modules can define multiple views 
module org.bgjug.A { 
exports org.bgjug.A.seminar; 
view org.bgjug.internal.view { 
permits org.bgjug.B 
} 
} 
the main() method org.bgjug.A.Main is called when invoking: 
java -m org.bgjug.A

47

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: A module can declare that it provides a service 
module org.bgjug.A { 
provides service org.bgjug.A.external.TestService with 
org.bgjug.A.external.TestServiceImpl; 
}

48

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: A module can require a service 
module org.bgjug.B { 
requires service org.bgjug.A.external.TestService 
}

49

Modularity of the platform: 
Jigsaw 
Q: What is a Jigsaw module in terms of the exploratory phase ? 
A: A service can also be required optionally 
module org.bgjug.B { 
requires optional service org.bgjug.A.TestService; 
}

50

Modularity of the platform: 
Jigsaw 
Q: So why not adopt OSGi (at least the module layer) for 
modularization of the Java platform ?

51

Modularity of the platform: 
Jigsaw 
Q: So why not adopt OSGi (at least the module layer) for 
modularization of the Java platform ? 
A: As chief architect of the Java platform Mark Reinhold states: 
The OSGI module layer is not operative at compile time - it 
addresses modularity only during packaging, deployment and 
execution. It is also strictly build on top of the platform so it 
cannot be used to modularize it.

52

Modularity of the platform: 
Jigsaw 
Q: So why not adopt OSGi (at least the module layer) for 
modularization of the Java platform ? 
A: However - according to Peter Kriens (former technical director 
at the OSGi Alliance and one of the key drivers behind the OSGi 
spec) Jigsaw is not typically needed an will introduce burden to 
the platform and modules can be introduced much easier: 
The only thing we need to add to the existing system is 
versioning information on the package and record this version in 
the class file

53

Live Demo 
Modularity of the platform: Jigsaw

54

OSGi and Jigsaw interoperability: 
Penrose

55

OSGi and Jigsaw interoperability: 
Penrose 
When speaking of JDK modules we should consider 
interoperability with existing module systems such 
as OSGi 
The purpose of project Penrose is to explore 
interoperability between OSGi and Jigsaw

56

OSGi and Jigsaw interoperability: 
Penrose 
Penrose is still in early stage of development … 
Current work on project Penrose is deprecated due 
to the dropped proof-of-concept version of Jigsaw …

57

OSGi and Jigsaw interoperability: 
Penrose 
Penrose goals: 
– ensuring OSGi frameworks run unmodified in a 
Jigsaw-enabled runtime 
– create modules/bundles that have both OSGi and 
Jigsaw metadata in them 
– Jigsaw metadata can be extended with OSGi concepts 
– extend OSGi to read Jigsaw metadata

58

OSGi and Jigsaw interoperability: 
Penrose 
Penrose goals: 
– mapping Jigsaw metadata to OSGi metadata 
– resolve Jigsaw modules in an OSGi runtime 
– enhance OSGi to use Jigsaw APIs 
– more cross delegation between the two systems …

59

Summary 
Q: Project Jigsaw - when ?

60

Summary 
Q: Project Jigsaw - when ? 
A: Maybe when the Armagedon comes … 
… or maybe in 2016 …

61

Summary 
Q: Projects Jigsaw/Penrose - when ? 
A: Unless you … 
… discuss: 
http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev 
… and code: 
http://hg.openjdk.java.net/jigsaw

62

Q&A 
Thank you 
Bulgarian JUG mailing list: 
https://groups.google.com/forum/#!forum/bg-jug

63

References 
OSGi Alliance 
http://www.osgi.org/Main/HomePage 
Jigsaw Project 
http://openjdk.java.net/projects/jigsaw/ 
Penrose Project 
http://openjdk.java.net/projects/penrose/

64

References 
Modularity - what is it ? 
http://www.infoq.com/articles/modular-java-what- 
is-it/ 
Java modularity - why ? 
http://java.dzone.com/articles/java-modularity- 
2-why 
Java JAR hell problem 
http://en.wikipedia.org/wiki/Java_Classloader#JA 
R_hell

65

References 
Project Jigsaw: Phase Two 
http://mreinhold.org/blog/jigsaw-phase-two 
Project Jigsaw: Goals & Requirements Draft 3 
http://openjdk.java.net/projects/jigsaw/goals-reqs/ 
03

66

References 
Java Module System Requirements 
http://openjdk.java.net/projects/jigsaw/doc/draf 
t-java-module-system-requirements-12 
Project Jigsaw: The Big Picture 
http://cr.openjdk.java.net/~mr/jigsaw/notes/jigs 
aw-big-picture-01 
Java 8 Modules Jigsaw and OSGi 
http://www.slideshare.net/mfrancis/java-8- 
modules-jigsaw-and-osgi-neil-bartlett

67

References 
Project Jigsaw: Late for the train 
http://mreinhold.org/blog/late-for-the-train-qa 
Unbearable lightness of Jigsaw 
http://blog.osgi.org/2011/05/unbearable-lightness- 
of-jigsaw.html 
Netbeans discussion on Jigsaw 
http://wiki.netbeans.org/Jigsaw

68

References 
Java Modularity - OSGi and Project Jigsaw 
http://techdistrict.kirkk.com/2009/06/12/java-modularity- 
osgi-and-project-jigsaw/ 
The Modular Java Platform & Project Jigsaw 
http://www.jfokus.se/jfokus14/preso/Jigsaw.pdf 
JAX 2013: A Project Jigsaw primer 
http://jaxenter.com/a-project-jigsaw-primer- 
50029.html

69

References 
JavaOne 2013: The Modular Java Platform and Project 
Jigsaw 
http://parleys.com/play/52549d02e4b0a43ac12 
124be/about 
OpenJDK Penrose JavaOne 2012 
http://www.slideshare.net/bosschaert/open-jdk-penrose- 
javaone-2012

More Related Content

Modular Java

  • 2. BG JUG mailing list: https://groups.google.com/forum/# !forum/bg-jug
  • 3. Agenda Modularity 101 Modularity on top of the platform: OSGi Modularity of the platform: Jigsaw OSGi and Jigsaw interoperability: Penrose
  • 5. Modularity 101 Standard Java libraries are modules - Hibernate, log4j and any library you can basically think of … Build systems like Maven provide transparent management of modules
  • 6. Modularity 101 Benefits of modularization: – smaller modules are typically tested easier than a monolithic application – allows for easier evolution of the system - modules evolve independently
  • 7. Modularity 101 Benefits of modularization: – development of the system can be split easier between teams/developers – increased maintainability of separate modules
  • 8. Modularity 101 The dependency mechanism used by the JDK introduces a number of problems that modular systems aim to solve: – The "JAR hell" problem caused by shortcomings of the classloading process
  • 9. Modularity 101 The dependency mechanism used by the JDK introduces a number of problems that modular systems aim to solve: – The lack of dynamicity in managing dependent modules – The lack of loose coupling between modules
  • 10. Modularity 101 Module systems aim to solve the mentioned problems and typically provide: • module management • module deployment • versioning • dependency management • module repositories • configuration management
  • 11. Modularity on top of the platform: OSGi
  • 12. Modularity on top of the platform: OSGi OSGi (Open Service Gateway iniatiave) provides a specification for module systems implemented in Java It is introduced as JSR 8 and JSR 291 to the Java platform
  • 13. Modularity on top of the platform: OSGi Q: So what is an OSGi runtime ?
  • 14. Modularity on top of the platform: OSGi Q: So what is an OSGi runtime ? A: An OSGi runtime (module system) makes use of the Java classloading mechanism in order to implement a container for modular units (bundles) and is based on the OSGi spec - a series of standards by the OSGi Alliance. Many application servers are implemented using OSGi as a basis - it is also used in systems from a diversity of areas
  • 15. Modularity on top of the platform: OSGi Q: So what is an OSGi runtime ? A: An OSGi bundle is a just a JAR file that contains source code, bundle metadata and resources. A bundle may provide various services and components to the OSGi runtime. An OSGi runtime allows for bundles to be installed, started, stopped, updated and uninstalled without requiring a reboot
  • 16. Modularity on top of the platform: OSGi Q: So what is an OSGi runtime ? A: The OSGi Core spec defines a layered architecture that determines what is supported by the runtime – each layer defines a particular functionality supported by the runtime and the bundles OSGi logical units:  bundles  services  services registry  life-cycle  modules  security  execution environment OSGi logical layers:
  • 17. Modularity on top of the platform: OSGi Q: So what is an OSGi runtime ? A: Bundles may export packages for use by other bundles or import packages exported by other bundles - this dependency mechanism is referred to as wire protocol and is provided by the Module layer of OSGi.
  • 18. Modularity on top of the platform: OSGi Q: So what is an OSGi runtime ? A: Bundles may publish services to the runtime and use already published services from the runtime – this dependency mechanism is provided by the Service layer of OSGI.
  • 19. Modularity on top of the platform: OSGi Q: So what is an OSGi runtime ? A: The MANIFEST.MF file of the bundle’s JAR file describes the metadata of the bundle Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Sample Bundle-SymbolicName: com.sample Bundle-Version: 1.0.0.qualifier Bundle-Activator: com.java2days.seminar.demo.Activator Bundle-Vendor: java2days Require-Bundle: org.java.jigsaw.core, org.java.jigsaw.extensions Bundle-RequiredExecutionEnvironment: JavaSE-1.7 Service-Component: OSGI-INF/service.xml Import-Package: com.java2days.seminar.jigsaw.shared;version="1.0.0“ Export-Package: com.java2days.seminar.demo.utils
  • 20. Modularity on top of the platform: OSGi Q: So what is an OSGi runtime ? A: The runtime may implement extensions based on the OSGi Compendium spec that extends the OSGi Core spec. These could be:  remote services  log service  HTTP service  device access service  configuration admin  metatype service  preferences service  user admin  wire admin  DMT admin service  IO connector service  provisioning service  UPnP device service  configuration admin  declarative services  event admin service  deployment admin  XML parser service  monitoring service  others
  • 21. Modularity on top of the platform: OSGi OSGi continues to evolve …
  • 22. Live Demo Modularity on top of the platform: OSGi
  • 23. Modularity of the platform: Jigsaw
  • 24. Modularity of the platform: Jigsaw When speaking of modularity we should also consider the entire runtime (rt.jar) and the JDK core libraries … … and built-in support for improved "OSGi-like" modules in the Java platform
  • 25. Modularity of the platform: Jigsaw The JDK is monolithic …
  • 26. Modularity of the platform: Jigsaw JDK 8 compact profiles provide smaller versions … (javac -profile <profile_name> or make profiles for an OpenJDK build) compact 1 compact 2 compact 3
  • 27. Modularity of the platform: Jigsaw The aim of project Jigsaw is to provide a module system for the Java platform Although deferred to JDK 9 some additional effort such as Compact Profiles and removed/ deprecated inter-library dependencies have been introduced in JDK8 as an intermediate solution
  • 28. Modularity of the platform: Jigsaw Modularization of the Java platform is a significant change that impacts the entire ecosystem - may even break existing projects
  • 29. Modularity of the platform: Jigsaw Draft 3 of Jigsaw requirements states that application using only standard APIs must remain compatible Draft 3 of Jigsaw requirements also mentions that some JDK-specific APIs must remain compatible but no concrete JDK APIs are listed yet
  • 30. Modularity of the platform: Jigsaw Q: So what is exactly project Jigsaw ?
  • 31. Modularity of the platform: Jigsaw Q: So what is exactly project Jigsaw ? A: Jigsaw will provide the basis for a Java Module System JSR. Currently work on Jigsaw is being done for: JEP 200 - define JDK modules (in a modules.xml file in the JDK repo) JEP 201 - reorganize JDK sources into modules and modify JDK build JEP 220 - restructure JRE/JDK images to accommodate modules
  • 32. Modularity of the platform: Jigsaw Q: So what is exactly project Jigsaw ? A: Structure of JDK sources as defined by JEP 201: old src/{share,$OS}/{classes,native}/$PACKAGE/*.{java,c,h,cpp,hpp} new src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java native/include/*.{h,hpp} $LIBRARY/*.{c,cpp} conf/*
  • 33. Modularity of the platform: Jigsaw Q: So what is exactly project Jigsaw ? A: In the early exploratory phase of project Jigsaw there was a proof-of-concept implementation with JDK8 early-access builds (now dropped).
  • 34. Modularity of the platform: Jigsaw Q: So what was exactly the exploratory phase of Jigsaw ? A: Jigsaw POC provided a modularized version of JDK along with additional tools and language support for creating Jigsaw modules. JDK8 early-access builds provided two types of JDK:  JDK modules image - all components are preinstalled as modules  JDK base image + jmod packages - base JDK installation along with additional Jigsaw modules of the JDK that can be installed on-demand using the jmod tool
  • 35. Modularity of the platform: Jigsaw Q: What is a Jigsaw module ?
  • 36. Modularity of the platform: Jigsaw Q: What is a Jigsaw module ? A: A collection of Java classes, native libraries and other resources along with metadata that provides name and version of the module and dependencies on other modules
  • 37. Modularity of the platform: Jigsaw Q: What is a Jigsaw module ? A: Jigsaw resolves modules during build and installation. Jigsaw has no dynamics, no module lifecycle. The module system assumes the existence of a foundational module named java.base
  • 38. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: Module can use ("require") other modules and additionally specify version or version ranges for the module dependency - modules are loaded with different module classloaders module org.bgjug.A @ 1.0 { requires org.bgjug.B @ [2.0, 3.0); } module org.bgjug.A { requires org.bgjug.B @ >= 1.0; requires org.bgjug.C @ < 2.0; }
  • 39. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: Module versions are compared using a similar approach as the one used for Debian package versions … The intent is to be able to package a module as an OS-specific package (not applicable for Windows/Mac OS)
  • 40. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: Modules can also "require" optional modules - meaning that compilation succeeds even if the required module is missing module org.bgjug.A { requires optional jdk-corba@8-ea; }
  • 41. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: Modules can also "require" local modules - meaning that the local module is a kind of a "mixin" - it is loaded in the same classloader as the requiring module module org.bgjug.A @ 1.0 { requires local org.bgjug.B @ [2.0, 3.0);
  • 42. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: A module may export packages and classes module org.bgjug.A @ 1.0 { requires org.bgjug.B @ [2.0, 3.0); exports org.bgjug.A.seminar.Sample; exports org.bgjug.A.seminar.samples.*; }
  • 43. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: Modules can explicitly specify which other modules can "require" them module org.bgjug.A@ 2.0 { exports org.bgjug.A.seminar; permits org.bgjug.B; }
  • 44. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: Modules can logically provide other module names (aliases): module com.bgjug.A @ 1.0 { provides com.bgjug.First @ 2.0; }
  • 45. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: Modules can have a single entry point module org.bgjug.A @ 1.0 { permits org.bgjug.B; class org.bgjug.A.Main; } the main() method org.bgjug.A.Main is called when invoking: java -m org.bgjug.A
  • 46. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: Modules can define multiple views module org.bgjug.A { exports org.bgjug.A.seminar; view org.bgjug.internal.view { permits org.bgjug.B } } the main() method org.bgjug.A.Main is called when invoking: java -m org.bgjug.A
  • 47. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: A module can declare that it provides a service module org.bgjug.A { provides service org.bgjug.A.external.TestService with org.bgjug.A.external.TestServiceImpl; }
  • 48. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: A module can require a service module org.bgjug.B { requires service org.bgjug.A.external.TestService }
  • 49. Modularity of the platform: Jigsaw Q: What is a Jigsaw module in terms of the exploratory phase ? A: A service can also be required optionally module org.bgjug.B { requires optional service org.bgjug.A.TestService; }
  • 50. Modularity of the platform: Jigsaw Q: So why not adopt OSGi (at least the module layer) for modularization of the Java platform ?
  • 51. Modularity of the platform: Jigsaw Q: So why not adopt OSGi (at least the module layer) for modularization of the Java platform ? A: As chief architect of the Java platform Mark Reinhold states: The OSGI module layer is not operative at compile time - it addresses modularity only during packaging, deployment and execution. It is also strictly build on top of the platform so it cannot be used to modularize it.
  • 52. Modularity of the platform: Jigsaw Q: So why not adopt OSGi (at least the module layer) for modularization of the Java platform ? A: However - according to Peter Kriens (former technical director at the OSGi Alliance and one of the key drivers behind the OSGi spec) Jigsaw is not typically needed an will introduce burden to the platform and modules can be introduced much easier: The only thing we need to add to the existing system is versioning information on the package and record this version in the class file
  • 53. Live Demo Modularity of the platform: Jigsaw
  • 54. OSGi and Jigsaw interoperability: Penrose
  • 55. OSGi and Jigsaw interoperability: Penrose When speaking of JDK modules we should consider interoperability with existing module systems such as OSGi The purpose of project Penrose is to explore interoperability between OSGi and Jigsaw
  • 56. OSGi and Jigsaw interoperability: Penrose Penrose is still in early stage of development … Current work on project Penrose is deprecated due to the dropped proof-of-concept version of Jigsaw …
  • 57. OSGi and Jigsaw interoperability: Penrose Penrose goals: – ensuring OSGi frameworks run unmodified in a Jigsaw-enabled runtime – create modules/bundles that have both OSGi and Jigsaw metadata in them – Jigsaw metadata can be extended with OSGi concepts – extend OSGi to read Jigsaw metadata
  • 58. OSGi and Jigsaw interoperability: Penrose Penrose goals: – mapping Jigsaw metadata to OSGi metadata – resolve Jigsaw modules in an OSGi runtime – enhance OSGi to use Jigsaw APIs – more cross delegation between the two systems …
  • 59. Summary Q: Project Jigsaw - when ?
  • 60. Summary Q: Project Jigsaw - when ? A: Maybe when the Armagedon comes … … or maybe in 2016 …
  • 61. Summary Q: Projects Jigsaw/Penrose - when ? A: Unless you … … discuss: http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev … and code: http://hg.openjdk.java.net/jigsaw
  • 62. Q&A Thank you Bulgarian JUG mailing list: https://groups.google.com/forum/#!forum/bg-jug
  • 63. References OSGi Alliance http://www.osgi.org/Main/HomePage Jigsaw Project http://openjdk.java.net/projects/jigsaw/ Penrose Project http://openjdk.java.net/projects/penrose/
  • 64. References Modularity - what is it ? http://www.infoq.com/articles/modular-java-what- is-it/ Java modularity - why ? http://java.dzone.com/articles/java-modularity- 2-why Java JAR hell problem http://en.wikipedia.org/wiki/Java_Classloader#JA R_hell
  • 65. References Project Jigsaw: Phase Two http://mreinhold.org/blog/jigsaw-phase-two Project Jigsaw: Goals & Requirements Draft 3 http://openjdk.java.net/projects/jigsaw/goals-reqs/ 03
  • 66. References Java Module System Requirements http://openjdk.java.net/projects/jigsaw/doc/draf t-java-module-system-requirements-12 Project Jigsaw: The Big Picture http://cr.openjdk.java.net/~mr/jigsaw/notes/jigs aw-big-picture-01 Java 8 Modules Jigsaw and OSGi http://www.slideshare.net/mfrancis/java-8- modules-jigsaw-and-osgi-neil-bartlett
  • 67. References Project Jigsaw: Late for the train http://mreinhold.org/blog/late-for-the-train-qa Unbearable lightness of Jigsaw http://blog.osgi.org/2011/05/unbearable-lightness- of-jigsaw.html Netbeans discussion on Jigsaw http://wiki.netbeans.org/Jigsaw
  • 68. References Java Modularity - OSGi and Project Jigsaw http://techdistrict.kirkk.com/2009/06/12/java-modularity- osgi-and-project-jigsaw/ The Modular Java Platform & Project Jigsaw http://www.jfokus.se/jfokus14/preso/Jigsaw.pdf JAX 2013: A Project Jigsaw primer http://jaxenter.com/a-project-jigsaw-primer- 50029.html
  • 69. References JavaOne 2013: The Modular Java Platform and Project Jigsaw http://parleys.com/play/52549d02e4b0a43ac12 124be/about OpenJDK Penrose JavaOne 2012 http://www.slideshare.net/bosschaert/open-jdk-penrose- javaone-2012

Editor's Notes

  1. Some people argue that Java libraries are not modules since they do not provide encapsulation (such as classes and packages).
  2. Evolution of modules in the default classloading mechanism supported by the Java platform may cause the so called "JAR hell" problem when conflicting versions of the same library are present on the classpath or required by different libraries. In order to evolve libraries in a compatible way using the default classloading mechanism on must design libraries with backward/forward compatibility in mind.
  3. Evolution of modules in the default classloading mechanism supported by the Java platform may cause the so called "JAR hell" problem when conflicting versions of the same library are present on the classpath or required by different libraries. In order to evolve libraries in a compatible way using the default classloading mechanism on must design libraries with backward/forward compatibility in mind.
  4. multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded) the optional modules may be explicitly required to "permit" the requiring module in the future
  5. multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded) the optional modules may be explicitly required to "permit" the requiring module in the future
  6. multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded) the optional modules may be explicitly required to "permit" the requiring module in the future
  7. multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded) the optional modules may be explicitly required to "permit" the requiring module in the future
  8. multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded) the optional modules may be explicitly required to "permit" the requiring module in the future
  9. multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded) the optional modules may be explicitly required to "permit" the requiring module in the future
  10. multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded) the optional modules may be explicitly required to "permit" the requiring module in the future
  11. The module can use an enhanced version of java.util.ServiceLoader to load the service
  12. The module can use an enhanced version of java.util.ServiceLoader to load the service
  13. The only benefit in Jigsaw according to Peter Kriens: The only reason I can think of is that is easier for the module system providers to program. In the Jigsaw model traversing the dependencies is as easy as taking the module name + version, combining it with a repository URL, doing some string juggling and using the result as a URL to your module.