modular java

Modular Java

Martin Toshev

BG JUG mailing list:https://groups.google.com/forum/#

!forum/bg-jug

Agenda

Modularity 101

Modularity on top of the platform: OSGi

Modularity of the platform: Jigsaw

OSGi and Jigsaw interoperability: Penrose

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

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

Modularity 101

Benefits of modularization:

– development of the system can be split easier between teams/developers

– increased maintainability of separate modules

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

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

Modularity 101

Module systems aim to solve the mentioned problems and typically provide:

• module management

• module deployment

• versioning

• dependency management

• module repositories

• configuration management

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

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

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

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:

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.

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.

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

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

OSGi continues to evolve …

Live DemoModularity on top of the platform: OSGi

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

The JDK is monolithic …

JDK 8 compact profiles provide smaller versions …

(javac -profile <profile_name> or

make profiles for an OpenJDK build)

compact 1 compact 2 compact 3

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

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

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

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

A: Structure of JDK sources as defined by JEP 201:

src/{share,$OS}/{classes,native}/$PACKAGE/*.{java,c,h,cpp,hpp}

src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java

native/include/*.{h,hpp}

$LIBRARY/*.{c,cpp}

conf/*

A: In the early exploratory phase of project Jigsaw there was a proof-of-concept implementation with JDK8 early-access builds (now dropped).

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

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

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

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;

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)

A: Modules can also "require" optional modules - meaning that compilation succeeds even if the required module is missing

requires optional jdk-corba@8-ea;

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

requires local org.bgjug.B @ [2.0, 3.0);

A: A module may export packages and classes

requires org.bgjug.B @ [2.0, 3.0);

exports org.bgjug.A.seminar.Sample;

exports org.bgjug.A.seminar.samples.*;

A: Modules can explicitly specify which other modules can "require" them

exports org.bgjug.A.seminar;

permits org.bgjug.B;

A: Modules can logically provide other module names (aliases):

module com.bgjug.A @ 1.0 {

provides com.bgjug.First @ 2.0;

A: Modules can have a single entry point

the main() method org.bgjug.A.Main is called when invoking:

java -m org.bgjug.A

permits org.bgjug.B;

class org.bgjug.A.Main;

A: Modules can define multiple views

the main() method org.bgjug.A.Main is called when invoking:

java -m org.bgjug.A

exports org.bgjug.A.seminar;

view org.bgjug.internal.view {

permits org.bgjug.B

A: A module can declare that it provides a service

provides service org.bgjug.A.external.TestService with

org.bgjug.A.external.TestServiceImpl;

A: A module can require a service

module org.bgjug.B {

requires service org.bgjug.A.external.TestService

A: A service can also be required optionally

module org.bgjug.B {

requires optional service org.bgjug.A.TestService;

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.

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

Live DemoModularity of the platform: Jigsaw

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

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 …

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

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 …

SummaryQ: Project Jigsaw - when ?

A: Maybe when the Armagedon comes …

… or maybe in 2016 …

SummaryQ: 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

Thank you

Bulgarian JUG mailing list:

https://groups.google.com/forum/#!forum/bg-jug

ReferencesOSGi Alliance

http://www.osgi.org/Main/HomePage

Jigsaw Project

http://openjdk.java.net/projects/jigsaw/

Penrose Project

http://openjdk.java.net/projects/penrose/

ReferencesModularity - what is it ?

http://www.infoq.com/articles/modular-java-what-is-it/

Java modularity - why ?http://java.dzone.com/articles/java-modularity-

Java JAR hell problemhttp://en.wikipedia.org/wiki/Java_Classloader#JA

R_hell

ReferencesProject Jigsaw: Phase Two

http://mreinhold.org/blog/jigsaw-phase-two

Project Jigsaw: Goals & Requirements Draft 3http://openjdk.java.net/projects/jigsaw/goals-

reqs/03

ReferencesJava Module System Requirements

http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12

Project Jigsaw: The Big Picturehttp://cr.openjdk.java.net/~mr/jigsaw/notes/jigs

aw-big-picture-01

Java 8 Modules Jigsaw and OSGihttp://www.slideshare.net/mfrancis/java-8-

modules-jigsaw-and-osgi-neil-bartlett

ReferencesProject Jigsaw: Late for the train

http://mreinhold.org/blog/late-for-the-train-qa

Unbearable lightness of Jigsawhttp://blog.osgi.org/2011/05/unbearable-

lightness-of-jigsaw.html

Netbeans discussion on Jigsawhttp://wiki.netbeans.org/Jigsaw

ReferencesJava Modularity - OSGi and Project Jigsaw

http://techdistrict.kirkk.com/2009/06/12/java-modularity-osgi-and-project-jigsaw/

The Modular Java Platform & Project Jigsawhttp://www.jfokus.se/jfokus14/preso/Jigsaw.pdf

JAX 2013: A Project Jigsaw primerhttp://jaxenter.com/a-project-jigsaw-primer-

50029.html

ReferencesJavaOne 2013: The Modular Java Platform and Project Jigsaw

http://parleys.com/play/52549d02e4b0a43ac12124be/about

OpenJDK Penrose JavaOne 2012

http://www.slideshare.net/bosschaert/open-jdk-penrose-javaone-2012

modular java

Software

developing modular applications with java ee 6 and...

cadec 2016 – java 9 module system ”jigsaw”main...

porto alegre, novembro 2017 a arquitetura modular java...

dianne: a modular framework for designing, training and...

jml: expressive, modular reasoning for java

the modular java platform & project jigsawjava.io java.lang...

modular speci cation of java programsmodular speci cation of...

building modular cloud applications in java - lessons...

java ee | modular ejbs for enterprise osgi | tim ward

jmfgraph—a modular framework for drawing graphs in...

jax london | the conference for java & software...

what's not new in modular java

writing modular java script

modular java with osgi and karaf

ibm distinguished engineer java cto€¦ · modular...

spectrasuite spectrometer operating...

aplicações visuais mobile com netbeans...

what's not new in modular java!

modular java web applications - curve

modular points, modular curves, modular surfaces and modular...