Modularization in java 8

Modularisierung in Java 8

c.dedek

|
Orientation In Objects GmbH

p.g.taboada
|
pgt technology scouting GmbH

Mit Java 8, Jigsaw und JSR 294 soll über die
Java-Plattform ein vereinheitlichtes
Modularisierungskonzept eingeführt und die
seit 2005 apostrophierte "post-jar-File-Ära"
eingeläutet werden.

Etablierte Konzepte und Vorgehensweisen zur
Modularisierung wie OSGi und JEE werden in
der Session den Ideen von Java 8
gegenübergestellt und der architektonische
Aspekt in der technologischen Debatte
hinterfragt.

© 2011 Orientation in Objects GmbH

‣Java 8, Jigsaw
‣ Modularization?
‣ 2013
Session
Topics

Wouldn’t it be
cool?
• You could write a Java application that
could run, without change, on cell
phones, on TV set-top boxes, and
on laptop and desktop computers?
• A Java applet could start up just
as quickly as a similar Flash
application, and have comparable
responsiveness?
• A Java application could start up just as
quickly as a similar application written
in C/C++, and have a comparable
memory footprint?
• (...)
http://mreinhold.org/blog/cool

“ All this works fine as long as a project fits
into a single package. Once the project
grows beyond that, you may find yourself
forced to make implementation classes
public in order to access them from
multiple packages in the project.

Blog: Superpackage strawman and
the JSR 294 mailing list

“ That loses the beneﬁts of information
hiding, which is clearly suboptimal and a
long-standing complaint that often comes
up in language discussions in forums such
as JavaOne.


“ However, if a project is too large to ﬁt into
a single package, Java does not provide a
suitable encapsulation mechanism.


JSR 294: Improved
Modularity Support in
the JavaTM
Programming Language
The intention is to deliver this JSR as a
component of Java SE 7.
Early Draft Review of this JSR is planned to
occur in the ﬁrst half of 2009, Public Review
in the second half of 2009, and Proposed
Final Draft in the ﬁrst half of 2010.

JSR 294 initially focused on a concept called
superpackages, described in April 2006
and again in November 2006. Later, JSR 294
focused on a more lightweight concept
called modules, described to the Expert
Group in March 2008.
http://jcp.org/en/jsr/detail?id=294

Status: Inactive


• JSR 308: Annotations on Java Java 8
Types
• JSR 310: Date and Time API JSR 337
• JSR TBD: More Small
Enhancements to the Java
Programming Language
(OpenJDK Project Coin)
• JSR 335: Lambda Expressions
for the Java Programming
Language (OpenJDK Project
Lambda)

• JSR TBD: Java Platform
Module System
http://jcp.org/en/jsr/detail?id=337

Project Jigsaw

The goal of this Project is to
design and implement a
standard module system for
the Java SE Platform, and
to apply that system to
the Platform itself and to
the JDK.

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

First, build your own JDK8

OpenJDK mit jigsaw auf Suse 11.3 bauen
======================================

Folgende URL als Paketquelle in YAST hinzufügen:
------------------------------------------------
http://download.opensuse.org/repositories/Java:/openjdk6:/Factory/openSUSE_11.3/

Benötigte Pakete installieren:
------------------------------
sudo zypper source-install -d java-1_7_0-openjdk
sudo zypper install java-1_7_0-openjdk
sudo zypper install make
sudo zypper install mercurial


Mercurial Addon besorgen:
-------------------------
hg clone https://vogella@bitbucket.org/vogella/hgforest-crew

Mercurial conﬁg ".hgrc" im Homeverzeichnis anlegen mit folgendem Inhalt:
-------------------------------------------------------------------------
[extensions]
forest=/root/hgforest/hgforest-crew/forest.py

JDK 8 mit Jigsaw bauen
=======================

JDK 8 Jigsaw Sourcen laden:
---------------------------
hg fclone http://hg.openjdk.java.net/jigsaw/jigsaw/


Umgebunsvariablen setzen:
-------------------------
export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-1.7.0-openjdk
export -n JAVA_HOME

Bauen:
------
make ALLOW_DOWNLOADS=true

1,5h warten ;-)
---------------


module jdk @ 8-ea { requires public jdk.jx.annotations @ 8-ea;
requires public jdk.apt @ 8-ea; requires public jdk.kerberos @ 8-ea;
requires public jdk.base @ 8-ea; requires public jdk.logging @ 8-ea;
requires public jdk.compat @ 8-ea; requires public jdk.management @ 8-ea;
requires public jdk.compiler @ 8-ea; requires public jdk.mirror @ 8-ea;
requires public jdk.corba @ 8-ea; requires public jdk.rmi @ 8-ea;
requires public jdk.deploy @ 8-ea; requires public jdk.scripting @ 8-ea;
requires public jdk.desktop @ 8-ea; requires public jdk.security.acl @ 8-ea;
requires public jdk.ext @ 8-ea; requires public jdk.smartcardio @ 8-ea;
requires public jdk.instrument @ 8-ea; requires public jdk.sunjce @ 8-ea;
requires public jdk.jaas @ 8-ea; requires public jdk.sunpkcs11 @ 8-ea;
requires public jdk.javac @ 8-ea; requires public jdk.tools @ 8-ea;
requires public jdk.javadoc @ 8-ea; requires public jdk.tools.base @ 8-ea;
requires public jdk.javah @ 8-ea; requires public jdk.tools.jaxws @ 8-ea;
requires public jdk.javap @ 8-ea; requires public jdk.tools.jre @ 8-ea;
requires public jdk.jaxp @ 8-ea; requires public jdk.xmldsig @ 8-ea;
requires public jdk.jaxws @ 8-ea; requires public sun.charsets @ 8-ea;
requires public jdk.jdbc @ 8-ea; requires public sun.localedata @ 8-ea;
requires public jdk.jdbc.rowset @ 8-ea; requires public sun.resources @ 8-ea;
requires public jdk.jndi @ 8-ea; requires public sun.sunec @ 8-ea;
requires public jdk.jsse @ 8-ea; }
requires public jdk.jta @ 8-ea;

Jigsawed JRE

Do the hello world thing

module de.oio.service @ 1.0 { module de.oio.test @ 1.0 {
} requires de.oio.service @ 1.0;
class de.oio.test.Test;
}

package de.oio.service; package de.oio.test;
import de.oio.service.OioService;
public class OioService { public class Test {
public int add(int a, int b) { public static void main(String[] args) {
return a+b; OioService
} service = new OioService();
} System.out.println(
"2+3=" + service.add(2, 3));
}
}


# de.oio.test kompilieren

javac
-d modules
-modulepath modules
-sourcepath modules `ﬁnd modules -name '*.java'`


# jmods erstellen

jpkg -m modules/de.oio.service jmod de.oio.service

jpkg -m modules/de.oio.test jmod de.oio.test


# mlib erstellen und Module installieren

jmod create -L mlib

jmod install
de.oio.service@1.0.jmod
de.oio.test@1.0.jmod
-L mlib


# Ausführen
java -L mlib -m de.oio.test@1.0


Java Module-System Requirements

Mark Reinhold,
2011/4/19

DRAFT 12
Fundamentals, Developers,
Containers, Migration and
interoperation, Packaging,
Publication, Performance...

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

Java Module-System
Requirements
DRAFT 12

? JSR TBD
!

OSGi
Jigsaw Ref Impl


Java Module-System Requirements
DRAFT 12
Mark Reinhold, 2011/4/19
Fundamentals:
Module dependences, Resolution in all phases,
Fidelity across all phases, Encapsulation,
Versioning, Optional modules, Refactoring,
Substitution, Module constraints on targets, Target
constraints on modules, Native code, Services,
Resources, Read-only operation, Platform
modularization, Package subsets, Shared class

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

META-INF Java Syntax Erweiterung

Form of deﬁnition

It must be easy for developers to both write and read module
declarations.

The Java language syntax must be extended to define
declarations of module metadata.

The syntax and, to the degree possible, the semantics of module
declarations must be specified in the Java Language Specification.

A module declaration must be written in a file that
resides with the module’s source content, rather than in a
side file in some other format or, even worse, a set of command-line
arguments baked into a build script.

Module declarations alongside
source code

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;
}

Java Syntax

src/com/example/myclass.java
src/com/example/myclassimpl.java
META-INF/MANIFEST.MF

Bundle-ManifestVersion: 2
Bundle-SymbolicName:
com.ex.mybundle
Bundle-Version: 1.0.0
Import-Package: com.example.bar
Import-Package: com.example.foo

META-INF

Form of Module
Definition
• Variante A - Non-Java source-file
names
When a module declaration is stored in a file
then the name of the file must, by convention,
end with a string other than “.java”.
• Variante B - Java source-file names
When a module declaration is stored in a file
then the name of the file must, by convention,
end with the string “.java”.


Form of Module
Definition
• Variante A - Source-form metadata in
modular JAR files
The module metadata in a modular JAR file must use
the same Java syntax as module-declaration source
files. This will ease deployment debugging and tool
construction.
• Variante B - Compiled module declarations
Module declarations must be compiled by a Java
compiler into a standard compact binary form, just as
Java class declarations are compiled into class files.


A B

API ....

Export-Package: API Import-Package: API

Deklarationslevel

A B

API ....

module B @ 1.0 {
requires A;
}

Deklarationslevel

Refactoring...
• It must be possible to refactor a module into a
set of smaller modules, without breaking
existing modules or applications that depend
upon the original module (splitting).

• Likewise, it must be possible to refactor a set of
modules so that they appear to be a single
module, without breaking existing modules or
applications that depend upon the original
modules (aggregation).


Substitution...
• It must be possible to declare that one module
can substitute for another. This supports
refactoring via aggregation and also allows a
module to resolve against any one of a set of
equivalent implementation modules.

• JREs from different vendors, e.g., can all declare
that they are substitutes for the “java” module.
An application module that requires only
standard Java SE APIs can declare that it requires


A B

API 1 ....
API 2

Refactoring - OSGi

A

API 1 B

....
A‘

API 2

Refactoring - OSGi

A B

API 1 ....
API 2

Refactoring - Jigsaw

A

API 1 B

....
A‘

API 2 ?


A

API 1
B

....
A‘

API 2


"The syntax must place all
extended metadata after all
standard metadata, with a clear
delineation between them."

Extensible module declarations

Versions
• The module system must support common
version-string schemes such as those deﬁned by
OSGi and Maven and also those found in both
proprietary and open-source software products.

• Version strings must be totally ordered but
otherwise the module system must not impose
any particular structure or semantics upon
them. It must be possible to specify a range of
allowable versions when declaring a module
dependence.


support common
version-string schemes?!?


M 1000
D 500
C 100
L 50
module Nodule @ I {
requires Copyright @ MMIX,
provides Fox @ MCMI,
permits Henry @ VIII,
}

http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series.html

Mercury
Venus
Earth
Mars
Jupiter
Saturn
Uranus module Home @ Earth {
Neptune requires InnerSystem @ [Mercury,Earth)
requires OuterSystem @ (Earth,Neptune]
permits Asteroids @ (Mars,Jupiter)
}


But not 2.3,
because that's a
dev release

module Lenny @ 2.4 {
requires SMTP @ [2.2,2.5),
requires MacOSX @ 2.10.*.2+,
permits Desmond @ 2.2,
}
Who uses Mac OS
X before .2 comes
out?

http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series-linux.html

!!!

module IrrationalVersioningSystem @ ∞
{
requires TeX @ [3.14159,π),
requires METAFONT @ [2.718,e),
permits Historic @ √66,
}


Versions
• Resolution in all phases — Build-time, install-
time, and run-time module resolution and linking must
all be supported.

• Fidelity across all phases — The set of modules seen by
a library or application must be computed by the same
algorithm at build time, install time, and run time
• The module system must support common version-
string schemes [...]. It must be possible to specify
a range of allowable versions when declaring a
module dependence.


Simultaneous multiple
versions
• A container must be able to load a group of modules
that, as a whole, requires a different version of one or
more modules already loaded by the container. A
canonical example is that of a web application requiring a
different version of the XML parser than that built-in to
the web container.

• Multi-version support should only be enabled
when type collisions can be detected and reported as
errors. This most likely means that it cannot be
enabled for run-time linking since detecting collisions is
nontrivial.


This most likely means???


OSGi: Because Sharing
Shouldn't Be Painful
http://www.theserverside.com/feature/OSGi-Because-Sharing-Shouldnt-Be-Painful

Migration and
interoperation

• Maven support
• OSGi support
• Manipulable module metadata


Maven support

• The module system must be able to download,
install, resolve, and link a Maven artifact and its
transitive dependences as if they were modules.
Maven is a popular and widely used modular
build and assembly system which most Java
developers are familiar with today, so making the
module system work really well with it will be
important to adoption.


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 reiﬁcation
API.


Manipulable module
metadata

• Module metadata must in all phases be easily
read, edited, and written by module-management
tools and by people, not just by Java compilers.


Package subsets

• Package subsets — In support of platform
modularization, it must be possible for the
types deﬁned in a Java package to be
provided by more than one module yet
still be loaded by the same class loader at run
time. This is required so that CDC-sized subsets
of large legacy packages such as java.util can be
deﬁned.

OSGi: Split Packages!

BootstrapClassloader

Classloader 2

Classloader 1

JAR

org.jboss.chap2.ex0.ExtCtx
org.jboss.chap2.ex0.ExtObj

Exceptions mit Classloadern

Package subsets

• Package subsets — In support of platform
modularization, it must be possible for the types
deﬁned in a Java package to be provided by more
than one module yet still be loaded by the
same class loader at run time.

• This is required so that CDC-sized subsets of
large legacy packages such as java.util can be
deﬁned.

OSGi: Noooo!

CDC-sized subsets?


Target Platform
Constraints
• Module constraints on targets — In a module declaration it must
be possible to declare that the module can only be used on
target platforms with specific properties, e.g., particular operating
systems, processor architectures, or display geometries. The
resolution algorithm must ignore any module whose platform
constraints are not satisfied by the target platform.

• Target constraints on modules — On a particular target platform
it must be possible to declare that only modules with specific
properties can be installed, e.g., particular authors, publishers, or
licenses. The resolution algorithm must ignore any module that
does not satisfy the target platform’s module constraints.


Shared class loaders

• In support of platform modularization,
it must be possible to declare that the types
deﬁned in a speciﬁc set of modules must be
loaded by the same class loader.


Enforcement

“ Modularity not enforced
is not.
Unless someone slaps
you on the wrist when
you violate a module
boundary you will not be
working modular.

http://www.theserverside.com/feature/OSGi-Because-Sharing-Shouldnt-Be-Painful

Open Issues
• “Friend” constraints — It must be possible for a module to specify the set of
modules that can depend directly upon it, and to have that restriction be enforced at
run time.
• JSR 294 — A new Java language keyword must be defined for controlling module-
level type and member accessibility.
• Multi-platform installations — It must be possible to install multiple variants of a
module, each targeted to a different combination of operating system, processor
architecture, and possibly other platform properties.
• Predictability — The set of modules seen by an application must not depend upon
the application’s behavior, or that of any other application, unless the application is
interacting directly with the module system to perform run-time resolution and
linking.
• Service declarations — A module must be able to declare that it requires and/or
provides specific services.
• Package-level dependences — It must be possible to declare that a module depends
upon one or more Java packages, leaving it to the module system to resolve which
modules will be linked to provide the types defined in those packages.
• Java-like syntax — The syntax of module declarations must be similar to that of
declarations of a like nature in the Java programming language.


‣ Java 8, Jigsaw
‣ Modularization?
Session ‣ 2013
Topics

where does modularization happen?

Wikipedia...
As documentation produced by architects,
typically drawings, plans and technical
speciﬁcations, architecture deﬁnes the structure
and/or behavior of a building or any other kind of
system that is to be or has been constructed.


so, is it a
matter of
architecture?

super-architect

Divide & Conquer

break it into pieces

• components

• layers

• modules

• aspects?


0100100101001100
110010010010010
010010010101
01010010101
010010010101
100100101010
10101010
010010010101
101
101111001011
0101010101

bad guy

0100100101001100 I am amonolithical thing!
110010010010010
010010010101
01010010101
010010010101
100100101010
10101010
010010010101
101
101111001011
0101010101

bad guy

0100100101001100 I am amonolithical thing!
110010010010010
010010010101
01010010101
010010010101
100100101010
10101010
010010010101
101
101111001011
0101010101

I am not known for
reusability, maintainability, etc..

bad guy

0100100101001100
110010010010010
010010010101
01010010101
010010010101
100100101010
10101010
010010010101
101
101111001011
0101010101

see the duplicate code?

0100100101001100
110010010010010
010010010101
01010010101
010010010101
100100101010
10101010
010010010101
101
101111001011
0101010101

re-use it!

0100100101001100
110010010010010
XXX
01010010101
XXX
100100101010
10101010
XXX XXX
101
101111001011 010010010101
0101010101

lifecycle? state? runtime?

XXX provides interfaces

010010010101
provides services

managed bean (ioc)!

XXX XXX XXX

010010010101 010010010101 0100100101

component based development


✓ components
• layers
• modules
• aspects?


presentation layer

business logic layer

integration layer

layers

presentation layer business logic layer integration layer

business session service beans manager daos
delegate facade beans

transfer objects converters entity beans

layers


✓ components
✓ layers
• modules
• aspects?


modules?

allowed intimacy level?


✓ components
✓ layers
✓ modules
• aspects?


ring

tion
security

monito

transac

minimum aop?
business logic layer integration
layer
layer

layer


✓ components
✓ layers
✓ modules
✓ aspects?



✓ VMs?


integration?

RCP Client JSF Client

BL „1“ BL „2“ BL „3“

DAO „A“ DAO „B“ DAO „C“ DAO „D“

simple 2 client situation


v.1.0 v.1.0 v.1.0 v.1.0

BL „1“ BL „2“ BL „3“

v.1.0 v.1.0 v.1.0 v.1.0 v.1.0 v.1.0


... with versions ...

RCP

PrimeFaces
v.1.0 v.1.0 v.1.0 v.1.0
DOJO

Spring

BL „1“ BL „2“ BL „3“ Log4J

Hibernate
v.1.0 v.1.0 v.1.0 v.1.0 v.1.0 v.1.0


and 3rd party libs

windows? tomcat
RCP Client v.6.x JSF Client
RCP

PrimeFaces
v.1.0 v.1.0 v.1.0 v.1.0
DOJO

Spring
jboss
v.5.x
BL „1“ BL „2“ BL „3“ Log4J

Hibernate
v.1.0 v.1.0 v.1.0 v.1.0 v.1.0 v.1.0


and runtimes

#omfg
• Release management?
• Versioning?
• Backwards compatibility?
• Dependency resolution & mediation?
• Compiletime vs. runtime?
• Visibility?
• Deployment, scalability, availability?

EJB-JAR

R
W

l JA
AR

uti
Java EE

EJB-JAR

R
W

l JA
AR

uti
Servlets, EJBs, ...

Java EE

EJB-JAR

R
W

l JA
AR

uti
Servlets, EJBs, ... EAR

Java EE

dependencies / scopes
BL
conﬁguration
runtime testtime
modularization?
compiletime

DAO interface impl mock

template

hibernate api

SCOPES

POM
artefact „2“
v1.0

artefact „1“

v1.2 artefact „3“

Maven (ivy too...)

JSF Client Frontend Libs RCP
v.1.0
v.1.0

v.1.0 PrimeFaces

v.1.0
DOJO

Spring
v.1.0

v.1.0 v.1.0
BL „3“ Backend Libs Log4J
v.1.0
Hibernate

v.1.0

DAO „D“

transitive dependencies

dead end with Java EE

update
install refresh

INSTALLED STARTING

resolve update
start stop
refresh

RESOLVED ACTIVE

uninstall uninstall stop

UNINSTALLED STOPPING

Bundle

OSGi

Java EE APIs
don‘t ﬁt into OSGi

e.g. ....

monolothical conﬁgs
classloading nightmares
don‘t work by design


dead end with Java

tools: a matter of context

develop modular
software

• APIs
• IDEs
• Test-Frameworks


build modular software

• integration server
• automated builds
• distributed builds?
• provisioning?
• release management?


run modular software

• runtime for modules
• module/ app deployment
• intelligent (?) clustering?


each tool is great

• and does (mostly) not work with the others
• no standard? no standard tooling.


‣ Java 8, Jigsaw
‣ Modularization?
Session ‣2013
Topics

http://mreinhold.org/blog/cool

Wouldn’t it be
cool?
• You could write a Java application that
could run, without change, on cell
phones, on TV set-top boxes, and on
laptop and desktop computers?
• A Java applet could start up just as
quickly as a similar Flash application, and
have comparable responsiveness?
• A Java application could start up just as
quickly as a similar application written in
C/C++, and have a comparable memory
footprint?
• (...)


Meanwhile...

Java X 8, ?
7,
super packages?
modules?
simpliﬁed module system?
dynamic modules?

==> Java EE ?!?


Maven/ Ivy, Spring, JBoss, OSGi, OBR/ P2, Cloud

Helping ourselves

There is not a moment to loose!

Thanks!

Modularization in java 8

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Modularization in java 8

Similar a Modularization in java 8 (20)

Más de pgt technology scouting GmbH

Más de pgt technology scouting GmbH (8)

Último

Último (20)

Modularization in java 8

Notas del editor