Modularisierung in Java 8

    
   c.dedek
 
   |
   Orientation In Objects GmbH


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

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




© 2011 Orientation in Objects GmbH
‣Java 8, Jigsaw
          ‣ Modularization?
          ‣ 2013
Session
Topics
Wouldn’t it be
               cool?
          • You could write a Java application that
              could run, without change, on cell
              phones, on TV set-top boxes, and
              on laptop and desktop computers?
          • A Java applet could start up just
              as quickly as a similar Flash
              application, and have comparable
              responsiveness?
          • A Java application could start up just as
              quickly as a similar application written
              in C/C++, and have a comparable
              memory footprint?
          • (...)
                                       http://mreinhold.org/blog/cool
© 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 class

http://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 that's a
                                                                                                       dev release


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


                                     http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series-linux.html
© 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
                                         Shouldn't 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   ‣ 2013
Topics
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



                                   tion
security



                    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




                                                     uti
Servlets, EJBs, ...




                                       Java EE
© 2011 Orientation in Objects GmbH
EJB-JAR



                                                       R
                                     W




                                                      l JA
                                      AR




                                                     uti
Servlets, EJBs, ...                                          EAR




                                       Java EE
© 2011 Orientation in Objects GmbH
EJB-JAR



                                                       R
                                     W




                                                      l JA
                                      AR




                                                     uti
Servlets, 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    ‣2013
Topics
http://mreinhold.org/blog/cool




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

© 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
Modularization in java 8

More Related Content

PPTX
Java modularization
PPTX
Modular Java
PDF
Desiging for Modularity with Java 9
PDF
Java modularity: life after Java 9
PDF
Modules all the way down: OSGi and the Java Platform Module System
PPTX
Java Modularity with OSGi
PPTX
Java 9 Modularity and Project Jigsaw
PDF
Open Services Gateway Initiative (OSGI)
Java modularization
Modular Java
Desiging for Modularity with Java 9
Java modularity: life after Java 9
Modules all the way down: OSGi and the Java Platform Module System
Java Modularity with OSGi
Java 9 Modularity and Project Jigsaw
Open Services Gateway Initiative (OSGI)

What's hot (20)

PDF
Benefits of OSGi in Practise
PDF
Java Modularity: the Year After
PPTX
Modularity of The Java Platform Javaday (http://javaday.org.ua/)
ZIP
Practical OSGi
PPTX
Step by step guide to create theme for liferay dxp 7
PPTX
Liferay (DXP) 7 Tech Meetup for Developers
PDF
GlassFish Community and future larochelle
PDF
GlassFish Article September 07
PDF
GlassFish OSGi - Java2days 2010
PDF
Modular JavaScript
PDF
JDK-9: Modules and Java Linker
PDF
Java SE 9 modules (JPMS) - an introduction
PDF
Migrating to Java 9 Modules
PDF
MicroProfile for MicroServices
PDF
OSGi and Java EE in GlassFish - Tech Days 2010 India
PDF
OSGi & Java EE in GlassFish
KEY
Beyond OSGi Software Architecture
PDF
OSGi-enabled Java EE applications in GlassFish
PDF
Travelling Light for the Long Haul - Ian Robinson
PPTX
Intro to OSGi
Benefits of OSGi in Practise
Java Modularity: the Year After
Modularity of The Java Platform Javaday (http://javaday.org.ua/)
Practical OSGi
Step by step guide to create theme for liferay dxp 7
Liferay (DXP) 7 Tech Meetup for Developers
GlassFish Community and future larochelle
GlassFish Article September 07
GlassFish OSGi - Java2days 2010
Modular JavaScript
JDK-9: Modules and Java Linker
Java SE 9 modules (JPMS) - an introduction
Migrating to Java 9 Modules
MicroProfile for MicroServices
OSGi and Java EE in GlassFish - Tech Days 2010 India
OSGi & Java EE in GlassFish
Beyond OSGi Software Architecture
OSGi-enabled Java EE applications in GlassFish
Travelling Light for the Long Haul - Ian Robinson
Intro to OSGi
Ad

Similar to Modularization in java 8 (20)

PDF
The State of Java under Oracle at JCertif 2011
PDF
OpenJDK Penrose Presentation (JavaOne 2012)
PDF
Java 9 / Jigsaw - LJC / VJUG session (hackday session)
PPTX
Modules in Java? Finally! (OpenJDK 9 Jigsaw, JSR376)
PDF
Java 23 and Beyond - A Roadmap Of Innovations
PDF
Java 25 and Beyond - A Roadmap of Innovations
PDF
RESTful Services and Distributed OSGi - 04/2009
PDF
GWT-Basics
PDF
GWT-Basics
PDF
Osgi in Action Creating Modular Applications in Java Unedited Draft 1st Editi...
ODP
Java 7: Quo vadis?
PDF
Instant download Osgi in Action Creating Modular Applications in Java Unedite...
PPSX
Java 9 and the impact on Maven Projects (JavaOne 2016)
PDF
Java 9 / Jigsaw - AJUG/VJUG session
PDF
What's Expected in Java 7
PDF
A Journey through the JDKs (Java 9 to Java 11)
DOC
Next-Generation Enterprise Application Development with SpringSource dm Serve...
PPTX
Custom Runtimes for the Cloud
PDF
Java Cloud and Container Ready
PPTX
Devoxx Belgium 2015
The State of Java under Oracle at JCertif 2011
OpenJDK Penrose Presentation (JavaOne 2012)
Java 9 / Jigsaw - LJC / VJUG session (hackday session)
Modules in Java? Finally! (OpenJDK 9 Jigsaw, JSR376)
Java 23 and Beyond - A Roadmap Of Innovations
Java 25 and Beyond - A Roadmap of Innovations
RESTful Services and Distributed OSGi - 04/2009
GWT-Basics
GWT-Basics
Osgi in Action Creating Modular Applications in Java Unedited Draft 1st Editi...
Java 7: Quo vadis?
Instant download Osgi in Action Creating Modular Applications in Java Unedite...
Java 9 and the impact on Maven Projects (JavaOne 2016)
Java 9 / Jigsaw - AJUG/VJUG session
What's Expected in Java 7
A Journey through the JDKs (Java 9 to Java 11)
Next-Generation Enterprise Application Development with SpringSource dm Serve...
Custom Runtimes for the Cloud
Java Cloud and Container Ready
Devoxx Belgium 2015
Ad

More from pgt technology scouting GmbH (8)

PDF
Javaland 2014 / GWT architectures and lessons learned
PDF
GWT widget development
PDF
Client-Server-Kommunikation mit dem Command Pattern
PDF
GWT Architectures and Lessons Learned (WJAX 2013)
PDF
GWT architecture best practices and lessons learned
KEY
GWT - building a better web
KEY
Gwt, die bessere spinne
ZIP
Google Web Toolkit
Javaland 2014 / GWT architectures and lessons learned
GWT widget development
Client-Server-Kommunikation mit dem Command Pattern
GWT Architectures and Lessons Learned (WJAX 2013)
GWT architecture best practices and lessons learned
GWT - building a better web
Gwt, die bessere spinne
Google Web Toolkit

Recently uploaded (20)

PDF
NewMind AI Journal Monthly Chronicles - August 2025
PDF
Early detection and classification of bone marrow changes in lumbar vertebrae...
PDF
Advancing precision in air quality forecasting through machine learning integ...
PDF
Lung cancer patients survival prediction using outlier detection and optimize...
PPTX
Information-Technology-in-Human-Society.pptx
PDF
Data Virtualization in Action: Scaling APIs and Apps with FME
PDF
A symptom-driven medical diagnosis support model based on machine learning te...
PDF
CEH Module 2 Footprinting CEH V13, concepts
PPTX
Build automations faster and more reliably with UiPath ScreenPlay
PDF
AI.gov: A Trojan Horse in the Age of Artificial Intelligence
PDF
5-Ways-AI-is-Revolutionizing-Telecom-Quality-Engineering.pdf
PPTX
Rise of the Digital Control Grid Zeee Media and Hope and Tivon FTWProject.com
PPTX
AI-driven Assurance Across Your End-to-end Network With ThousandEyes
PPTX
How to Convert Tickets Into Sales Opportunity in Odoo 18
PDF
Altius execution marketplace concept.pdf
PDF
substrate PowerPoint Presentation basic one
PPTX
Report in SIP_Distance_Learning_Technology_Impact.pptx
PDF
Connector Corner: Transform Unstructured Documents with Agentic Automation
PDF
Rapid Prototyping: A lecture on prototyping techniques for interface design
PDF
Introduction to MCP and A2A Protocols: Enabling Agent Communication
NewMind AI Journal Monthly Chronicles - August 2025
Early detection and classification of bone marrow changes in lumbar vertebrae...
Advancing precision in air quality forecasting through machine learning integ...
Lung cancer patients survival prediction using outlier detection and optimize...
Information-Technology-in-Human-Society.pptx
Data Virtualization in Action: Scaling APIs and Apps with FME
A symptom-driven medical diagnosis support model based on machine learning te...
CEH Module 2 Footprinting CEH V13, concepts
Build automations faster and more reliably with UiPath ScreenPlay
AI.gov: A Trojan Horse in the Age of Artificial Intelligence
5-Ways-AI-is-Revolutionizing-Telecom-Quality-Engineering.pdf
Rise of the Digital Control Grid Zeee Media and Hope and Tivon FTWProject.com
AI-driven Assurance Across Your End-to-end Network With ThousandEyes
How to Convert Tickets Into Sales Opportunity in Odoo 18
Altius execution marketplace concept.pdf
substrate PowerPoint Presentation basic one
Report in SIP_Distance_Learning_Technology_Impact.pptx
Connector Corner: Transform Unstructured Documents with Agentic Automation
Rapid Prototyping: A lecture on prototyping techniques for interface design
Introduction to MCP and A2A Protocols: Enabling Agent Communication

Modularization in java 8

  • 1. Modularisierung in Java 8 c.dedek | Orientation In Objects GmbH p.g.taboada | pgt technology scouting GmbH
  • 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. ‣Java 8, Jigsaw ‣ Modularization? ‣ 2013 Session Topics
  • 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. 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. 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. 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. 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. Status: Inactive © 2011 Orientation in Objects GmbH
  • 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. 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. First, build your own JDK8 © 2011 Orientation in Objects GmbH
  • 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. Mercurial Addon besorgen: ------------------------- hg clone https://[email protected]/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. 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. 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. Do the hello world thing © 2011 Orientation in Objects GmbH
  • 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. # de.oio.test kompilieren javac -d modules -modulepath modules -sourcepath modules `find modules -name '*.java'` © 2011 Orientation in Objects GmbH
  • 20. © 2011 Orientation in Objects GmbH
  • 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. © 2011 Orientation in Objects GmbH
  • 23. # mlib erstellen und Module installieren jmod create -L mlib jmod install [email protected] [email protected] -L mlib © 2011 Orientation in Objects GmbH
  • 24. © 2011 Orientation in Objects GmbH
  • 25. # Ausführen java -L mlib -m [email protected] © 2011 Orientation in Objects GmbH
  • 26. © 2011 Orientation in Objects GmbH
  • 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. Java Module-System Requirements DRAFT 12 ? JSR TBD ! OSGi Jigsaw Ref Impl © 2011 Orientation in Objects GmbH
  • 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 class http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12 © 2011 Orientation in Objects GmbH
  • 30. META-INF Java Syntax Erweiterung Form of definition © 2011 Orientation in Objects GmbH
  • 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. 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. 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. 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. 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. A B API .... Export-Package: API Import-Package: API Deklarationslevel © 2011 Orientation in Objects GmbH
  • 37. A B API .... module B @ 1.0 { requires A; } Deklarationslevel © 2011 Orientation in Objects GmbH
  • 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. 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. A B API 1 .... API 2 Refactoring - OSGi © 2011 Orientation in Objects GmbH
  • 41. A API 1 B .... A‘ API 2 Refactoring - OSGi © 2011 Orientation in Objects GmbH
  • 42. A B API 1 .... API 2 Refactoring - Jigsaw © 2011 Orientation in Objects GmbH
  • 43. A API 1 B .... A‘ API 2 ? Refactoring - Jigsaw © 2011 Orientation in Objects GmbH
  • 44. A API 1 B .... A‘ API 2 Refactoring - Jigsaw © 2011 Orientation in Objects GmbH
  • 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. 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. support common version-string schemes?!? © 2011 Orientation in Objects GmbH
  • 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. 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. But not 2.3, because that's a dev release module Lenny @ 2.4 { requires SMTP @ [2.2,2.5), requires MacOSX @ 2.10.*.2+, permits Desmond @ 2.2, } Who uses Mac OS X before .2 comes out? http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series-linux.html © 2011 Orientation in Objects GmbH
  • 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. 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. 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. 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. This most likely means??? © 2011 Orientation in Objects GmbH
  • 56. OSGi: Because Sharing Shouldn't Be Painful http://www.theserverside.com/feature/OSGi-Because-Sharing-Shouldnt-Be-Painful © 2011 Orientation in Objects GmbH
  • 57. Migration and interoperation • Maven support • OSGi support • Manipulable module metadata © 2011 Orientation in Objects GmbH
  • 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. 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. 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. 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. A B API .... module B @ 1.0 { requires A; } Deklarationslevel © 2011 Orientation in Objects GmbH
  • 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. 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. CDC-sized subsets? © 2011 Orientation in Objects GmbH
  • 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. 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. 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. 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. ‣ Java 8, Jigsaw ‣ Modularization? Session ‣ 2013 Topics
  • 71. where does modularization happen? © 2011 Orientation in Objects GmbH
  • 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. so, is it a matter of architecture? © 2011 Orientation in Objects GmbH
  • 75. Divide & Conquer © 2011 Orientation in Objects GmbH
  • 76. break it into pieces • components • layers • modules • aspects? © 2011 Orientation in Objects GmbH
  • 77. 0100100101001100 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 bad guy © 2011 Orientation in Objects GmbH
  • 78. 0100100101001100 I am amonolithical thing! 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 bad guy © 2011 Orientation in Objects GmbH
  • 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. 0100100101001100 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 see the duplicate code? © 2011 Orientation in Objects GmbH
  • 81. 0100100101001100 110010010010010 010010010101 01010010101 010010010101 100100101010 10101010 010010010101 101 101111001011 0101010101 re-use it! © 2011 Orientation in Objects GmbH
  • 82. 0100100101001100 110010010010010 XXX 01010010101 XXX 100100101010 10101010 XXX XXX 101 101111001011 010010010101 0101010101 lifecycle? state? runtime? © 2011 Orientation in Objects GmbH
  • 83. XXX provides interfaces 010010010101 provides services managed bean (ioc)! © 2011 Orientation in Objects GmbH
  • 84. XXX XXX XXX 010010010101 010010010101 0100100101 component based development © 2011 Orientation in Objects GmbH
  • 85. break it into pieces ✓ components • layers • modules • aspects? © 2011 Orientation in Objects GmbH
  • 86. presentation layer business logic layer integration layer layers © 2011 Orientation in Objects GmbH
  • 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. break it into pieces ✓ components ✓ layers • modules • aspects? © 2011 Orientation in Objects GmbH
  • 89. modules? © 2011 Orientation in Objects GmbH
  • 90. allowed intimacy level? © 2011 Orientation in Objects GmbH
  • 91. modules? © 2011 Orientation in Objects GmbH
  • 92. modules? © 2011 Orientation in Objects GmbH
  • 93. break it into pieces ✓ components ✓ layers ✓ modules • aspects? © 2011 Orientation in Objects GmbH
  • 94. ring tion security 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. break it into pieces ✓ components ✓ layers ✓ modules ✓ aspects? © 2011 Orientation in Objects GmbH
  • 96. break it into pieces ✓ VMs? © 2011 Orientation in Objects GmbH
  • 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. 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. 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. 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. #omfg • Release management? • Versioning? • Backwards compatibility? • Dependency resolution & mediation? • Compiletime vs. runtime? • Visibility? • Deployment, scalability, availability? © 2011 Orientation in Objects GmbH
  • 103. EJB-JAR R W l JA AR uti Java EE © 2011 Orientation in Objects GmbH
  • 104. EJB-JAR R W l JA AR uti Servlets, EJBs, ... Java EE © 2011 Orientation in Objects GmbH
  • 105. EJB-JAR R W l JA AR uti Servlets, EJBs, ... EAR Java EE © 2011 Orientation in Objects GmbH
  • 106. EJB-JAR R W l JA AR uti Servlets, EJBs, ... EAR Java EE © 2011 Orientation in Objects GmbH
  • 107. dependencies / scopes BL configuration runtime testtime modularization? compiletime DAO interface impl mock template hibernate api SCOPES © 2011 Orientation in Objects GmbH
  • 108. POM artefact „2“ v1.0 artefact „1“ v1.2 artefact „3“ Maven (ivy too...) © 2011 Orientation in Objects GmbH
  • 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. dead end with Java EE © 2011 Orientation in Objects GmbH
  • 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. 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. 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. 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. dead end with Java © 2011 Orientation in Objects GmbH
  • 116. tools: a matter of context © 2011 Orientation in Objects GmbH
  • 117. develop modular software • APIs • IDEs • Test-Frameworks © 2011 Orientation in Objects GmbH
  • 118. build modular software • integration server • automated builds • distributed builds? • provisioning? • release management? © 2011 Orientation in Objects GmbH
  • 119. run modular software • runtime for modules • module/ app deployment • intelligent (?) clustering? © 2011 Orientation in Objects GmbH
  • 120. each tool is great • and does (mostly) not work with the others • no standard? no standard tooling. © 2011 Orientation in Objects GmbH
  • 121. ‣ Java 8, Jigsaw ‣ Modularization? Session ‣2013 Topics
  • 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. Meanwhile... Java X 8, ? 7, super packages? modules? simplified module system? dynamic modules? ==> Java EE ?!? © 2011 Orientation in Objects GmbH
  • 124. Maven/ Ivy, Spring, JBoss, OSGi, OBR/ P2, Cloud Helping ourselves © 2011 Orientation in Objects GmbH
  • 125. There is not a moment to loose! © 2011 Orientation in Objects GmbH
  • 126. Thanks! © 2011 Orientation in Objects GmbH

Editor's Notes

  • #2: \n
  • #3: \n
  • #4: \n
  • #5: \n
  • #6: \n
  • #7: \n
  • #8: \n
  • #9: \n
  • #10: \n
  • #11: PGT\n
  • #12: \n
  • #13: \n
  • #14: 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://[email protected]/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 [email protected] [email protected] -L mlib\n\nAusführen:\n----------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/java -L mlib -m de.oio.test\n
  • #15: 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://[email protected]/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 [email protected] [email protected] -L mlib\n\nAusführen:\n----------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/java -L mlib -m de.oio.test\n
  • #16: 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://[email protected]/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 [email protected] [email protected] -L mlib\n\nAusführen:\n----------\n/foo/jdkbuild/jigsaw/build/linux-i586/bin/java -L mlib -m de.oio.test\n
  • #17: \n
  • #18: \n
  • #19: \n
  • #20: \n
  • #21: \n
  • #22: \n
  • #23: \n
  • #24: \n
  • #25: \n
  • #26: \n
  • #27: \n
  • #28: CD\n
  • #29: \n
  • #30: \n
  • #31: \n
  • #32: \n
  • #33: 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
  • #34: \n
  • #35: \n
  • #36: 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
  • #37: \n
  • #38: == Require Bundle aus OSGi\n
  • #39: \n
  • #40: \n
  • #41: \n
  • #42: \n
  • #43: \n
  • #44: \n
  • #45: \n
  • #46: 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
  • #47: 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
  • #48: \n
  • #49: http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series-roman.html\n
  • #50: http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series-roman.html\n
  • #51: http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series-roman.html\n
  • #52: http://alblue.bandlem.com/2009/12/jsr294-fantasy-version-series-roman.html\n
  • #53: 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
  • #54: 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
  • #55: 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
  • #56: \n
  • #57: \n
  • #58: \n
  • #59: Scott Stark http://community.jboss.org/wiki/ModulesInJava8\n\nmaven support is more of a usecase for pluggable loading\n\n
  • #60: Scott Stark http://community.jboss.org/wiki/ModulesInJava8\n\n\nOSGi support also seems like a usecase for pluggable module resolution.\n\n
  • #61: Scott Stark http://community.jboss.org/wiki/ModulesInJava8\n\nmanipuable module metadata; doesn't this imply not using java language syntax for metadata?\n
  • #62: 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
  • #63: == Require Bundle aus OSGi\n
  • #64: \n
  • #65: 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
  • #66: \n
  • #67: 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
  • #68: 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
  • #69: Enforcement, Hiding, Cost of Dependencies, Package Sharing, Versioningm Unexpected Consequences of API based Programming, ...\n
  • #70: \n
  • #71: @ 30m - 40m\n
  • #72: \n
  • #73: \n
  • #74: \n
  • #75: \n
  • #76: \n
  • #77: \n
  • #78: \n
  • #79: \n
  • #80: \n
  • #81: \n
  • #82: \n
  • #83: \n
  • #84: \n
  • #85: \n
  • #86: \n
  • #87: \n
  • #88: \n
  • #89: \n
  • #90: \n
  • #91: \n
  • #92: \n
  • #93: \n
  • #94: \n
  • #95: \n
  • #96: \n
  • #97: \n
  • #98: \n
  • #99: \n
  • #100: \n
  • #101: \n
  • #102: \n
  • #103: package modules\n do class sharing\n do instance sharing\n no versions\n no visibility constraints\n no module lifecycle\n
  • #104: package modules\n do class sharing\n do instance sharing\n no versions\n no visibility constraints\n no module lifecycle\n
  • #105: package modules\n do class sharing\n do instance sharing\n no versions\n no visibility constraints\n no module lifecycle\n
  • #106: 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
  • #107: 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
  • #108: \n
  • #109: \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
  • #110: Bei OSGi ist es andersrum. Oder war es zum Teil. Mit 4.2 bekommen wir doch Spring dm als fine grained RI, oder?\n
  • #111: Bei OSGi ist es andersrum. Oder war es zum Teil. Mit 4.2 bekommen wir doch Spring dm als fine grained RI, oder?\n
  • #112: \n
  • #113: \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
  • #114: \n
  • #115: \n
  • #116: \n
  • #117: \n
  • #118: \n
  • #119: @55\n
  • #120: \n
  • #121: \n
  • #122: \n
  • #123: \n
  • #124: \n
  • #125: \n