• Save
Modularization in java 8
Upcoming SlideShare
Loading in...5
×
 

Modularization in java 8

on

  • 1,999 views

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.

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.

Statistics

Views

Total Views
1,999
Views on SlideShare
1,999
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \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 Modularization in java 8 Presentation Transcript

  • 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? ‣ 2013SessionTopics
  • 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
  • “ 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
  • “ 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
  • “ 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
  • 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
  • Status: Inactive© 2011 Orientation in Objects GmbH
  • • 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
  • 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
  • First, build your own JDK8© 2011 Orientation in Objects GmbH
  • 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
  • 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
  • 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
  • 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
  • Do the hello world thing© 2011 Orientation in Objects GmbH
  • 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
  • # de.oio.test kompilieren javac -d modules -modulepath modules -sourcepath modules `find modules -name *.java`© 2011 Orientation in Objects GmbH
  • © 2011 Orientation in Objects GmbH
  • # 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
  • © 2011 Orientation in Objects GmbH
  • # 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
  • © 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 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
  • Java Module-System Requirements DRAFT 12 ? JSR TBD ! OSGi Jigsaw Ref Impl© 2011 Orientation in Objects GmbH
  • 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
  • META-INF Java Syntax Erweiterung Form of definition© 2011 Orientation in Objects GmbH
  • 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
  • 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
  • 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
  • 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
  • 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
  • A B API .... Export-Package: API Import-Package: API Deklarationslevel© 2011 Orientation in Objects GmbH
  • A B API .... module B @ 1.0 { requires A; } Deklarationslevel© 2011 Orientation in Objects GmbH
  • 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
  • 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
  • A B API 1 .... API 2 Refactoring - OSGi© 2011 Orientation in Objects GmbH
  • A API 1 B .... A‘ API 2 Refactoring - OSGi© 2011 Orientation in Objects GmbH
  • A B API 1 .... API 2 Refactoring - Jigsaw© 2011 Orientation in Objects GmbH
  • A API 1 B .... A‘ API 2 ? Refactoring - Jigsaw© 2011 Orientation in Objects GmbH
  • A API 1 B .... A‘ API 2 Refactoring - Jigsaw© 2011 Orientation in Objects GmbH
  • "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
  • 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
  • support common version-string schemes?!?© 2011 Orientation in Objects GmbH
  • 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
  • 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
  • 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
  • !!! 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
  • 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
  • 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
  • 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
  • This most likely means???© 2011 Orientation in Objects GmbH
  • OSGi: Because Sharing Shouldnt Be Painful http://www.theserverside.com/feature/OSGi-Because-Sharing-Shouldnt-Be-Painful© 2011 Orientation in Objects GmbH
  • Migration and interoperation • Maven support • OSGi support • Manipulable module metadata© 2011 Orientation in Objects GmbH
  • 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
  • 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
  • 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
  • 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
  • A B API .... module B @ 1.0 { requires A; } Deklarationslevel© 2011 Orientation in Objects GmbH
  • BootstrapClassloader Classloader 2 Classloader 1 JAR org.jboss.chap2.ex0.ExtCtx org.jboss.chap2.ex0.ExtObj Exceptions mit Classloadern© 2011 Orientation in Objects GmbH
  • 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
  • CDC-sized subsets?© 2011 Orientation in Objects GmbH
  • 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
  • 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
  • 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
  • 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
  • ‣ 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 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
  • 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 • modules • aspects?© 2011 Orientation in Objects GmbH
  • 0100100101001100 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 bad guy© 2011 Orientation in Objects GmbH
  • 0100100101001100 I am amonolithical thing! 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 bad guy© 2011 Orientation in Objects GmbH
  • 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
  • 0100100101001100 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 see the duplicate code?© 2011 Orientation in Objects GmbH
  • 0100100101001100 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 re-use it!© 2011 Orientation in Objects GmbH
  • 0100100101001100 110010010010010 XXX 01010010101 XXX 100100101010 10101010 XXX XXX 101 101111001011 010010010101 0101010101 lifecycle? state? runtime?© 2011 Orientation in Objects GmbH
  • XXX provides interfaces 010010010101 provides services managed bean (ioc)!© 2011 Orientation in Objects GmbH
  • XXX XXX XXX 010010010101 010010010101 0100100101 component based development© 2011 Orientation in Objects GmbH
  • break it into pieces ✓ components • layers • modules • aspects?© 2011 Orientation in Objects GmbH
  • presentation layer business logic layer integration layer layers© 2011 Orientation in Objects GmbH
  • 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
  • break it into pieces ✓ components ✓ layers • modules • aspects?© 2011 Orientation in Objects GmbH
  • 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 • aspects?© 2011 Orientation in Objects GmbH
  • 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
  • break it into pieces ✓ components ✓ layers ✓ modules ✓ aspects?© 2011 Orientation in Objects GmbH
  • 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“ DAO „A“ DAO „B“ DAO „C“ DAO „D“ simple 2 client situation© 2011 Orientation in Objects GmbH
  • 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
  • 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
  • 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
  • #omfg • Release management? • Versioning? • Backwards compatibility? • Dependency resolution & mediation? • Compiletime vs. runtime? • Visibility? • Deployment, scalability, availability?© 2011 Orientation in Objects GmbH
  • EJB-JAR R W l JA AR uti Java EE© 2011 Orientation in Objects GmbH
  • EJB-JAR R W l JA AR utiServlets, EJBs, ... Java EE© 2011 Orientation in Objects GmbH
  • EJB-JAR R W l JA AR utiServlets, EJBs, ... EAR Java EE© 2011 Orientation in Objects GmbH
  • EJB-JAR R W l JA AR utiServlets, EJBs, ... EAR Java EE© 2011 Orientation in Objects GmbH
  • dependencies / scopes BL configuration runtime testtime modularization? compiletime DAO interface impl mock template hibernate api SCOPES© 2011 Orientation in Objects GmbH
  • POM artefact „2“ v1.0 artefact „1“ v1.2 artefact „3“ Maven (ivy too...)© 2011 Orientation in Objects GmbH
  • 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
  • dead end with Java EE© 2011 Orientation in Objects GmbH
  • update install refresh INSTALLED STARTING resolve update start stop refresh RESOLVED ACTIVE uninstall uninstall stop UNINSTALLED STOPPING Bundle OSGi© 2011 Orientation in Objects GmbH
  • update install refresh INSTALLED STARTING resolve update start stop refresh RESOLVED ACTIVE uninstall uninstall stop UNINSTALLED STOPPING Bundle OSGi© 2011 Orientation in Objects GmbH
  • update install refresh INSTALLED STARTING resolve update start stop refresh RESOLVED ACTIVE uninstall uninstall stop UNINSTALLED STOPPING Bundle OSGi© 2011 Orientation in Objects GmbH
  • Java EE APIs don‘t fit into OSGi e.g. .... monolothical configs classloading nightmares don‘t work by design© 2011 Orientation in Objects GmbH
  • dead end with Java© 2011 Orientation in Objects GmbH
  • tools: a matter of context© 2011 Orientation in Objects GmbH
  • develop modular software • APIs • IDEs • Test-Frameworks© 2011 Orientation in Objects GmbH
  • build modular software • integration server • automated builds • distributed builds? • provisioning? • release management?© 2011 Orientation in Objects GmbH
  • run modular software • runtime for modules • module/ app deployment • intelligent (?) clustering?© 2011 Orientation in Objects GmbH
  • each tool is great • and does (mostly) not work with the others • no standard? no standard tooling.© 2011 Orientation in Objects GmbH
  • ‣ Java 8, Jigsaw ‣ Modularization?Session ‣2013Topics
  • 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
  • Meanwhile... Java X 8, ? 7, super packages? modules? simplified module system? dynamic modules? ==> Java EE ?!?© 2011 Orientation in Objects GmbH
  • Maven/ Ivy, Spring, JBoss, OSGi, OBR/ P2, Cloud Helping ourselves© 2011 Orientation in Objects GmbH
  • There is not a moment to loose!© 2011 Orientation in Objects GmbH
  • Thanks!© 2011 Orientation in Objects GmbH