• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Java 7 Modularity: a View from the Gallery
 

Java 7 Modularity: a View from the Gallery

on

  • 4,465 views

 

Statistics

Views

Total Views
4,465
Views on SlideShare
4,408
Embed Views
57

Actions

Likes
4
Downloads
114
Comments
1

4 Embeds 57

http://www.slideshare.net 22
http://devpub.kr 20
http://blog.iband.kr 10
http://webcache.googleusercontent.com 5

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • java 7
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Java 7 Modularity: a View from the Gallery Java 7 Modularity: a View from the Gallery Presentation Transcript

    • 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 specification. Nevertheless, probably a de facto standard.
    • 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
    • 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 compiler (shout if I’m wrong!)
    • 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.
    • 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.
    • 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.g. “this software requires Java 1.4 or higher”.
    • 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.
    • 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 principal allegiance is to the Java platform and community.
    • Overview Announced in a blog post by Mark Reinhold, Dec 2008. “focused narrowly upon the goal of modularizing the JDK”
    • 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 “provides” B.
    • 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++.
    • 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 can see all types in B and C.
    • 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.
    • 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
    • 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 above but below 1.2.0.0
    • 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
    • OSGi
    • Bundle = Module
    • 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
    • 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 provider exports each package.
    • 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!
    • Requires We can use whole-module dependencies as an alternative. Require-Bundle: org.foo Strongly discouraged! Breaks substitution, creates high degree of fan- out.
    • Re-export With Require-Bundle we can re-export dependencies Tends to create a mess With Import-Package, re-exporting is simply not needed.
    • 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.
    • 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
    • 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/visibility assumptions Broken Class.forName()
    • 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. Circular dependencies make true separation impossible.
    • Assumptions Some internal classes (e.g. under com.sun.*) assume that certain other classes are always visible on every class loader.
    • Why Jigsaw? Jigsaw appears designed for this specific legacy modularisation task. No proscription against split packages. “requires local” to hack around class loader assumptions.
    • 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 libraries and applications.
    • 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!
    • 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.
    • 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 would gladly switch!
    • Fragmentation
    • 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.
    • 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!
    • 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.
    • 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.
    • JSR 294’s Promise
    • 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.
    • 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.
    • Accessibility & the Missing Modifier
    • Accessibility Today Top level types: Modifier Accessibility public Anywhere (default) Same Package
    • Accessibility Today Members (fields, methods): Modifier Accessibility public Anywhere protected Same Package, subtypes private Same Compilation Unit (default) Same Package
    • 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.
    • OSGi’s Answer Restricted list of packages exported from a module. Only explicitly exported packages may be seen by other modules.
    • 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.
    • 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.
    • Compiler/Runtime Fidelity
    • Ever Seen These...? AbstractMethodError InstantiationError ClassCircularityError NoSuchFieldError ClassFormatError NoSuchMethodError IllegalAccessError VerifyError
    • Mostly Caused By: Compiler bugs – you have my sympathy! Partial compilation after refactoring – zero sympathy.
    • Except... AbstractMethodError InstantiationError ClassCircularityError NoSuchFieldError ClassFormatError NoSuchMethodError IllegalAccessError VerifyError
    • “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??
    • “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!
    • “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!
    • 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.
    • JSR 294: The Reality
    • New Access Modifier Top level types: Modifier Accessibility public Anywhere module Same Module (default) Same Package
    • New Access Modifier Members (fields, methods): Modifier Accessibility public Anywhere module Same Module protected Same Package, subtypes private Same Compilation Unit (default) Same Package
    • 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(); } }
    • 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; class com.foo.bar; }
    • 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; }
    • 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); // ... }
    • 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; }
    • 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; }
    • 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; }
    • Versions Version string is opaque – meaning is undefined (determined by the module system). Also optional – default is undefined (determined by the module system).
    • Directives Content is arbitrary (though some syntax rules apply). Similar to annotations, but not imported. Semantics are undefined (determined by the module system).
    • 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 cannot function without knowledge of the specific module system.
    • 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.
    • 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.
    • 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.
    • Supporting Many Two version schemes for one library? Choosing a version number for our library will bind us to a specific module system.
    • 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, and we can hit the beach before they run out of loungers!”
    • 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.
    • Simple Module System
    • 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.
    • 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.
    • 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.
    • 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.
    • 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. MANIFEST.MF for OSGi, annotations for Jigsaw.
    • 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”) Module friends (“permits”)
    • 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 packages exported. Will require a minor change to the OSGi spec (R4.3 or R5?)
    • 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!
    • Module Membership Jigsaw: Individual Java files can declare module membership module com.mycorp; package com.mycorp; import java.util.*; ...
    • 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, keep it simple and follow SMS’s rules.
    • Get Involved Support SMS Subscribe to the JSR 294 mailing lists Support OSGi!
    • Thank You