Java 7 Modularity:
a View from the Gallery
             – Neil Bartlett –

    A Skills Matter “In The Brain” Talk
A Small Correction

 There will probably never be a “Java 7”.
 Sun always says JDK7 or OpenJDK: a
 product, not a specifica...
Java Timeline
                                Java 1.4
       JSR 59                               GA


                  ...
JDK7 Features

 Project Coin
 JSR 292 (dynamic language support)
 G1 garbage collector
 Modularisation
About You

 A Java developer, of course.
 Building libraries or apps or both.
 Probably not building your own JVM or
 Java...
Therefore...

 Modularisation must be a good thing...
 .. so long as you’re not forced to change
 anything!
 You don’t car...
Therefore...


 This talk is not about OSGi vs Jigsaw for
 modularising the JVM.
 It is about how the existence of multipl...
JDK Modularisation
Why?
Why?
JDK 1.1 = 3.5Mb
JDK 6u16 = 65.2Mb
>1800% growth ;-)
Slow start-up
Difficult to deploy with apps
Difficult to evolve APIs
API Evolution

 Never let an old API just die?
 Deprecation is meaningless.
 Version dependencies have no upper
 bound.
 E...
Dependency Versions

 Depending on whole JDK version is no
 longer feasible.
 Would like to depend on, e.g., Swing v2
 and...
Dependency Versions


 .NET has always done this
 Allowed them to introduce generics
 without the Erasure mess!
Project Jigsaw
Semi-Disclaimer

 I am an “OSGi person” (training courses,
 book, etc).
 But I’m paid by Sun (JavaFX in Eclipse).
 My prin...
Overview


 Announced in a blog post by Mark
 Reinhold, Dec 2008.
 “focused narrowly upon the goal of
 modularizing the JD...
Example

module M1@1.0 provides M2@2.0 {
   requires M3 @ 3.0;
   requires private M4 @ 4.0;
   permits M6;
}
Provides

 A way for a module to “alias” itself as
 another module.
 E.g. module A requires B.
 B is not present but C “pr...
Permits

 If module A “permits” B then only B may
 depend on A.
 If no explicit permits listed, then all are
 permitted.
 ...
Requires


 Creates a dependency on another
 module.
 All types in other module will be visible.
Re-export
      A            B           C


 A requires B requires C
 B’s dependency on C is re-exported by
 default
 A c...
Requires Modifiers

 Private: no re-export
 Optional: no error if dependency not
 present (but ClassNotFoundException or
 ...
Versions

   String starting with a digit or [ or (
   “The Java language assigns no
   meaning to the version of a module...
Version Ranges


 Dependencies can address a range of
 providers.
 The range syntax is not specified/
 documented yet.
JSR 277 Versions


 Five segments: four numeric, one text
 major.minor.micro.update-qualifier
JSR 277 Ranges


 Closed:
    1 = exactly 1.0.0.0 only
JSR 277 Ranges


 Open Range:
    1+ = anything 1.0.0.0 or above
    1.1+ = anything 1.1.0.0 or above
JSR 277 Ranges

 Family Range:
    1* = anything 1.0.0.0 or above but
    below 2.0.0.0
    1.1* = anything 1.1.0.0 or abo...
JSR 277 Ranges

 Open Range Within Family:
    1.[1.1.1+] = anything 1.1.1.1 or above
    but below 2.0.0.0
    1.1.[1.1+]...
OSGi
Bundle = Module
Example

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Version: 1.0
Export-Package: org.foo;version=“1.0.0”
Impor...
Exports


 The fundamental unit of sharing is the
 package.
 Only explicitly exported packages are
 available to importers.
Imports

 List all the packages used by your bundle.
 OSGi will “wire” them to the best provider.
 Do not care which provi...
Substitution

 OSGi emphasises the ability to substitute
 implementations.
 Framework attempts to minimise the
 number of ...
Requires

 We can use whole-module dependencies
 as an alternative.
 Require-Bundle: org.foo
 Strongly discouraged! Breaks...
Re-export

 With Require-Bundle we can re-export
 dependencies
 Tends to create a mess
 With Import-Package, re-exporting ...
Versions

 Four segments: three numeric, one text
 major.minor.micro.qualifier
    e.g. 3.5.1.beta_20091030
 Defined semanti...
Version Ranges

 1.0.0 = anything 1.0.0 or above
 [1.0.0,2.0.0) = anything 1.0.0 or above but
 below 2.0.0
 [ and ] mean i...
Why Jigsaw?
My Initial Reaction



 Admittedly not positive...
Just
   kill
it now
What’s Hard in OSGi?

 Focus on packages as unit of sharing
 makes split packages awkward.
 Legacy class loading/visibilit...
The JDK


 One, massive, tangled, legacy mess.
 API used by everybody.
 Can’t just refactor!
Tangled?

 Example:
    java.lang depends on java.net,
    java.util, java.io.
    Everything depends on java.lang.
 Circu...
Assumptions


 Some internal classes (e.g. under
 com.sun.*) assume that certain other
 classes are always visible on ever...
Why Jigsaw?

 Jigsaw appears designed for this specific
 legacy modularisation task.
 No proscription against split package...
Why Jigsaw


 I now accept Jigsaw may be the most
 convenient way to modularise the JDK in
 the short term.
Why Jigsaw is Worrying
Why Care?


 As I said, you probably don’t care how
 modularity works inside the JVM.
 But you do care how it affects your...
Why Care?


 “...available for developers to use in their
 own code, and will be fully supported by
 Sun...” - Mark Reinho...
Therefore...

 Some applications will use it.
 Forget about technical merits... it’s in the
 JRE!
 I’m not here today to c...
Therefore...



 Library authors must cope with demands
 for their library to work in Jigsaw.
Competition?

 Why resist Jigsaw?
 Not just fear of competition.
 Nor legacy & inertia.
 If Jigsaw was better than OSGi, I...
Fragmentation
OSGi is Standard!
 Both de facto and de jure.
 Firmly established.
 Maybe not so much in apps (yet)...
 ... but look insid...
As a Result...

 For library authors, compatibility with
 OSGi is already very important.
 Many Apache libraries packaged ...
What about jpkg?

 jpkg is a cool tool for installing Java
 modules using your O/S’s native
 packaging system.
 i.e. RPM (...
What about jpkg?

 Nothing about jpkg fundamentally
 requires Jigsaw.
 Dalibor Topic (jpkg author) is in favour of
 jpkg s...
JSR 294’s Promise
Overview

 “Superpackages” described in a blog
 post by Gilad Bracha, April 2006.
 Focus on Java language support for
 mod...
Overview (cont)
 JSR 277 now dead, partially replaced by
 Project Jigsaw.
 Superpackages idea dropped.
 New focus on modul...
Accessibility & the
 Missing Modifier
Accessibility Today
 Top level types:

   Modifier         Accessibility
    public            Anywhere
   (default)      ...
Accessibility Today
 Members (fields, methods):

  Modifier            Accessibility
   public                Anywhere
  pr...
Accessibility Today

 Difficult to create “library internal” utility
 classes.
 Most libraries contain >1 package.
 Utiliti...
OSGi’s Answer


 Restricted list of packages exported from
 a module.
 Only explicitly exported packages may be
 seen by o...
OSGi’s Answer

 Not highly granular, only works on whole
 packages.
 May need to move utilities to an “internal”
 package....
OSGi’s Answer

 Based on visibility not accessibility.
 To compile accurately, we need to fiddle
 the classpath.
 Would sti...
Compiler/Runtime
    Fidelity
Ever Seen These...?

AbstractMethodError     InstantiationError


ClassCircularityError   NoSuchFieldError


ClassFormatEr...
Mostly Caused By:


 Compiler bugs – you have my sympathy!
 Partial compilation after refactoring – zero
 sympathy.
Except...

AbstractMethodError     InstantiationError


ClassCircularityError   NoSuchFieldError


ClassFormatError       ...
“Package-Private”
package org.foo;                     package org.foo;


public class Bar {                   public clas...
“Package-Private”
package org.foo;                     package org.foo;


public class Bar {                   public clas...
“Package-Private”
 ...is really runtime-package-private (JVM spec,
 §5.4.4)
 “determined by the package name and defining
 ...
OSGi’s Answer

 Packages are the fundamental unit of
 sharing.
 “Split packages” are strongly
 discouraged.
 Therefore typ...
JSR 294: The Reality
New Access Modifier
 Top level types:

   Modifier         Accessibility
    public            Anywhere
    module        ...
New Access Modifier
 Members (fields, methods):

  Modifier            Accessibility
   public                Anywhere
   m...
Sample
package org.foo;

module class Wibble {
   module static void doStuff() {
      System.out.println("Hello");
   }
}...
Module Declaration


 Specifies a new named module.
 module-info.java
Examples: Jigsaw

module M1 @   1.0 {
   requires   M2 @ 2.0, M3 @ 3.0;
   provides   M4 @ 4.0, M5 @ 5.0;
   permits    M6...
Examples: OSGi-like

module M @ 1.2.0.beta for OSGi @ 4.2 {
   requires N;
   requires package P @ [1.0,2.0);
   requires ...
With Annotations...
import com.mycorp.annotations.*;
@Foo
module M @ 5.0u7:SPARC for osgi @ 4.2 {
   @Bar(“wibble”)
   req...
Anatomy
 New restricted keyword

module M1 @   1.0 {
   requires   M2 @ 2.0, M3 @ 3.0;
   provides   M4 @ 4.0, M5 @ 5.0;
 ...
Anatomy (cont)
 Name = word + (optional) version

module M1 @   1.0 {
   requires   M2 @ 2.0, M3 @ 3.0;
   provides   M4 @...
Anatomy (cont)
 Directives

module M1 @   1.0 {
   requires   M2 @ 2.0, M3 @ 3.0;
   provides   M4 @ 4.0, M5 @ 5.0;
   per...
Versions

 Version string is opaque – meaning is
 undefined (determined by the module
 system).
 Also optional – default is...
Directives

 Content is arbitrary (though some syntax
 rules apply).
 Similar to annotations, but not imported.
 Semantics...
Module Membership


 Which classes are members of this
 module?
 Undefined (determined by the module
 system).
Here Be Dragons!
Compiler Implications

 Not a lot is actually defined!
 The compiler must understand these
 directives somehow.
 Compiler c...
Compiler Implications

 We need either:
    A Jigsaw version of javac and an
    OSGi version of javac (plus N other
    j...
For Developers

 The directives for each module system are
 completely different.
 A module that compiles for Jigsaw won’t...
Supporting Many

 Can libraries support multiple module
 systems?
 Perhaps... but at a high price
 Compile & test everythi...
Supporting Many


 Two version schemes for one library?
 Choosing a version number for our library
 will bind us to a spec...
A Rant about Standards
Resolving Conflict



 How do standards bodies resolve
 conflicting requirements?
Hit the Beach

 “I know! Let’s just keep both ways as
 options. Then implementers and users
 can choose for themselves, an...
Also Known As...

 Agreeing to disagree.
 Does not help users, it hurts them.
 Too often we are forced to deal with both
 ...
Simple Module System
Overview

 A proposal to JSR 294 expert group by:
    Peter Kriens (OSGi Alliance)
    BJ Hargrave (IBM & OSGi Alliance)
 ...
What Is It?

 A concrete module system.
 Remove the undefined “black holes” of
 JSR 294.
 Provide as much of a module syste...
Focus on Users

 Libraries should be offered as modules.
 Do not make library authors build and
 ship multiple module type...
Heal Fragmentation

 Not another new module system!
 Does not address all use-cases.
 An easy on-ramp to modularity.
 If y...
Concrete


 All keywords must mean something.
 No arbitrary module-specific keywords.
Extensible

 Allow access to extended features by
 specific module systems.
 Extensions must be extra-lingual.
 E.g. MANIFE...
Simple!


 Simple visibility model
 Single version number scheme
 Module membership
Visibility: OSGi


 Exports are limited
 Import packages, or whole modules
 Optional re-export of modules
Visibility: Jigsaw

 Modules export everything
 Whole-module imports
 Re-export is the default
 Module aliases (“provides”...
Visibility: SMS


 Modules export everything
 Whole-module imports
 That’s it!
Visibility: SMS

 No change for Jigsaw – a subset of its
 behaviour.
 For OSGi, very close to Require-Bundle
 with all pac...
Versions: SMS
 OSGi’s versioning scheme is admittedly
 quite strict (but qualifiers can smooth over
 many differences).
 Su...
Module Membership
 Jigsaw:
     Individual Java files can declare
     module membership
module com.mycorp;
package com.myc...
Module Membership


 OSGi:
    Not a compile-time concept.
    Any class in the physical bundle (JAR
    file) is a member.
Module Membership

 SMS:
   Membership corresponds to the
   module artifact, e.g. JAR file.
   One class loader per module.
Summary
A modular JDK will
be a Good Thing TM.
Summary


But the JDK is “special”
The same technology does not
necessarily work well for applications.
Summary

For library authors, OSGi metadata can be
added and tested now.
If future compatibility with Jigsaw is a
concern,...
Get Involved


 Support SMS
 Subscribe to the JSR 294 mailing lists
 Support OSGi!
Thank You
Upcoming SlideShare
Loading in …5
×

Java 7 Modularity: a View from the Gallery

4,900 views

Published on

Published in: Technology, News & Politics
1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total views
4,900
On SlideShare
0
From Embeds
0
Number of Embeds
59
Actions
Shares
0
Downloads
122
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

Java 7 Modularity: a View from the Gallery

  1. 1. Java 7 Modularity: a View from the Gallery – Neil Bartlett – A Skills Matter “In The Brain” Talk
  2. 2. A Small Correction There will probably never be a “Java 7”. Sun always says JDK7 or OpenJDK: a product, not a specification. Nevertheless, probably a de facto standard.
  3. 3. Java Timeline Java 1.4 JSR 59 GA Java 5 JSR 176 GA [1] Java 6 JSR 270 GA [2] Java 7? 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 1. That’s TODAY folks! 2. http://java.sun.com/products/archive/eol.policy.html
  4. 4. JDK7 Features Project Coin JSR 292 (dynamic language support) G1 garbage collector Modularisation
  5. 5. About You A Java developer, of course. Building libraries or apps or both. Probably not building your own JVM or Java compiler (shout if I’m wrong!)
  6. 6. Therefore... Modularisation must be a good thing... .. so long as you’re not forced to change anything! You don’t care how it works inside the JVM and compiler.
  7. 7. Therefore... This talk is not about OSGi vs Jigsaw for modularising the JVM. It is about how the existence of multiple modules systems will affect you.
  8. 8. JDK Modularisation
  9. 9. Why?
  10. 10. Why? JDK 1.1 = 3.5Mb JDK 6u16 = 65.2Mb >1800% growth ;-) Slow start-up Difficult to deploy with apps Difficult to evolve APIs
  11. 11. API Evolution Never let an old API just die? Deprecation is meaningless. Version dependencies have no upper bound. E.g. “this software requires Java 1.4 or higher”.
  12. 12. Dependency Versions Depending on whole JDK version is no longer feasible. Would like to depend on, e.g., Swing v2 and Concurrency v1.x. Or on Swing 1.x but NO higher. Now v2 can change incompatibly.
  13. 13. Dependency Versions .NET has always done this Allowed them to introduce generics without the Erasure mess!
  14. 14. Project Jigsaw
  15. 15. Semi-Disclaimer I am an “OSGi person” (training courses, book, etc). But I’m paid by Sun (JavaFX in Eclipse). My principal allegiance is to the Java platform and community.
  16. 16. Overview Announced in a blog post by Mark Reinhold, Dec 2008. “focused narrowly upon the goal of modularizing the JDK”
  17. 17. Example module M1@1.0 provides M2@2.0 { requires M3 @ 3.0; requires private M4 @ 4.0; permits M6; }
  18. 18. Provides A way for a module to “alias” itself as another module. E.g. module A requires B. B is not present but C “provides” B.
  19. 19. Permits If module A “permits” B then only B may depend on A. If no explicit permits listed, then all are permitted. A bit like “friends” in C++.
  20. 20. Requires Creates a dependency on another module. All types in other module will be visible.
  21. 21. Re-export A B C A requires B requires C B’s dependency on C is re-exported by default A can see all types in B and C.
  22. 22. Requires Modifiers Private: no re-export Optional: no error if dependency not present (but ClassNotFoundException or NoClassDefFoundError can result). Local: module must be loaded by same class loader.
  23. 23. Versions String starting with a digit or [ or ( “The Java language assigns no meaning to the version of a module” “Vaguely Debian-like version strings, for now” – Jigsaw JavaDocs
  24. 24. Version Ranges Dependencies can address a range of providers. The range syntax is not specified/ documented yet.
  25. 25. JSR 277 Versions Five segments: four numeric, one text major.minor.micro.update-qualifier
  26. 26. JSR 277 Ranges Closed: 1 = exactly 1.0.0.0 only
  27. 27. JSR 277 Ranges Open Range: 1+ = anything 1.0.0.0 or above 1.1+ = anything 1.1.0.0 or above
  28. 28. JSR 277 Ranges Family Range: 1* = anything 1.0.0.0 or above but below 2.0.0.0 1.1* = anything 1.1.0.0 or above but below 1.2.0.0
  29. 29. JSR 277 Ranges Open Range Within Family: 1.[1.1.1+] = anything 1.1.1.1 or above but below 2.0.0.0 1.1.[1.1+] = anything 1.1.1.1 or above but below 1.2.0.0
  30. 30. OSGi
  31. 31. Bundle = Module
  32. 32. Example Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Version: 1.0 Export-Package: org.foo;version=“1.0.0” Import-Package: org.bar;version=“[1,2)” Bundle-SymbolicName: mybundle
  33. 33. Exports The fundamental unit of sharing is the package. Only explicitly exported packages are available to importers.
  34. 34. Imports List all the packages used by your bundle. OSGi will “wire” them to the best provider. Do not care which provider exports each package.
  35. 35. Substitution OSGi emphasises the ability to substitute implementations. Framework attempts to minimise the number of time a class is loaded. Always get from others before getting from yourself!
  36. 36. Requires We can use whole-module dependencies as an alternative. Require-Bundle: org.foo Strongly discouraged! Breaks substitution, creates high degree of fan- out.
  37. 37. Re-export With Require-Bundle we can re-export dependencies Tends to create a mess With Import-Package, re-exporting is simply not needed.
  38. 38. Versions Four segments: three numeric, one text major.minor.micro.qualifier e.g. 3.5.1.beta_20091030 Defined semantics, e.g. new major version = breaking change, etc.
  39. 39. Version Ranges 1.0.0 = anything 1.0.0 or above [1.0.0,2.0.0) = anything 1.0.0 or above but below 2.0.0 [ and ] mean inclusive ( and ) mean exclusive
  40. 40. Why Jigsaw?
  41. 41. My Initial Reaction Admittedly not positive...
  42. 42. Just kill it now
  43. 43. What’s Hard in OSGi? Focus on packages as unit of sharing makes split packages awkward. Legacy class loading/visibility assumptions Broken Class.forName()
  44. 44. The JDK One, massive, tangled, legacy mess. API used by everybody. Can’t just refactor!
  45. 45. Tangled? Example: java.lang depends on java.net, java.util, java.io. Everything depends on java.lang. Circular dependencies make true separation impossible.
  46. 46. Assumptions Some internal classes (e.g. under com.sun.*) assume that certain other classes are always visible on every class loader.
  47. 47. Why Jigsaw? Jigsaw appears designed for this specific legacy modularisation task. No proscription against split packages. “requires local” to hack around class loader assumptions.
  48. 48. Why Jigsaw I now accept Jigsaw may be the most convenient way to modularise the JDK in the short term.
  49. 49. Why Jigsaw is Worrying
  50. 50. Why Care? As I said, you probably don’t care how modularity works inside the JVM. But you do care how it affects your libraries and applications.
  51. 51. Why Care? “...available for developers to use in their own code, and will be fully supported by Sun...” - Mark Reinhold Sun wants you to use it in your apps!
  52. 52. Therefore... Some applications will use it. Forget about technical merits... it’s in the JRE! I’m not here today to convince you that OSGi is better.
  53. 53. Therefore... Library authors must cope with demands for their library to work in Jigsaw.
  54. 54. Competition? Why resist Jigsaw? Not just fear of competition. Nor legacy & inertia. If Jigsaw was better than OSGi, I would gladly switch!
  55. 55. Fragmentation
  56. 56. OSGi is Standard! Both de facto and de jure. Firmly established. Maybe not so much in apps (yet)... ... but look inside your app server, ESB, build platform, IDE, CRM... OSGi is the King of Infrastructure.
  57. 57. As a Result... For library authors, compatibility with OSGi is already very important. Many Apache libraries packaged as bundles (and of course, all Eclipse libs). Many of Sun’s libraries also!
  58. 58. What about jpkg? jpkg is a cool tool for installing Java modules using your O/S’s native packaging system. i.e. RPM (Red Hat), apt-get (Ubuntu). Makes for nice JavaOne demos.
  59. 59. What about jpkg? Nothing about jpkg fundamentally requires Jigsaw. Dalibor Topic (jpkg author) is in favour of jpkg supporting OSGi. Unfortunately, no story for Windows or Mac OS yet.
  60. 60. JSR 294’s Promise
  61. 61. Overview “Superpackages” described in a blog post by Gilad Bracha, April 2006. Focus on Java language support for modules, rather than runtime aspects. Complemented by JSR 277, the proposed runtime module system.
  62. 62. Overview (cont) JSR 277 now dead, partially replaced by Project Jigsaw. Superpackages idea dropped. New focus on module declaration and access modifier. In theory can benefit any runtime module system.
  63. 63. Accessibility & the Missing Modifier
  64. 64. Accessibility Today Top level types: Modifier Accessibility public Anywhere (default) Same Package
  65. 65. Accessibility Today Members (fields, methods): Modifier Accessibility public Anywhere protected Same Package, subtypes private Same Compilation Unit (default) Same Package
  66. 66. Accessibility Today Difficult to create “library internal” utility classes. Most libraries contain >1 package. Utilities must be public. Therefore also usable by clients of the library.
  67. 67. OSGi’s Answer Restricted list of packages exported from a module. Only explicitly exported packages may be seen by other modules.
  68. 68. OSGi’s Answer Not highly granular, only works on whole packages. May need to move utilities to an “internal” package. However, encourages strong separation of API from implementation.
  69. 69. OSGi’s Answer Based on visibility not accessibility. To compile accurately, we need to fiddle the classpath. Would still be nice to support true compiler-supported “module private” access.
  70. 70. Compiler/Runtime Fidelity
  71. 71. Ever Seen These...? AbstractMethodError InstantiationError ClassCircularityError NoSuchFieldError ClassFormatError NoSuchMethodError IllegalAccessError VerifyError
  72. 72. Mostly Caused By: Compiler bugs – you have my sympathy! Partial compilation after refactoring – zero sympathy.
  73. 73. Except... AbstractMethodError InstantiationError ClassCircularityError NoSuchFieldError ClassFormatError NoSuchMethodError IllegalAccessError VerifyError
  74. 74. “Package-Private” package org.foo; package org.foo; public class Bar { public class Baz { // Default access, a.k.a public static void main(...) { // "package-private" Bar.doStuff(); static void doStuff() { } System.out.println("Hello"); } } } What could possibly go wrong??
  75. 75. “Package-Private” package org.foo; package org.foo; public class Bar { public class Baz { // Default access, a.k.a public static void main(...) { // "package-private" Bar.doStuff(); static void doStuff() { } System.out.println("Hello"); } } } Are Bar and Baz in the same package? It depends!
  76. 76. “Package-Private” ...is really runtime-package-private (JVM spec, §5.4.4) “determined by the package name and defining class loader” (JVM spec, §5.3) Accessibility depends on runtime deployment. The compiler doesn’t have a clue. Compiler gives up and simply allows access. Result: IllegalAccessError!
  77. 77. OSGi’s Answer Packages are the fundamental unit of sharing. “Split packages” are strongly discouraged. Therefore types in the same package are always* in the same class loader. * OSGi sadly does not prevent us from being stupid and splitting packages if that’s what we really, really want to do. See: Eclipse.
  78. 78. JSR 294: The Reality
  79. 79. New Access Modifier Top level types: Modifier Accessibility public Anywhere module Same Module (default) Same Package
  80. 80. New Access Modifier Members (fields, methods): Modifier Accessibility public Anywhere module Same Module protected Same Package, subtypes private Same Compilation Unit (default) Same Package
  81. 81. Sample package org.foo; module class Wibble { module static void doStuff() { System.out.println("Hello"); } } package org.bar; public class Wobble { public static void main(...) { Wibble.doStuff(); } }
  82. 82. Module Declaration Specifies a new named module. module-info.java
  83. 83. Examples: Jigsaw module M1 @ 1.0 { requires M2 @ 2.0, M3 @ 3.0; provides M4 @ 4.0, M5 @ 5.0; permits M6; class com.foo.bar; }
  84. 84. Examples: OSGi-like module M @ 1.2.0.beta for OSGi @ 4.2 { requires N; requires package P @ [1.0,2.0); requires X:5.0 vendor=S; classpath a.jar b.jar c.jar; }
  85. 85. With Annotations... import com.mycorp.annotations.*; @Foo module M @ 5.0u7:SPARC for osgi @ 4.2 { @Bar(“wibble”) requires N; @Quux requires package P @ [1.0,2.0); // ... }
  86. 86. Anatomy New restricted keyword module M1 @ 1.0 { requires M2 @ 2.0, M3 @ 3.0; provides M4 @ 4.0, M5 @ 5.0; permits M6; class com.foo.bar; }
  87. 87. Anatomy (cont) Name = word + (optional) version module M1 @ 1.0 { requires M2 @ 2.0, M3 @ 3.0; provides M4 @ 4.0, M5 @ 5.0; permits M6; class com.foo.bar; }
  88. 88. Anatomy (cont) Directives module M1 @ 1.0 { requires M2 @ 2.0, M3 @ 3.0; provides M4 @ 4.0, M5 @ 5.0; permits M6; class com.foo.bar; }
  89. 89. Versions Version string is opaque – meaning is undefined (determined by the module system). Also optional – default is undefined (determined by the module system).
  90. 90. Directives Content is arbitrary (though some syntax rules apply). Similar to annotations, but not imported. Semantics are undefined (determined by the module system).
  91. 91. Module Membership Which classes are members of this module? Undefined (determined by the module system).
  92. 92. Here Be Dragons!
  93. 93. Compiler Implications Not a lot is actually defined! The compiler must understand these directives somehow. Compiler cannot function without knowledge of the specific module system.
  94. 94. Compiler Implications We need either: A Jigsaw version of javac and an OSGi version of javac (plus N other javacs for other module systems). Compiler plug-ins.
  95. 95. For Developers The directives for each module system are completely different. A module that compiles for Jigsaw won’t compile for OSGi and vice versa. Must target a single module system.
  96. 96. Supporting Many Can libraries support multiple module systems? Perhaps... but at a high price Compile & test everything N times. Must offer N separate JARs for download.
  97. 97. Supporting Many Two version schemes for one library? Choosing a version number for our library will bind us to a specific module system.
  98. 98. A Rant about Standards
  99. 99. Resolving Conflict How do standards bodies resolve conflicting requirements?
  100. 100. Hit the Beach “I know! Let’s just keep both ways as options. Then implementers and users can choose for themselves, and we can hit the beach before they run out of loungers!”
  101. 101. Also Known As... Agreeing to disagree. Does not help users, it hurts them. Too often we are forced to deal with both approaches. Thanks a lot, standards dudes.
  102. 102. Simple Module System
  103. 103. Overview A proposal to JSR 294 expert group by: Peter Kriens (OSGi Alliance) BJ Hargrave (IBM & OSGi Alliance) Richard Hall (Sun & author of Felix) i.e. the OSGi posse.
  104. 104. What Is It? A concrete module system. Remove the undefined “black holes” of JSR 294. Provide as much of a module system as needed by most libraries. ~80% subset of OSGi, Jigsaw.
  105. 105. Focus on Users Libraries should be offered as modules. Do not make library authors build and ship multiple module types. Enable “drop-in” deployability to Jigsaw and OSGi runtimes.
  106. 106. Heal Fragmentation Not another new module system! Does not address all use-cases. An easy on-ramp to modularity. If you need more power, move up to Jigsaw/OSGi.
  107. 107. Concrete All keywords must mean something. No arbitrary module-specific keywords.
  108. 108. Extensible Allow access to extended features by specific module systems. Extensions must be extra-lingual. E.g. MANIFEST.MF for OSGi, annotations for Jigsaw.
  109. 109. Simple! Simple visibility model Single version number scheme Module membership
  110. 110. Visibility: OSGi Exports are limited Import packages, or whole modules Optional re-export of modules
  111. 111. Visibility: Jigsaw Modules export everything Whole-module imports Re-export is the default Module aliases (“provides”) Module friends (“permits”)
  112. 112. Visibility: SMS Modules export everything Whole-module imports That’s it!
  113. 113. Visibility: SMS No change for Jigsaw – a subset of its behaviour. For OSGi, very close to Require-Bundle with all packages exported. Will require a minor change to the OSGi spec (R4.3 or R5?)
  114. 114. Versions: SMS OSGi’s versioning scheme is admittedly quite strict (but qualifiers can smooth over many differences). Sun has stated the OSGi scheme does not meet Jigsaw’s requirements. TELL US THE REQUIREMENTS. OSGi will update its spec!
  115. 115. Module Membership Jigsaw: Individual Java files can declare module membership module com.mycorp; package com.mycorp; import java.util.*; ...
  116. 116. Module Membership OSGi: Not a compile-time concept. Any class in the physical bundle (JAR file) is a member.
  117. 117. Module Membership SMS: Membership corresponds to the module artifact, e.g. JAR file. One class loader per module.
  118. 118. Summary
  119. 119. A modular JDK will be a Good Thing TM.
  120. 120. Summary But the JDK is “special” The same technology does not necessarily work well for applications.
  121. 121. Summary For library authors, OSGi metadata can be added and tested now. If future compatibility with Jigsaw is a concern, keep it simple and follow SMS’s rules.
  122. 122. Get Involved Support SMS Subscribe to the JSR 294 mailing lists Support OSGi!
  123. 123. Thank You

×