• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
OpenJDK Penrose Presentation (JavaOne 2012)
 

OpenJDK Penrose Presentation (JavaOne 2012)

on

  • 1,416 views

Presentation given on OpenJDK project Penrose by Tim Ellison and David Bosschaert at Penrose BOF at JavaOne 2012

Presentation given on OpenJDK project Penrose by Tim Ellison and David Bosschaert at Penrose BOF at JavaOne 2012

Statistics

Views

Total Views
1,416
Views on SlideShare
1,356
Embed Views
60

Actions

Likes
2
Downloads
21
Comments
0

2 Embeds 60

https://twitter.com 59
http://webcache.googleusercontent.com 1

Accessibility

Categories

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
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    OpenJDK Penrose Presentation (JavaOne 2012) OpenJDK Penrose Presentation (JavaOne 2012) Presentation Transcript

    • Penrose @OpenJDKTim Ellison, IBMDavid Bosschaert, Red Hat September 2012
    • Agenda• Level setting o Introduction to modularity o Modules and the JRE o The Jigsaw project o OSGi• Introduction to Project Penrose o Goal of the project o Structure of the project o Technical roadmap• Technical work o Achievements o Observations o To be done• Advice and call to arms
    • What is a module?Why do we need a module system?• Modules facilitate software engineering & enhanced runtime capabilities o Decomposition of complex systems o Software assemblies of pre-built modules o Provisioning / deployment, including module repositories o Versioning and configuration management• The module system is used to manage the modules, including installing, activating, resolving module requirements and conflicts.• Interacting with the module system provides a higher level abstraction than the language provides directly.
    • Modules in Java• The module as a unit of encapsulation...• The Java language already has two kinds of module: classes and packages. o classes encapsulate fields and methods o packages encapsulate classes and resources• Problem: neither of these is a deployable unit (too granular, too tightly coupled).• Javas unit of deployment is the JAR file. o No encapsulation, therefore not a module!• Problem: need an entity that is a deployable unit of encapsulation.
    • Desirable characteristics of a module• A module should be highly coherent• A module should be loosely coupled to other modules.• A module should be explicit about what it provides to other modules.• A module should be explicit about what it depends on from other modules.
    • Why modules for the Java runtime (JRE)?• Presently the JRE is a monolithic entity o in general the runtime must assume your application will use anything and everything o class loaders provide runtime type definition and isolation o download time and start-up time are directly impacted by the number of types available in the runtime• Application start-up time includes a linear search through the class path to find system and application code o e.g. Oracle 1.7 Windows bootclass path contains nearly 20k classes o resources.jar rt.jar jsse.jar jce.jar charsets.jar o rt.jar index alone is ~1Mb• To the JRE, your applications jars’ indexes are disjoint & unsorted o there are JRE implementation tricks like look aside tables and shared classes that can help o class loading is a BIG time hog to amortize over the length of the run
    • Why modules for the Java runtime (JRE)? - continued• Dependency management o avoid “JAR hell” → trying satisfy competing requirements by simple path ordering o type name space comprising (unversioned) package name is often insufficient o e.g. my app depends upon foo-v2.jar and bar-v2.jar but foo-v2.jar depends upon bar-v1.jar - classpath foo-v2.jar; bar-v2.jar; bar-v1.jar –> my app “wins” - classpath foo-v2.jar; bar-v1.jar; bar-v2.jar –> foo “wins”• Module level visibility o public, protected, private and package-private level visibility means some implementation types (com.sun.) need to be marked public to be called by java. APIs. o convention asks people not to depend upon them...• Version control o ability to define the compatibility of a module based on numbering scheme o different module versions for different target devices / resource goals
    • Introducing Project Jigsaw• Project Jigsaw is an effort currently underway at OpenJDK o defining a simple module system for Java o modularizing the JRE itself o originally intended as an implementation detail for the JRE / applications, but being adopted as a Java standard (JSR)• Working within constraints of backwards compatibility o existing Java APIs “cannot” be changed o Some packages contain wildly different functionality e.g. java.util contains collection hierarchy and Locale infrastructure• Introduces language changes to define modules module com.example @ 1.0 { src/com/example/myclass.java requires jdk.base; src/com/example/myclassimpl.java requires foo @ 2.0; src/module-info.java requires bar @ 2.0; }
    • Introducing OSGi• Existing, mature, standards-based modularity solution for Java applications.• Rich modularity model based on code-level (package) dependencies, module-level dependencies, and services.• First practical solution for effective component reuse o well supported by multiple implementations, tooling, etc.• Millions use applications built with OSGi o most application servers are based on OSGi• No language changes. Bundle-ManifestVersion: 2 Bundle-SymbolicName: com.ex.mybundle o defines info in META-INF/MANIFEST.MF Bundle-Version: 1.0.0 Import-Package: com.example.bar Export-Package: com.example.foo
    • Multiple dependency resolution• The module system must resolve bundle dependencies, possibly in the face of multiple valid alternatives o e.g. my app depends upon (foo-v2.jar and (bar-v1.jar or bar-v2.jar)) and foo- v2.jar depends upon bar-v1.jar o if my app touches bar first, the module system may chose bar-v2.jar o if my app touches foo first, the module system will chose bar-v1.jar• OSGis dynamic dependency resolution attempts to find the best fit for currently invoked bundles at runtime o modules are apparent at runtime o runtime activation lifecycle: installed, resolved, starting, active, stopping, uninstalled• Jigsaw resolves module dependencies during build, installation, or runtime o gives opportunity for load time optimizations such as pre-verify, indexing, etc. o Equinox OSGi implementation has similar optimizations.
    • Agenda• Level setting o Introduction to modularity o Modules and the JRE o The Jigsaw project o OSGi• Introduction to Project Penrose o Goal of the project o Structure of the project o Technical roadmap• Technical work o Achievements o Observations o To be done• Advice and call to arms
    • Project Penrose - the road to reality• Both Jigsaw and OSGi are here to stay! o Try to get the best of both worlds o It need not be a zero-sum game• OSGi is established and will continue to be well used• Jigsaw is underway and a key component to the Java SE plans• Project Penroses goal is to demonstrate interoperability between Jigsaw and OSGiOSGi 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. Thekernel 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 modulesystem’s reification API. Java Module-System Requirements
    • Project Penrose - structure• Penrose is structured to allow collaboration between OSGi and Jigsaw developers o OSGi (Equinox) and Jigsaw are governed by different foundations, companies and licenses o Need to allow separation of developers• Two Penrose code repositories o Main code repository is downstream from Jigsaw § Provides opportunity to be experimental without disrupting Jigsaw progress § Kept in sync with Jigsaw changes, easy to pass code upstream § “show me” working code, rather than arguments on Jigsaw lists o Second code repository specifically for Penrose tools, demos, etc. o These are licensed under GPLv2 + classpath exception o Code developed in Penrose will be delivered through Jigsaw
    • Project Penrose - structure• Two Penrose mailing lists o Developer mailing list (penrose-dev) § Conversations around coding work on main Penrose repository § Incudes details of Jigsaw implementation and Penroses modifications § This is licensed GPLv2 o Discuss mailing list (penrose-discuss) § Conversations around interoperability requirements, design and new APIs § No implementation code is exchanged directly on this list § This is dual licensed GPLv2 and BSD• Java Specification Request (JSR) o Looking forward to a JSR in which design discussions can take place
    • Project Penrose: technical roadmap• Goal #0 : toleration o ensure that OSGi frameworks continue to run unmodified on a Jigsaw enabled runtime o creating modules / bundles that have both Jigsaw & OSGi metadata on the same JAR• Goal #1 : interoperability of module info metadata o ensure Jigsaw metadata can be enhanced with OSGi concepts o teach OSGi to read Jigsaw module info o mapping Jigsaw metadata into OSGi format for the framework to understand, e.g. requires ⇒ Require-Bundle: o resolve Jigsaw modules using the OSGi resolver• Goal #2 : OSGi implementation exploit of Jigsaw modularity o enhance OSGi to use Jigsaw publication repositories, API, etc• Goal #3+ : Full interop o a blend of OSGi and Jigsaw cross delegation on module phases
    • Agenda• Level setting o Introduction to modularity o Modules and the JRE o The Jigsaw project o OSGi• Introduction to Project Penrose o Goal of the project o Structure of the project o Technical roadmap• Technical work o Achievements o Observations o To be done• Advice and call to arms
    • Achievements in Level 0 : Toleration• Achievement #1: pass the OSGi tests on a Jigsaw enabled runtime o Equinox 3.7.2 – the OSGi reference implementation o OSGi 4.3 Compliance Tests – with minor patch for test case error o Running on Windows XP SP3 & Ubuntu 11.04• Achievement #2: run a Java application as either OSGi or Jigsaw modules o Took Java 2D demo o Broke it into multiple functional units, and run the demo as OSGi bundles OR Jigsaw modules
    • Observations: Jigsaw Module Metadata• Jigsaws module-info.java files compile into module-info.class files o ultimate .jar module contains binary metadata• Number of issues with these files o cannot (or very hard) to extend § other module systems or tools may need to store additional module- related data o binary files are not easy to read § you need to use a tool § or create your own .class file reader § may make troubleshooting harder too• Goal to create an readable, easily parsed metadata format o extensible o expressive enough for Jigsaw and OSGi
    • Achievements in Level 1: Module Metadata inPenrose• Penrose proposes using module-info.json o Plain Text module definitions o In JSON• JSON offers o Better extensibility, additions can be made inline o Easier to read from modular JAR files for humans for tools o For performance, implementations can still cache their own binary representations
    • JSON Module Metadatamodule-info.java (Jigsaw) module-info.json (Penrose) "module" : {module org.astro @ 1.2 { "name" : "org.astro", "version" : "1.2", exports org.astro; "exports" :} [{ "name" : "org.astro", "org.osgi.version" : "1.2.3"In the Jar file: }] }binary module-info.class Note the extension on the exports In the Jar file: plain text module-info.json
    • DemosThe current set of Penrose demos shows: • Modules that use JSON metadata (no module-info.java/.class files) • Modules that work both in JavaSE and in OSGi o currently duplicate module information o unified module information in the future
    • To be done Level 2/3: Deep integration with OSGiThis pilot needs to start, some areas to look at: • Loading JavaSE modules in OSGi as bundles o OSGi will most likely be extended to understand JavaSE Module Metadata. • Define extensions to JavaSE module metadata to cover OSGi information o Package Versions, Package Imports, etc... • Wiring to existing JavaSE modules in OSGi package imports
    • Agenda• Level setting o Introduction to modularity o Modules and the JRE o The Jigsaw project o OSGi• Introduction to Project Penrose o Goal of the project o Structure of the project o Technical roadmap• Technical work o Achievements o Observations o To be done• Advice and call to arms
    • Final words of advice• Stop using internal APIs and implementation classes o You will be broken in a modular world o Be modest in your API usage and we can likely help with a tailored JRE• If you need a modularity story that works before Java 9 (expected summer 2015) then the answer is OSGi o Penrose will ensure OSGi continues to work beyond Java 9 too• OSGi has greater expressiveness o Experience of modularity has resulted in a rich set of behaviors o While you may not need it now, do you want to change system when you do need it?• We would like to see the JSR created right now so that a Java Community Expert Group can get to work on designing the Java Module System.• Come and participate in OpenJDK Jigsaw or Penrose projects!
    • LinksPenrose website: http://openjdk.java.net/projects/penrosePenrose mailing lists: http://mail.openjdk.java.net/mailman/listinfo/penrose-dev http://mail.openjdk.java.net/mailman/listinfo/penrose-discussPenrose forests: http://hg.openjdk.java.net/penrose/jigsaw http://hg.openjdk.java.net/penrose/penroseJSON ModuleInfo documentation http://hg.openjdk.java.net/penrose/penrose/raw-file/tip/doc/ PenroseModuleInfoJSON.html