Modularisierung in Java 8       c.dedek    |   Orientation In Objects GmbH       p.g.taboada |   pgt technology scouting G...
Mit Java 8, Jigsaw und JSR 294 soll über die                                     Java-Plattform ein vereinheitlichtes     ...
‣Java 8, Jigsaw          ‣ Modularization?          ‣ 2013SessionTopics
Wouldn’t it be               cool?          • You could write a Java application that              could run, without chan...
“                          All this works fine as long as a project fits                            into a single package. O...
“                          That loses the benefits of information                            hiding, which is clearly subop...
“                          However, if a project is too large to fit into                            a single package, Java...
JSR 294: Improved       Modularity Support in       the JavaTM       Programming Language       The intention is to delive...
Status: Inactive© 2011 Orientation in Objects GmbH
• JSR 308: Annotations on Java                                    Java 8                 Types          • JSR 310: Date an...
Project Jigsaw                 The goal of this Project is to                 design and implement a                 stand...
First, build your own JDK8© 2011 Orientation in Objects GmbH
OpenJDK mit jigsaw auf Suse 11.3 bauen         ======================================         Folgende URL als Paketquelle...
Mercurial Addon besorgen:       -------------------------       hg clone https://vogella@bitbucket.org/vogella/hgforest-cr...
Umgebunsvariablen setzen:       -------------------------       export LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-1.7.0-openjdk ...
module jdk @ 8-ea {                             requires public jdk.jx.annotations @ 8-ea;   requires public jdk.apt @ 8-e...
Do the hello world thing© 2011 Orientation in Objects GmbH
module de.oio.service @ 1.0 {           module de.oio.test @ 1.0 {    }                                         requires d...
# de.oio.test kompilieren                   javac                     -d modules                     -modulepath modules  ...
© 2011 Orientation in Objects GmbH
# jmods erstellen                  jpkg -m modules/de.oio.service jmod de.oio.service                  jpkg -m modules/de....
© 2011 Orientation in Objects GmbH
# mlib erstellen und Module installieren                                     jmod create -L mlib                          ...
© 2011 Orientation in Objects GmbH
# Ausführen                                     java -L mlib -m de.oio.test@1.0© 2011 Orientation in Objects GmbH
© 2011 Orientation in Objects GmbH
Java Module-System Requirements                Mark Reinhold,                2011/4/19                DRAFT 12            ...
Java Module-System      Requirements        DRAFT 12                                     ?         JSR TBD                ...
Java Module-System Requirements                               DRAFT 12                    Mark Reinhold, 2011/4/19        ...
META-INF                           Java Syntax Erweiterung                                     Form of definition© 2011 Ori...
It must be easy for developers to both write and read module                                                              ...
src/com/example/myclass.java      src/com/example/myclassimpl.java      src/module-info.java                              ...
src/com/example/myclass.java     src/com/example/myclassimpl.java     META-INF/MANIFEST.MF                                ...
Form of Module                                        Definition                    • Variante A - Non-Java source-file     ...
Form of Module                                        Definition                    • Variante A - Source-form metadata in ...
A              B                                      API            ....                        Export-Package: API   Imp...
A               B                                      API             ....                                               ...
Refactoring...                    • It must be possible to refactor a module into a                          set of smalle...
Substitution...                    • It must be possible to declare that one module                          can substitut...
A          B                                     API 1             ....                                      API 2        ...
A                             API 1                   B                                                      ....         ...
A           B                                     API 1              ....                                       API 2     ...
A                             API 1                     B                                                       ....      ...
A              API 1                                                       B                                              ...
"The syntax must place all                                       extended metadata after all                              ...
Versions                    • The module system must support common                          version-string schemes such a...
support common                  version-string schemes?!?© 2011 Orientation in Objects GmbH
M 1000                                                                                                            D 500   ...
Mercury          Venus          Earth          Mars          Jupiter          Saturn          Uranus                      ...
But not 2.3,                                                                                                       because...
!!!                             module IrrationalVersioningSystem @ ∞                             {                       ...
Versions                    • Resolution in all phases — Build-time, install-                          time, and run-time ...
Versions                    • Resolution in all phases — Build-time, install-                          time, and run-time ...
Simultaneous multiple                                   versions                    • A container must be able to load a g...
This most likely means???© 2011 Orientation in Objects GmbH
OSGi: Because Sharing                                         Shouldnt Be Painful                               http://www...
Migration and                                     interoperation                    • Maven support                    • O...
Maven support                    • The module system must be able to download,                      install, resolve, and ...
OSGi support                    • It must be demonstrated by prototype to be                      feasible to modify an OS...
Manipulable module                                          metadata                    • Module metadata must in all phas...
Package subsets                    • Package subsets — In support of platform                          modularization, it ...
A               B                                      API             ....                                               ...
BootstrapClassloader                                              Classloader 2                    Classloader 1          ...
Package subsets                    • Package subsets — In support of platform                          modularization, it ...
CDC-sized subsets?© 2011 Orientation in Objects GmbH
Target Platform                                       Constraints                    •     Module constraints on targets —...
Shared class loaders                    • In support of platform modularization,                          it must be possi...
Enforcement“                     Modularity not enforced                      is not.                      Unless someone ...
Open Issues                    •     “Friend” constraints — It must be possible for a module to specify the set of        ...
‣ Java 8, Jigsaw           ‣ Modularization?Session   ‣ 2013Topics
where does modularization happen?© 2011 Orientation in Objects GmbH
Wikipedia...                  As documentation produced by architects,                  typically drawings, plans and tech...
so, is it a                     matter of                   architecture?© 2011 Orientation in Objects GmbH
super-architect© 2011 Orientation in Objects GmbH
Divide & Conquer© 2011 Orientation in Objects GmbH
break it into pieces                    •          components                    •          layers                    •   ...
0100100101001100                                     110010010010010                                     010010010101     ...
0100100101001100   I am amonolithical thing!                                     110010010010010                          ...
0100100101001100   I am amonolithical thing!                                       110010010010010                        ...
0100100101001100           110010010010010           010010010101           01010010101           010010010101           1...
0100100101001100           110010010010010           010010010101           01010010101           010010010101           1...
0100100101001100           110010010010010           XXX           01010010101           XXX           100100101010       ...
XXX            provides interfaces                                     010010010101                                       ...
XXX              XXX            XXX                     010010010101    010010010101   0100100101                component...
break it into pieces                    ✓ components                    • layers                    • modules             ...
presentation layer                                     business logic layer                                      integrati...
presentation layer                business logic layer                           integration layer                      bu...
break it into pieces                    ✓ components                    ✓ layers                    • modules             ...
modules?© 2011 Orientation in Objects GmbH
allowed intimacy level?© 2011 Orientation in Objects GmbH
modules?© 2011 Orientation in Objects GmbH
modules?© 2011 Orientation in Objects GmbH
break it into pieces                    ✓ components                    ✓ layers                    ✓ modules             ...
ring                                   tionsecurity                    monito                                 transac     ...
break it into pieces                    ✓ components                    ✓ layers                    ✓ modules             ...
break it into pieces                    ✓ VMs?© 2011 Orientation in Objects GmbH
integration?© 2011 Orientation in Objects GmbH
RCP Client             JSF Client                                           BL „1“     BL „2“     BL „3“                  ...
RCP Client                                            JSF Client                                                v.1.0     ...
RCP Client                                            JSF Client                                                          ...
windows?                                             tomcat                                                RCP Client     ...
#omfg                    • Release management?                    • Versioning?                    • Backwards compatibili...
EJB-JAR                                                       R                                     W                     ...
EJB-JAR                                                       R                                     W                     ...
EJB-JAR                                                       R                                     W                     ...
EJB-JAR                                                       R                                     W                     ...
dependencies / scopes                   BL                                                                                ...
POM                                                   artefact „2“                                          v1.0          ...
JSF Client                              Frontend Libs                                 RCP                                 ...
dead end with Java EE© 2011 Orientation in Objects GmbH
update                                             install           refresh                                            IN...
update                                             install           refresh                                            IN...
update                                             install           refresh                                            IN...
Java EE APIs                           don‘t fit into OSGi                                     e.g. ....                   ...
dead end with Java© 2011 Orientation in Objects GmbH
tools: a matter of context© 2011 Orientation in Objects GmbH
develop modular                                         software                    • APIs                    • IDEs      ...
build modular software                    • integration server                    • automated builds                    • ...
run modular software                    • runtime for modules                    • module/ app deployment                 ...
each tool is great                   • and does (mostly) not work with the others                   • no standard? no stan...
‣ Java 8, Jigsaw          ‣ Modularization?Session    ‣2013Topics
http://mreinhold.org/blog/cool            Wouldn’t it be               cool?          • You could write a Java application...
Meanwhile...                        Java X 8, ?                             7,                         super packages?    ...
Maven/ Ivy, Spring, JBoss, OSGi, OBR/ P2, Cloud                                     Helping ourselves© 2011 Orientation in...
There is not a moment to loose!© 2011 Orientation in Objects GmbH
Thanks!© 2011 Orientation in Objects GmbH
Modularization in java 8
Upcoming SlideShare
Loading in …5
×

Modularization in java 8

2,449 views

Published on

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.

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,449
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • PGT\n
  • \n
  • \n
  • OpenJDK mit jigsaw auf Suse 11.3 bauen\n======================================\n\nFolgende URL als Paketquelle in YAST hinzufügen:\n------------------------------------------------\nhttp://download.opensuse.org/repositories/Java:/openjdk6:/Factory/openSUSE_11.3/\n\nBenötigte Pakete installieren:\n------------------------------\nsudo zypper source-install -d java-1_7_0-openjdk\nsudo zypper install java-1_7_0-openjdk\nsudo zypper install make\nsudo zypper install mercurial\n\nMercurial Addon besorgen:\n-------------------------\nhg clone https://vogella@bitbucket.org/vogella/hgforest-crew\n\nMercurial config ".hgrc" im Homeverzeichnis anlegen mit folgendem Inhalt:\n-------------------------------------------------------------------------\n[extensions]\nforest=/root/hgforest/hgforest-crew/forest.py\n\nJDK 8 mit Jigsaw bauen\n=======================\n\nJDK 8 Jigsaw Sourcen laden:\n---------------------------\nhg fclone http://hg.openjdk.java.net/jigsaw/jigsaw/\n\nUmgebunsvariablen setzen:\n-------------------------\nexport LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-1.7.0-openjdk\nexport -n JAVA_HOME\n\nBauen:\n------\nmake ALLOW_DOWNLOADS=true\n\n1,5h warten ;-)\n---------------\n\nGebautes JDK prüfen:\n--------------------\n./build/linux-i586/bin/java -version\n\nJigsaw Anwendung bauen\n======================\n\nKompilieren von Modulen:\n------------------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/javac -d modules -modulepath modules -sourcepath modules `find modules -name '*.java'`\n\nModules verpacken:\n------------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jpkg -m modules/de.oio.service jmod de.oio.service\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jpkg -m modules/de.oio.test jmod de.oio.test\n\nMlib erstellen:\n---------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jmod create -L mlib\n\nModule in Mlib installieren:\n----------------------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jmod install de.oio.service@1.0.jmod de.oio.test@1.0.jmod -L mlib\n\nAusführen:\n----------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/java -L mlib -m de.oio.test\n
  • OpenJDK mit jigsaw auf Suse 11.3 bauen\n======================================\n\nFolgende URL als Paketquelle in YAST hinzufügen:\n------------------------------------------------\nhttp://download.opensuse.org/repositories/Java:/openjdk6:/Factory/openSUSE_11.3/\n\nBenötigte Pakete installieren:\n------------------------------\nsudo zypper source-install -d java-1_7_0-openjdk\nsudo zypper install java-1_7_0-openjdk\nsudo zypper install make\nsudo zypper install mercurial\n\nMercurial Addon besorgen:\n-------------------------\nhg clone https://vogella@bitbucket.org/vogella/hgforest-crew\n\nMercurial config ".hgrc" im Homeverzeichnis anlegen mit folgendem Inhalt:\n-------------------------------------------------------------------------\n[extensions]\nforest=/root/hgforest/hgforest-crew/forest.py\n\nJDK 8 mit Jigsaw bauen\n=======================\n\nJDK 8 Jigsaw Sourcen laden:\n---------------------------\nhg fclone http://hg.openjdk.java.net/jigsaw/jigsaw/\n\nUmgebunsvariablen setzen:\n-------------------------\nexport LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-1.7.0-openjdk\nexport -n JAVA_HOME\n\nBauen:\n------\nmake ALLOW_DOWNLOADS=true\n\n1,5h warten ;-)\n---------------\n\nGebautes JDK prüfen:\n--------------------\n./build/linux-i586/bin/java -version\n\nJigsaw Anwendung bauen\n======================\n\nKompilieren von Modulen:\n------------------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/javac -d modules -modulepath modules -sourcepath modules `find modules -name '*.java'`\n\nModules verpacken:\n------------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jpkg -m modules/de.oio.service jmod de.oio.service\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jpkg -m modules/de.oio.test jmod de.oio.test\n\nMlib erstellen:\n---------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jmod create -L mlib\n\nModule in Mlib installieren:\n----------------------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jmod install de.oio.service@1.0.jmod de.oio.test@1.0.jmod -L mlib\n\nAusführen:\n----------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/java -L mlib -m de.oio.test\n
  • OpenJDK mit jigsaw auf Suse 11.3 bauen\n======================================\n\nFolgende URL als Paketquelle in YAST hinzufügen:\n------------------------------------------------\nhttp://download.opensuse.org/repositories/Java:/openjdk6:/Factory/openSUSE_11.3/\n\nBenötigte Pakete installieren:\n------------------------------\nsudo zypper source-install -d java-1_7_0-openjdk\nsudo zypper install java-1_7_0-openjdk\nsudo zypper install make\nsudo zypper install mercurial\n\nMercurial Addon besorgen:\n-------------------------\nhg clone https://vogella@bitbucket.org/vogella/hgforest-crew\n\nMercurial config ".hgrc" im Homeverzeichnis anlegen mit folgendem Inhalt:\n-------------------------------------------------------------------------\n[extensions]\nforest=/root/hgforest/hgforest-crew/forest.py\n\nJDK 8 mit Jigsaw bauen\n=======================\n\nJDK 8 Jigsaw Sourcen laden:\n---------------------------\nhg fclone http://hg.openjdk.java.net/jigsaw/jigsaw/\n\nUmgebunsvariablen setzen:\n-------------------------\nexport LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-1.7.0-openjdk\nexport -n JAVA_HOME\n\nBauen:\n------\nmake ALLOW_DOWNLOADS=true\n\n1,5h warten ;-)\n---------------\n\nGebautes JDK prüfen:\n--------------------\n./build/linux-i586/bin/java -version\n\nJigsaw Anwendung bauen\n======================\n\nKompilieren von Modulen:\n------------------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/javac -d modules -modulepath modules -sourcepath modules `find modules -name '*.java'`\n\nModules verpacken:\n------------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jpkg -m modules/de.oio.service jmod de.oio.service\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jpkg -m modules/de.oio.test jmod de.oio.test\n\nMlib erstellen:\n---------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jmod create -L mlib\n\nModule in Mlib installieren:\n----------------------------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/jmod install de.oio.service@1.0.jmod de.oio.test@1.0.jmod -L mlib\n\nAusführen:\n----------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/java -L mlib -m de.oio.test\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • CD\n
  • \n
  • \n
  • \n
  • \n
  • David Bosschaert: http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html\n\nSome argued that the module source definition should be in a .java file and because it's in a .java file there should be a compiled .class file in the resulting Jar file. However, I think that the structure of a module definition screams for a specific DSL that might be quite different from ordinary Java. Especially the extensibility requirement makes a DSL much more natural than a traditional .java source file. I think the module definition should be in  META-INF/module.jmod or something like that. Then it becomes natural to migrate that file as-is to the resulting jar. In a sense the existing MANIFEST.MF does cover most of the requirements. Sure, it has some issues (esp. the 76 chars-per-line limit) but it's clear, simple and extensible - and - it is readable by humans in the Jar file.\n
  • \n
  • \n
  • A:\nHaving a distinct compiled form would complicate or eliminate usage scenarios in which people or tools update module metadata independently of compilation tools. \nIt avoids the need to specify a compiled form, which gives implementors more freedom to choose efficient internal private forms, but only if they are unobservable (e.g., constructed in the process of caching). \n\nB:\nIt is more efficient to read in a structured binary than to parse source-form Java module declarations. When combined with new ways of packaging compiled files it may even open up opportunities for further efficiencies. \nIf it’s decided that the names of module declaration files should end with the string “.java”, then why should there be an exception to the convention that “.java” files always compile into “.class” files? Creating such an exception would violate the principle of least surprise, presenting one more stumbling block to developers trying to adopt the module system. \nA compiled form helps to ensure validity, since it’s more difficult to modify a file incorrectly when doing so requires the use of a tool. This will help to reduce failures in all phases, and especially at deployment time. \n
  • \n
  • == Require Bundle aus OSGi\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • David Bosschaert: http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html\nI don't see why this requirement is needed and I actually think it's bad because it doesn't encourage extending the module definitions. Again, the MANIFEST.MF is a good example where this was not done (standard headers are mixed with custom headers) and it has proven to be extremely useful.Let's come up with a module definition syntax that encourages extensions and where those extensions happily co-exist with the JavaSE definitions.\n\nGlyn Normington gnormington at vmware.com :\nHi Mark I'm pleased to see the explicit acknowledgement of some basic OSGi interoperation requirements in the requirements document ([1]). I agree with David Bosschaert ([2]), that it would make sense for OSGi to support the Java SE 8 module format and, for modules which can serve equally well as OSGi bundles, I'd like to avoid dual-maintenance of module metadata and OSGi manifest. I'd like to be able to "decorate" the standard metadata. However, the requirement "The syntax must place all extended metadata after all standard metadata, with a clear delineation between them." precludes inline decorations. The result would be duplication and clunkiness. I propose that this requirement be changed so that standard metadata could be decorated inline (the decorations would be ignored by the Java SE module system). What do you think? \n
  • David Loyd – Red Hat: http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsReviewPart1#H-FundamentalsTargetConstraintsOnModules \nThe fundamentals paragraph items all indicate a strong sense that the Jigsaw project is on the right general track. However I found a couple sections noteworthy:\nResolution in all phases — Build-time, install-time, and run-time module resolution and linking must all be supported. UNIX has all three models and they are all still in use 40 years later.coupled with the following paragraph:\nFidelity 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.and this one:\nVersioning — 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.\n\nThese seemingly reasonable statements hide a particularly tricky little goblin; namely, build reproducibility. At build-time, an artifact (to use the Maven term) is identified in part by its version. And that identity has a specific meaning. If I check out version 1.2.3 of jboss-cobwobble from source control and build it, I should get an artifact which is equivalent to one which anyone else who checks out and builds the same version of the same project gets.\nHowever, that means that such builds cannot use version ranges. By definition this creates a way for two parties building the same project to get different output, thus blurring the meaning of what a version is. In the first paragraph, Mark emphasises the similarities to the shared library model and recommends that similar practices be followed to that paradigm, however there is a key difference in that when one builds against a shared library the linkage is much less invasive. A change to a compiled library used by a project does not generally affect the compilation results of that project, whereas in Java this is much easier to do, since class files are a much richer format than a shared object symbol table.\nTherefore it is very important to allow (better yet, require) builds to use specific dependency versions when building, and allow version ranges only at install and run time, where version ranges are a much better fit.\n\nBsp: you can add a more specific method, which would change how the same code is compiled the next time it is compiled; you can change the return type of a method to make it covariant, causing linking to occur to the new bridge method instead of the original; I'm sure there are quite a few generics changes you can do which cause compilation against a bridge method. Etc, etc.\n
  • \n
  • http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series-roman.html\n
  • http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series-roman.html\n
  • http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series-roman.html\n
  • http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series-roman.html\n
  • David Loyd – Red Hat: http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsReviewPart1#H-FundamentalsTargetConstraintsOnModules \nThe fundamentals paragraph items all indicate a strong sense that the Jigsaw project is on the right general track. However I found a couple sections noteworthy:\nResolution in all phases — Build-time, install-time, and run-time module resolution and linking must all be supported. UNIX has all three models and they are all still in use 40 years later.coupled with the following paragraph:\nFidelity 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.and this one:\nVersioning — 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.\n\nThese seemingly reasonable statements hide a particularly tricky little goblin; namely, build reproducibility. At build-time, an artifact (to use the Maven term) is identified in part by its version. And that identity has a specific meaning. If I check out version 1.2.3 of jboss-cobwobble from source control and build it, I should get an artifact which is equivalent to one which anyone else who checks out and builds the same version of the same project gets.\nHowever, that means that such builds cannot use version ranges. By definition this creates a way for two parties building the same project to get different output, thus blurring the meaning of what a version is. In the first paragraph, Mark emphasises the similarities to the shared library model and recommends that similar practices be followed to that paradigm, however there is a key difference in that when one builds against a shared library the linkage is much less invasive. A change to a compiled library used by a project does not generally affect the compilation results of that project, whereas in Java this is much easier to do, since class files are a much richer format than a shared object symbol table.\nTherefore it is very important to allow (better yet, require) builds to use specific dependency versions when building, and allow version ranges only at install and run time, where version ranges are a much better fit.\n\nBsp: you can add a more specific method, which would change how the same code is compiled the next time it is compiled; you can change the return type of a method to make it covariant, causing linking to occur to the new bridge method instead of the original; I'm sure there are quite a few generics changes you can do which cause compilation against a bridge method. Etc, etc.\n
  • David Loyd – Red Hat: http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsReviewPart1#H-FundamentalsTargetConstraintsOnModules \nThe fundamentals paragraph items all indicate a strong sense that the Jigsaw project is on the right general track. However I found a couple sections noteworthy:\nResolution in all phases — Build-time, install-time, and run-time module resolution and linking must all be supported. UNIX has all three models and they are all still in use 40 years later.coupled with the following paragraph:\nFidelity 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.and this one:\nVersioning — 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.\n\nThese seemingly reasonable statements hide a particularly tricky little goblin; namely, build reproducibility. At build-time, an artifact (to use the Maven term) is identified in part by its version. And that identity has a specific meaning. If I check out version 1.2.3 of jboss-cobwobble from source control and build it, I should get an artifact which is equivalent to one which anyone else who checks out and builds the same version of the same project gets.\nHowever, that means that such builds cannot use version ranges. By definition this creates a way for two parties building the same project to get different output, thus blurring the meaning of what a version is. In the first paragraph, Mark emphasises the similarities to the shared library model and recommends that similar practices be followed to that paradigm, however there is a key difference in that when one builds against a shared library the linkage is much less invasive. A change to a compiled library used by a project does not generally affect the compilation results of that project, whereas in Java this is much easier to do, since class files are a much richer format than a shared object symbol table.\nTherefore it is very important to allow (better yet, require) builds to use specific dependency versions when building, and allow version ranges only at install and run time, where version ranges are a much better fit.\n\nBsp: you can add a more specific method, which would change how the same code is compiled the next time it is compiled; you can change the return type of a method to make it covariant, causing linking to occur to the new bridge method instead of the original; I'm sure there are quite a few generics changes you can do which cause compilation against a bridge method. Etc, etc.\n
  • Scott Stark \n\nhttp://community.jboss.org/wiki/ModulesInJava8\n\ndon't understand why multi-version support only applies when type collisions can be detected. \n\nWhy isn't this just required when dependencies demand it?\n
  • \n
  • \n
  • \n
  • Scott Stark http://community.jboss.org/wiki/ModulesInJava8\n\nmaven support is more of a usecase for pluggable loading\n\n
  • Scott Stark http://community.jboss.org/wiki/ModulesInJava8\n\n\nOSGi support also seems like a usecase for pluggable module resolution.\n\n
  • Scott Stark http://community.jboss.org/wiki/ModulesInJava8\n\nmanipuable module metadata; doesn't this imply not using java language syntax for metadata?\n
  • David Loyd – Red Hat: http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsReviewPart1#H-FundamentalsTargetConstraintsOnModules \n\nI am very much against this notion. One module, one class loader, period, end of story. If you are splitting a single class loader among many modules, you haven't created modules, you've created one module with a class path of several JARs, of which some stuff may be missing and others not, and a hell of a lot of useless complexity, all for the privilege of saying sure, we modularized this. There is no isolation of any sort between them beyond your standard access controls provided by the Java language. Without a strong definition of a module as an encapsulating vehicle for a class loader, the whole idea is weakened - visibility is only sensibly enforced in terms of whole class loaders (yes, while it is probably possible to use a different unit of division like class, it will definitely have a negative performance impact).\nRather than thus weakening the definition of a module, I recommend that modules be allowed to be packaged in portions, which may be separately shipped and installed - perhaps a module/submodule concept could be introduced, where the contract of a submodule is clearly defined as sharing the parent module's class loader. In other words, the label should be clearly marked, so to speak. There is no reasonable expectation that a package may be split between modules, and doing so is definitely a violation of the Principle of Least WTF.\n\nScott Stark http://community.jboss.org/wiki/ModulesInJava8\nthis seems to be in conflict with the notion of target constraints. If I have a CDC module exporting java.util.*, why would I have another module that also applies to the CDC target platform also exporting java.util.*? (anders formuliert : Könnte man das CDC-Beispiel nicht mit Target Constraints lösen ???)\n\nPackage Subsets führt zu Split packages – ist in OSGi lösbar durch Require-Bundle führt zu Illegal Access Errors (Folien siehe JBoss)\nSee the OSGi core specification, section 3.12.3, for some more good reasons not to do it.\n\nA module system that encourages split packages will require tools that can manage modularity at the level of types rather than packages. How many types are there in an average Java package… twenty, thirty? That is how many times more difficult it will be to design and assemble coherent modules with Jigsaw.\n
  • == Require Bundle aus OSGi\n
  • \n
  • David Loyd – Red Hat: http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsReviewPart1#H-FundamentalsTargetConstraintsOnModules \n\nI am very much against this notion. One module, one class loader, period, end of story. If you are splitting a single class loader among many modules, you haven't created modules, you've created one module with a class path of several JARs, of which some stuff may be missing and others not, and a hell of a lot of useless complexity, all for the privilege of saying sure, we modularized this. There is no isolation of any sort between them beyond your standard access controls provided by the Java language. Without a strong definition of a module as an encapsulating vehicle for a class loader, the whole idea is weakened - visibility is only sensibly enforced in terms of whole class loaders (yes, while it is probably possible to use a different unit of division like class, it will definitely have a negative performance impact).\nRather than thus weakening the definition of a module, I recommend that modules be allowed to be packaged in portions, which may be separately shipped and installed - perhaps a module/submodule concept could be introduced, where the contract of a submodule is clearly defined as sharing the parent module's class loader. In other words, the label should be clearly marked, so to speak. There is no reasonable expectation that a package may be split between modules, and doing so is definitely a violation of the Principle of Least WTF.\n\nScott Stark http://community.jboss.org/wiki/ModulesInJava8\nthis seems to be in conflict with the notion of target constraints. If I have a CDC module exporting java.util.*, why would I have another module that also applies to the CDC target platform also exporting java.util.*? (anders formuliert : Könnte man das CDC-Beispiel nicht mit Target Constraints lösen ???)\n\nPackage Subsets führt zu Split packages – ist in OSGi lösbar durch Require-Bundle führt zu Illegal Access Errors (Folien siehe JBoss)\nSee the OSGi core specification, section 3.12.3, for some more good reasons not to do it.\n\nA module system that encourages split packages will require tools that can manage modularity at the level of types rather than packages. How many types are there in an average Java package… twenty, thirty? That is how many times more difficult it will be to design and assemble coherent modules with Jigsaw.\n
  • \n
  • David Loyd – Red Hat: http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsReviewPart1#H-FundamentalsTargetConstraintsOnModules \n\nIf the purpose of this is security, which I can very much get behind, then I think the only sensible approach is to constrain module loading to signed modules. Otherwise, if the goal is simply to create a mechanism by which administrators can annoy each other, then I guess this fits the bill; the restriction can be bypassed by changing the metadata, which means that it provides neither security nor convenience.\n\nScott Stark http://community.jboss.org/wiki/ModulesInJava8\n\nmodule/target constraints seems to be a secondary requirement\n\n\n Target Plattform?\n Sicherheit über änderbare Metadaten ?\n Lizenzmetadaten ?\n
  • David Loyd – Red Hat: http://in.relation.to/Bloggers/ModulesInJDK8AndProjectJigsawRequirementsReviewPart1#H-FundamentalsTargetConstraintsOnModules \n\nI am very much against this notion. One module, one class loader, period, end of story. If you are splitting a single class loader among many modules, you haven't created modules, you've created one module with a class path of several JARs, of which some stuff may be missing and others not, and a hell of a lot of useless complexity, all for the privilege of saying sure, we modularized this. There is no isolation of any sort between them beyond your standard access controls provided by the Java language. Without a strong definition of a module as an encapsulating vehicle for a class loader, the whole idea is weakened - visibility is only sensibly enforced in terms of whole class loaders (yes, while it is probably possible to use a different unit of division like class, it will definitely have a negative performance impact).\nRather than thus weakening the definition of a module, I recommend that modules be allowed to be packaged in portions, which may be separately shipped and installed - perhaps a module/submodule concept could be introduced, where the contract of a submodule is clearly defined as sharing the parent module's class loader. In other words, the label should be clearly marked, so to speak. There is no reasonable expectation that a package may be split between modules, and doing so is definitely a violation of the Principle of Least WTF.\n\nScott Stark http://community.jboss.org/wiki/ModulesInJava8\nthis seems to be in conflict with the notion of target constraints. If I have a CDC module exporting java.util.*, why would I have another module that also applies to the CDC target platform also exporting java.util.*? (anders formuliert : Könnte man das CDC-Beispiel nicht mit Target Constraints lösen ???)\n\nPackage Subsets führt zu Split packages – ist in OSGi lösbar durch Require-Bundle führt zu Illegal Access Errors (Folien siehe JBoss)\nSee the OSGi core specification, section 3.12.3, for some more good reasons not to do it.\n\nA module system that encourages split packages will require tools that can manage modularity at the level of types rather than packages. How many types are there in an average Java package… twenty, thirty? That is how many times more difficult it will be to design and assemble coherent modules with Jigsaw.\n
  • Enforcement, Hiding, Cost of Dependencies, Package Sharing, Versioningm Unexpected Consequences of API based Programming, ...\n
  • \n
  • @ 30m - 40m\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • package modules\n do class sharing\n do instance sharing\n no versions\n no visibility constraints\n no module lifecycle\n
  • package modules\n do class sharing\n do instance sharing\n no versions\n no visibility constraints\n no module lifecycle\n
  • package modules\n do class sharing\n do instance sharing\n no versions\n no visibility constraints\n no module lifecycle\n
  • Bei OSGi ist es andersrum. Oder war es zum Teil. Mit 4.2 bekommen wir doch Spring dm als fine grained RI, oder?\n\n compile time dependencies handled by compiler, IDE, classpath\n runtime dependency declared/ managed in context\n
  • Bei OSGi ist es andersrum. Oder war es zum Teil. Mit 4.2 bekommen wir doch Spring dm als fine grained RI, oder?\n because we have versions\n solve version problems at compile time\n no fancy-OSGi features at runtime\n
  • \n
  • \n - nicht auflösbare modul-versions-konflikte\n -> repackaging\n\n- Sichtbarkeit\n\n-> naming conventions ITextField\n-> naming conventions (nicht impl package von fremden modulen verwenden)\n\n- nur sehr einfache (proprietäre) Plugin-Architekturen umsetzbar\n-> Fairplay\n\n- Laufzeit rauf-runter-fahren von Modulen\n\n\n- Modularisierung kein standard -> tools, libs können nicht darauf aufbauen\n
  • Bei OSGi ist es andersrum. Oder war es zum Teil. Mit 4.2 bekommen wir doch Spring dm als fine grained RI, oder?\n
  • Bei OSGi ist es andersrum. Oder war es zum Teil. Mit 4.2 bekommen wir doch Spring dm als fine grained RI, oder?\n
  • \n
  • \n - nicht auflösbare modul-versions-konflikte\n -> repackaging\n\n- Sichtbarkeit\n\n-> naming conventions ITextField\n-> naming conventions (nicht impl package von fremden modulen verwenden)\n\n- nur sehr einfache (proprietäre) Plugin-Architekturen umsetzbar\n-> Fairplay\n\n- Laufzeit rauf-runter-fahren von Modulen\n\n\n- Modularisierung kein standard -> tools, libs können nicht darauf aufbauen\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • @55\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Modularization in java 8

    1. 1. Modularisierung in Java 8 c.dedek | Orientation In Objects GmbH p.g.taboada | pgt technology scouting GmbH
    2. 2. 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
    3. 3. ‣Java 8, Jigsaw ‣ Modularization? ‣ 2013SessionTopics
    4. 4. 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© 2011 Orientation in Objects GmbH
    5. 5. “ 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© 2011 Orientation in Objects GmbH
    6. 6. “ That loses the benefits of information hiding, which is clearly suboptimal and a long-standing complaint that often comes up in language discussions in forums such as JavaOne. Blog: Superpackage strawman and the JSR 294 mailing list© 2011 Orientation in Objects GmbH
    7. 7. “ However, if a project is too large to fit into a single package, Java does not provide a suitable encapsulation mechanism. Blog: Superpackage strawman and the JSR 294 mailing list© 2011 Orientation in Objects GmbH
    8. 8. 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 first half of 2009, Public Review in the second half of 2009, and Proposed Final Draft in the first 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© 2011 Orientation in Objects GmbH
    9. 9. Status: Inactive© 2011 Orientation in Objects GmbH
    10. 10. • 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© 2011 Orientation in Objects GmbH
    11. 11. 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/© 2011 Orientation in Objects GmbH
    12. 12. First, build your own JDK8© 2011 Orientation in Objects GmbH
    13. 13. 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© 2011 Orientation in Objects GmbH
    14. 14. Mercurial Addon besorgen: ------------------------- hg clone https://vogella@bitbucket.org/vogella/hgforest-crew Mercurial config ".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/© 2011 Orientation in Objects GmbH
    15. 15. 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 ;-) ---------------© 2011 Orientation in Objects GmbH
    16. 16. 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© 2011 Orientation in Objects GmbH
    17. 17. Do the hello world thing© 2011 Orientation in Objects GmbH
    18. 18. 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)); } }© 2011 Orientation in Objects GmbH
    19. 19. # de.oio.test kompilieren javac -d modules -modulepath modules -sourcepath modules `find modules -name *.java`© 2011 Orientation in Objects GmbH
    20. 20. © 2011 Orientation in Objects GmbH
    21. 21. # jmods erstellen jpkg -m modules/de.oio.service jmod de.oio.service jpkg -m modules/de.oio.test jmod de.oio.test© 2011 Orientation in Objects GmbH
    22. 22. © 2011 Orientation in Objects GmbH
    23. 23. # 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© 2011 Orientation in Objects GmbH
    24. 24. © 2011 Orientation in Objects GmbH
    25. 25. # Ausführen java -L mlib -m de.oio.test@1.0© 2011 Orientation in Objects GmbH
    26. 26. © 2011 Orientation in Objects GmbH
    27. 27. 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© 2011 Orientation in Objects GmbH
    28. 28. Java Module-System Requirements DRAFT 12 ? JSR TBD ! OSGi Jigsaw Ref Impl© 2011 Orientation in Objects GmbH
    29. 29. 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 classhttp://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12 © 2011 Orientation in Objects GmbH
    30. 30. META-INF Java Syntax Erweiterung Form of definition© 2011 Orientation in Objects GmbH
    31. 31. 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© 2011 Orientation in Objects GmbH
    32. 32. 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© 2011 Orientation in Objects GmbH
    33. 33. 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© 2011 Orientation in Objects GmbH
    34. 34. 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”.© 2011 Orientation in Objects GmbH
    35. 35. 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.© 2011 Orientation in Objects GmbH
    36. 36. A B API .... Export-Package: API Import-Package: API Deklarationslevel© 2011 Orientation in Objects GmbH
    37. 37. A B API .... module B @ 1.0 { requires A; } Deklarationslevel© 2011 Orientation in Objects GmbH
    38. 38. 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).© 2011 Orientation in Objects GmbH
    39. 39. 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© 2011 Orientation in Objects GmbH
    40. 40. A B API 1 .... API 2 Refactoring - OSGi© 2011 Orientation in Objects GmbH
    41. 41. A API 1 B .... A‘ API 2 Refactoring - OSGi© 2011 Orientation in Objects GmbH
    42. 42. A B API 1 .... API 2 Refactoring - Jigsaw© 2011 Orientation in Objects GmbH
    43. 43. A API 1 B .... A‘ API 2 ? Refactoring - Jigsaw© 2011 Orientation in Objects GmbH
    44. 44. A API 1 B .... A‘ API 2 Refactoring - Jigsaw© 2011 Orientation in Objects GmbH
    45. 45. "The syntax must place all extended metadata after all standard metadata, with a clear delineation between them." Extensible module declarations© 2011 Orientation in Objects GmbH
    46. 46. Versions • The module system must support common version-string schemes such as those defined 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.© 2011 Orientation in Objects GmbH
    47. 47. support common version-string schemes?!?© 2011 Orientation in Objects GmbH
    48. 48. 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© 2011 Orientation in Objects GmbH
    49. 49. Mercury Venus Earth Mars Jupiter Saturn Uranus module Home @ Earth { Neptune requires InnerSystem @ [Mercury,Earth) requires OuterSystem @ (Earth,Neptune] permits Asteroids @ (Mars,Jupiter) } http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series.html© 2011 Orientation in Objects GmbH
    50. 50. But not 2.3, because thats 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© 2011 Orientation in Objects GmbH
    51. 51. !!! module IrrationalVersioningSystem @ ∞ { requires TeX @ [3.14159,π), requires METAFONT @ [2.718,e), permits Historic @ √66, } http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series.html© 2011 Orientation in Objects GmbH
    52. 52. 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.© 2011 Orientation in Objects GmbH
    53. 53. 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.© 2011 Orientation in Objects GmbH
    54. 54. 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.© 2011 Orientation in Objects GmbH
    55. 55. This most likely means???© 2011 Orientation in Objects GmbH
    56. 56. OSGi: Because Sharing Shouldnt Be Painful http://www.theserverside.com/feature/OSGi-Because-Sharing-Shouldnt-Be-Painful© 2011 Orientation in Objects GmbH
    57. 57. Migration and interoperation • Maven support • OSGi support • Manipulable module metadata© 2011 Orientation in Objects GmbH
    58. 58. 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.© 2011 Orientation in Objects GmbH
    59. 59. 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.© 2011 Orientation in Objects GmbH
    60. 60. 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.© 2011 Orientation in Objects GmbH
    61. 61. Package subsets • Package subsets — In support of platform modularization, it must be possible for the types defined 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 defined. OSGi: Split Packages!© 2011 Orientation in Objects GmbH
    62. 62. A B API .... module B @ 1.0 { requires A; } Deklarationslevel© 2011 Orientation in Objects GmbH
    63. 63. BootstrapClassloader Classloader 2 Classloader 1 JAR org.jboss.chap2.ex0.ExtCtx org.jboss.chap2.ex0.ExtObj Exceptions mit Classloadern© 2011 Orientation in Objects GmbH
    64. 64. Package subsets • Package subsets — In support of platform modularization, it must be possible for the types defined 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 defined. OSGi: Noooo!© 2011 Orientation in Objects GmbH
    65. 65. CDC-sized subsets?© 2011 Orientation in Objects GmbH
    66. 66. 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.© 2011 Orientation in Objects GmbH
    67. 67. Shared class loaders • In support of platform modularization, it must be possible to declare that the types defined in a specific set of modules must be loaded by the same class loader.© 2011 Orientation in Objects GmbH
    68. 68. 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© 2011 Orientation in Objects GmbH
    69. 69. 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.© 2011 Orientation in Objects GmbH
    70. 70. ‣ Java 8, Jigsaw ‣ Modularization?Session ‣ 2013Topics
    71. 71. where does modularization happen?© 2011 Orientation in Objects GmbH
    72. 72. Wikipedia... As documentation produced by architects, typically drawings, plans and technical specifications, architecture defines the structure and/or behavior of a building or any other kind of system that is to be or has been constructed.© 2011 Orientation in Objects GmbH
    73. 73. so, is it a matter of architecture?© 2011 Orientation in Objects GmbH
    74. 74. super-architect© 2011 Orientation in Objects GmbH
    75. 75. Divide & Conquer© 2011 Orientation in Objects GmbH
    76. 76. break it into pieces • components • layers • modules • aspects?© 2011 Orientation in Objects GmbH
    77. 77. 0100100101001100 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 bad guy© 2011 Orientation in Objects GmbH
    78. 78. 0100100101001100 I am amonolithical thing! 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 bad guy© 2011 Orientation in Objects GmbH
    79. 79. 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© 2011 Orientation in Objects GmbH
    80. 80. 0100100101001100 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 see the duplicate code?© 2011 Orientation in Objects GmbH
    81. 81. 0100100101001100 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 re-use it!© 2011 Orientation in Objects GmbH
    82. 82. 0100100101001100 110010010010010 XXX 01010010101 XXX 100100101010 10101010 XXX XXX 101 101111001011 010010010101 0101010101 lifecycle? state? runtime?© 2011 Orientation in Objects GmbH
    83. 83. XXX provides interfaces 010010010101 provides services managed bean (ioc)!© 2011 Orientation in Objects GmbH
    84. 84. XXX XXX XXX 010010010101 010010010101 0100100101 component based development© 2011 Orientation in Objects GmbH
    85. 85. break it into pieces ✓ components • layers • modules • aspects?© 2011 Orientation in Objects GmbH
    86. 86. presentation layer business logic layer integration layer layers© 2011 Orientation in Objects GmbH
    87. 87. presentation layer business logic layer integration layer business session service beans manager daos delegate facade beans transfer objects converters entity beans layers© 2011 Orientation in Objects GmbH
    88. 88. break it into pieces ✓ components ✓ layers • modules • aspects?© 2011 Orientation in Objects GmbH
    89. 89. modules?© 2011 Orientation in Objects GmbH
    90. 90. allowed intimacy level?© 2011 Orientation in Objects GmbH
    91. 91. modules?© 2011 Orientation in Objects GmbH
    92. 92. modules?© 2011 Orientation in Objects GmbH
    93. 93. break it into pieces ✓ components ✓ layers ✓ modules • aspects?© 2011 Orientation in Objects GmbH
    94. 94. ring tionsecurity monito transac minimum aop? business logic layer integration layer business logic layer integration layer business logic layer integration © 2011 Orientation in Objects GmbH layer
    95. 95. break it into pieces ✓ components ✓ layers ✓ modules ✓ aspects?© 2011 Orientation in Objects GmbH
    96. 96. break it into pieces ✓ VMs?© 2011 Orientation in Objects GmbH
    97. 97. integration?© 2011 Orientation in Objects GmbH
    98. 98. RCP Client JSF Client BL „1“ BL „2“ BL „3“ DAO „A“ DAO „B“ DAO „C“ DAO „D“ simple 2 client situation© 2011 Orientation in Objects GmbH
    99. 99. RCP Client JSF Client 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 DAO „A“ DAO „B“ DAO „C“ DAO „D“ ... with versions ...© 2011 Orientation in Objects GmbH
    100. 100. RCP Client JSF Client 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 DAO „A“ DAO „B“ DAO „C“ DAO „D“ and 3rd party libs© 2011 Orientation in Objects GmbH
    101. 101. 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 DAO „A“ DAO „B“ DAO „C“ DAO „D“ and runtimes© 2011 Orientation in Objects GmbH
    102. 102. #omfg • Release management? • Versioning? • Backwards compatibility? • Dependency resolution & mediation? • Compiletime vs. runtime? • Visibility? • Deployment, scalability, availability?© 2011 Orientation in Objects GmbH
    103. 103. EJB-JAR R W l JA AR uti Java EE© 2011 Orientation in Objects GmbH
    104. 104. EJB-JAR R W l JA AR utiServlets, EJBs, ... Java EE© 2011 Orientation in Objects GmbH
    105. 105. EJB-JAR R W l JA AR utiServlets, EJBs, ... EAR Java EE© 2011 Orientation in Objects GmbH
    106. 106. EJB-JAR R W l JA AR utiServlets, EJBs, ... EAR Java EE© 2011 Orientation in Objects GmbH
    107. 107. dependencies / scopes BL configuration runtime testtime modularization? compiletime DAO interface impl mock template hibernate api SCOPES© 2011 Orientation in Objects GmbH
    108. 108. POM artefact „2“ v1.0 artefact „1“ v1.2 artefact „3“ Maven (ivy too...)© 2011 Orientation in Objects GmbH
    109. 109. 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© 2011 Orientation in Objects GmbH
    110. 110. dead end with Java EE© 2011 Orientation in Objects GmbH
    111. 111. update install refresh INSTALLED STARTING resolve update start stop refresh RESOLVED ACTIVE uninstall uninstall stop UNINSTALLED STOPPING Bundle OSGi© 2011 Orientation in Objects GmbH
    112. 112. update install refresh INSTALLED STARTING resolve update start stop refresh RESOLVED ACTIVE uninstall uninstall stop UNINSTALLED STOPPING Bundle OSGi© 2011 Orientation in Objects GmbH
    113. 113. update install refresh INSTALLED STARTING resolve update start stop refresh RESOLVED ACTIVE uninstall uninstall stop UNINSTALLED STOPPING Bundle OSGi© 2011 Orientation in Objects GmbH
    114. 114. Java EE APIs don‘t fit into OSGi e.g. .... monolothical configs classloading nightmares don‘t work by design© 2011 Orientation in Objects GmbH
    115. 115. dead end with Java© 2011 Orientation in Objects GmbH
    116. 116. tools: a matter of context© 2011 Orientation in Objects GmbH
    117. 117. develop modular software • APIs • IDEs • Test-Frameworks© 2011 Orientation in Objects GmbH
    118. 118. build modular software • integration server • automated builds • distributed builds? • provisioning? • release management?© 2011 Orientation in Objects GmbH
    119. 119. run modular software • runtime for modules • module/ app deployment • intelligent (?) clustering?© 2011 Orientation in Objects GmbH
    120. 120. each tool is great • and does (mostly) not work with the others • no standard? no standard tooling.© 2011 Orientation in Objects GmbH
    121. 121. ‣ Java 8, Jigsaw ‣ Modularization?Session ‣2013Topics
    122. 122. 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? • (...)© 2011 Orientation in Objects GmbH
    123. 123. Meanwhile... Java X 8, ? 7, super packages? modules? simplified module system? dynamic modules? ==> Java EE ?!?© 2011 Orientation in Objects GmbH
    124. 124. Maven/ Ivy, Spring, JBoss, OSGi, OBR/ P2, Cloud Helping ourselves© 2011 Orientation in Objects GmbH
    125. 125. There is not a moment to loose!© 2011 Orientation in Objects GmbH
    126. 126. Thanks!© 2011 Orientation in Objects GmbH

    ×