Our presentation at InterConnect 2017 about Java SE 9 and our direct experiences with using it as our Java runtime for the WebSphere Liberty application server.

1. InterConnect
2017HAJ-4344:
Java SE 9 and the
Application Server
Tim Ellison, STSM, Java SE
Kevin Sutter, STSM, Java EE
1 4/3/17

2. 2 4/3/17
Please note
IBM’s statements regarding its plans, directions, and intent
are subject to change or withdrawal without notice at IBM’s
sole discretion.
Information regarding potential future products is intended to
outline our general product direction and it should not be relied
on in making a purchasing decision.
The information mentioned regarding potential future products
is not a commitment, promise, or legal obligation to deliver
any material, code or functionality. Information about potential
future products may not be incorporated into any contract.
The development, release, and timing of any future features
or functionality described for our products remains at our sole
discretion.
Performance is based on measurements and projections
using standard IBM benchmarks in a controlled environment.
The actual throughput or performance that any user will
experience will vary depending upon many factors, including
considerations such as the amount of multiprogramming in
the user’s job stream, the I/O configuration, the storage
configuration, and the workload processed. Therefore, no
assurance can be given that an individual user will achieve
results similar to those stated here.

3. Java SE 9
Standalone
• Tim Ellison, STSM, Java SE
3 4/3/17

4. Java 9 – Standard Features
JSR 379: Java SE 9 Release Contents
Reference implementation from Oracle due July 2017

5. Enhancements Targeted to Java 9
JEP 201: Modular Source Code
JEP 265: Marlin Graphics Renderer
JEP 102: Process API Updates
JEP 258: HarfBuzz Font-Layout Engine
JEP 143: Improve Contended Locking
JEP 257: Update JavaFX/Media to Newer Version of GStreamer
JEP 211: Elide Deprecation Warnings on Import Statements
JEP 245: Validate JVM Command-Line Flag Arguments
JEP 244: TLS Application-Layer Protocol Negotiation Extension
JEP 219: Datagram Transport Layer Security (DTLS)
JEP 267: Unicode 8.0
JEP 226: UTF-8 Property Files
JEP 254: Compact Strings
JEP 241: Remove the jhat Tool
JEP 240: Remove the JVM TI hprof Agent
JEP 250: Store Interned Strings in CDS Archives
JEP 214: Remove GC Combinations Deprecated in JDK 8
JEP 228: Add More Diagnostic Commands
JEP 165: Compiler Control
JEP 229: Create PKCS12 Keystores by Default
JEP 232: Improve Secure Application Performance
JEP 246: Leverage CPU Instructions for GHASH and RSA
JEP 224: HTML5 Javadoc
JEP 215: Tiered Attribution for javac
JEP 217: Annotations Pipeline 2.0
JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
JEP 213: Milling Project Coin
JEP 199: Smart Java Compilation, Phase Two
JEP 268: XML Catalogs
JEP 255: Merge Selected Xerces 2.11.0 Updates into JAXP
JEP 237: Linux/AArch64 Port
JEP 256: BeanInfo Annotations
JEP 236: Parser API for Nashorn
JEP 252: Use CLDR Locale Data by Default
JEP 264: Platform Logging API and Service
JEP 197: Segmented Code Cache
JEP 247: Compile for Older Platform Versions
JEP 216: Process Import Statements Correctly
JEP 235: Test Class-File Attributes Generated by javac
JEP 231: Remove Launch-Time JRE Version Selection
JEP 212: Resolve Lint and Doclint Warnings
JEP 243: Java-Level JVM Compiler Interface
JEP 223: New Version-String Scheme
JEP 220: Modular Run-Time Images
JEP 262: TIFF Image I/O
JEP 263: HiDPI Graphics on Windows and Linux
JEP 266: More Concurrency Updates
JEP 158: Unified JVM Logging
JEP 248: Make G1 the Default Garbage Collector
JEP 249: OCSP Stapling for TLS
JEP 251: Multi-Resolution Images
JEP 276: Dynamic Linking of Language-Defined Object Models
JEP 259: Stack-Walking API
JEP 274: Enhanced Method Handles
JEP 271: Unified GC Logging
JEP 270: Reserved Stack Areas for Critical Sections
JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization
JEP 221: Simplified Doclet API
JEP 225: Javadoc Search
JEP 280: Indify String Concatenation
JEP 279: Improve Test-Failure Troubleshooting
JEP 233: Generate Run-Time Compiler Tests Automatically
JEP 230: Microbenchmark Suite
JEP 110: HTTP/2 Client
JEP 272: Platform-Specific Desktop Features
JEP 193: Variable Handles
JEP 281: HotSpot C++ Unit-Test Framework
JEP 273: DRBG-Based SecureRandom Implementations
JEP 238: Multi-Release JAR Files
JEP 269: Convenience Factory Methods for Collections
JEP 278: Additional Tests for Humongous Objects in G1
JEP 282: jlink: The Java Linker
JEP 260: Encapsulate Most Internal APIs
JEP 200: The Modular JDK
JEP 261: Module System
JEP 277: Enhanced Deprecation
JEP 283: Enable GTK 3 on Linux
JEP 275: Modular Java Application Packaging

6. Java 9 Structural Changes
§ Yes, there will be lots of new functionality, but I'm not talking about those today.
§ Focus on two significant changes coming in Java 9 carrying large business impact
Change 1: The JDK layout is changing
Change 2: The world is going modular

7. Change 1: The JDK directory layout is changing
.
├── bin
├── include
│ └── linux
├── jre
│ ├── bin
│ │ ├── classic
│ │ └── j9vm
│ ├── lib
│ │ ├── applet
│ │ ├── boot
│ │ ├── cmm
│ │ ├── deploy
│ │ ├── endorsed
│ │ ├── ext
│ │ ├── fonts
│ │ ├── management
│ │ ├── oblique-fonts
│ │ └── security
│ └── plugin
├── lib
└── properties
└── version
.
├── bin
├── conf
│ ├── management
│ └── security
├── include
│ └── linux
└── lib
├── modules
└── security
IBM Java 8 GA OpenJDK Java 9 dev
Old World (pre-JDK9) New World (JDK9)
Installs are JRE or JDK.
JDKs contain a JRE, e.g. there are two bin directories.
There is now a single Java install that may contain
development tools, or not.
Placing code in certain directories conveys rights, i.e.
endorsed, and ext dirs.
Endorsed updates become “upgradeable modules”
Extensions concept is abandoned.
Implementation is provided in various (well-known) JAR files
such as rt.jar and tools.jar
No more JARs. IDEs etc will need to learn new file formats
and locations.
Supporting paraphernalia such as timezone info and fonts
can be seen
Implementation are hidden in modules
Impact: If you rely on the file layout, your application may break!
•IBM will be fixing all IBM products which have any dependency on layout
Recommendation: JDK9 early access builds will be available
•Try them, feedback to IBM is critical we have enough runway to mitigate issues

8. Java Platform Module System – high level goals
• Reliable configuration of programs
• replace the class-path with a new mechanism allowing program components to
declare explicit dependencies upon one another.
• Strong encapsulation
• enable a component to declare which of its public types are accessible to other
components, and which are not.

9. Reliable Configuration
java -classpath … is a linear search through class files, directories, and JARs
ClassNotFoundException
“JAR hell” → trying to satisfy competing requirements by simple path ordering
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”

10. Applications are defined by a module path configuration
§A well-formed configuration of JSR 376 modules comprises a directed graph of
module dependencies, rooted at java.base.
–All modules ultimately depend upon java.base
–(it is an implied requires if not made explicit)
§These configurations are specified at runtime by a module path
java -mp <dir1>:<dir2>:<dir3> -m com.example.app
§The responsibility of assembling a coherent and consistent set of
modules in the module path is delegated to external tools
–e.g. Maven, Ivy, Gradle
§In particular, JSR376 modules do not require version information
–The “works-with” semantics are open to interpretation by configuration tools
–A missing dependency, or different modules with the same name is an error
nami
ng
types
jgss
types
script
'
types
sasl
types
sasl
types
base
type
s
loggi
ng
types
sql
types
{java.base}
{java.logging}
{java.security.sasl}
{java.security.jgss}{java.naming}
{jdk.security.sasl}
{java.sql}
My
Application
{java.scripting}
~53 modules

11. Strong Encapsulation: Internal APIs are now hidden
• There are “Java Platform SE APIs”, and then there are those “useful”, internal public types...
• Often applications will over-reach the APIs into implementation types
• Java 9 will not discriminate!
• New module boundaries will only export public APIs to strangers
• Your code may be clean, but how about your dependencies?
• Some types have migrated into API in later releases, e.g. Base64Encoder
• Java 8 (and 9) contains a tool called jdeps that can show you the impact today
Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependency on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
jdeps -jdkinternals myapplication.jar
Recommendation: Run jdeps early to assess the impact of modularity

12. Basics of the Java Platform Module System
• Modules are defined by a new type of program component
• The runtime recognizes classes, interfaces, packages, and now modules
• There are updates to the Java language and JVM specifications
• Introducing new keywords to declare modules, and new behaviors for VM
accessibility
• Modules are named in a familiar convention, e.g. com.example.app
• Modules names starting “java.” provide platform APIs
• Module names beginning “jdk.” are supporting code
• Practically, modules are created in a source file called module-info.java
• Placed in the module root directory (c.f. package-info.java)
• Compiled to module-info.class by javac
• Not designed to be extensible by end users (e.g. no annotations)
• Expected to be recognized by a wide variety of tools to provide and read the
module definition

13. Simple module declaration
/**
* java.base defines and exports the core
* APIs of the Java SE platform.
*/
module java.base {
exports java.io;
exports java.lang;
exports java.lang.annotation;
exports java.lang.invoke;
exports java.lang.module;
exports java.lang.ref;
exports java.lang.reflect;
exports java.math;
exports java.net;
exports java.net.spi;
exports java.nio;
...

14. Simple module dependency declaration
/**
* java.base defines and exports the core
* APIs of the Java SE platform.
*/
module java.base {
exports java.io;
exports java.lang;
exports java.lang.annotation;
exports java.lang.invoke;
exports java.lang.module;
exports java.lang.ref;
exports java.lang.reflect;
exports java.math;
exports java.net;
exports java.net.spi;
exports java.nio;
...
module com.example.app {
requires java.base;
exports com.example.utils;
exports com.example.stuff;
}

15. Modular JAR files
§ JSR376 module information can co-exist with MANIFEST metadata
$ jar tf com.example.app‐1.0.jar
META-INF/
META-INF/MANIFEST.MF
module-info.class
com/example/utils/MyUtil.class
com/example/stuff/MyStuff.class
com/example/internal/MyInternals.class
JAR files can be both JSR376 modules and OSGi bundles simultaneously
There is some overlap in the metadata that needs synchronizing

16. Reflection and Accessibility
• Reflection APIs are enhanced by JSR 376 to allow for testing and adding new module links at runtime
• You can 'export' a package to another module
MyClass.getClass().getModule().addExports(<packageName>, <targetModule>)
• Or add a 'reads' relationship to another module
MyClass.getClass().getModule().addReads(<sourceModule>)
• Cannot use reflection to increase accessibility
• Types are only accessible if the dependency is readable, and the dependency exports the public type.
• The Java compiler and virtual machine enforce accessibility in the same way as a private method or field, i.e. an
attempt to use an inaccessible type will cause
•an error to be reported by the compiler, or
•an IllegalAccessError to be thrown by the Java virtual machine, or
•an IllegalAccessException to be thrown by reflective run-time APIs.
§ But there are runtime options to break out of modularity and ensure your application continues to work.

17. Interconnect
1H 16
2H 16
1H17
2H 17
- Java 9 Platform Release
- IBM Open Java PoC
Drumbeat
•Docker images
•Performance
•Footprint reductions
•
Drumbeat
•Cloud: Idle detection
•Basic Modularity
•Footprint reductions
Drumbeat
Cloud: Co-operative JVM
Cloud: Reduced footprint on Idle
Drumbeat
‘Lean Mean Cloud’ Demo
Performance Demo
Small footprint JRE + Liberty demo @
Inter-Connect (on Java 8)
IBM Java 9 Experience Roadmap
IBM Java 9 SE beta is open for business!
http://ibm.biz/java9beta

18. Java SE 9
in a Java EE Environment
• Kevin Sutter, STSM, Java EE
18 4/3/17

19. 19 20/02/17
Java 9 + WebSphere Roadmap
Java SE 9
development
WebSphere
exploitation
of Java 9
WebSphere
toleration of Java 9
Java SE 9
release
Application
exploitation
of Java 9

20. 20 20/02/17
Phase 1: Toleration of Java 9
•Applications using only Java spec interfaces should still work, unchanged
•Applications that depend on JDK internal APIs or deep reflection may encounter problems
•Applications depending on third-party software which depend on JDK internal APIs are also vulnerable
•CDI and JPA applications use deep reflection!
•If using Liberty-provided CDI and JPA services, no action needed – we’ll take care of it
•Java 9 command-line options offer a workaround
e.g. --add-reads, --add-exports, --add-opens
•IBM JDK migration guide can be found at: ibm.biz/java9-compat
•WebSphere analysis of Java 9 can be found at: ibm.biz/java9-liberty

21. 21 20/02/17
Phase 1: Toleration of Java 9
wlp
├── etc
│ └── jvm.options
└── usr
└── servers
└── myServer
└── jvm.options
Location of jvm.options Example jvm.options file

22. 22 20/02/17
Phase 1: Toleration of Java 9
•Liberty expects to be tolerant of Java 9 quickly
•All command-line options needed for Liberty runtime will be added automatically
•Liberty will initially run in the “unnamed module” space
•As a result, applications must also run in the “unnamed module” space

23. 23 20/02/17
Phase 2: Java EE Exploitation of Java 9
•It is still unclear how Java modules will interact in the Java EE space
•We expect there will be Java EE mandated named modules
•An example module-info.java for a Java EE application might look like:
module com.foo.myapp {
requires javax.servlet;
requires com.ibm.websphere.servlet;
}
•Since Liberty is an OSGi based runtime, it will maintain both OSGi and JPMS modular systems
•JPMS and OSGi applications will both be usable

24. Boot layer
24 20/02/17
Phase 2: Java EE Exploitation of Java 9
java.base java.logging java.xml
com.myapp
javax.servlet
JPMS modules
OSGi bundles
Source: ibm.biz/java9-osgi

25. javax.servlet layer
Boot layer
25 20/02/17
Phase 2: Java EE Exploitation of Java 9
java.base
javax.servlet
App Layer
com.myapp
java.logging java.xml
com.myapp
javax.servlet
JPMS modules
OSGi bundles
Source: ibm.biz/java9-osgi

26. Liberty Layer
26 20/02/17
Module Dependencies
Boot layer
java.base java.logging java.xml
Unnamed
Module
Unnamed
Module

27. Liberty Layer
27 20/02/17
Module Dependencies
Boot layer
java.base
App Layer
com.myapp
java.logging java.xml
Unnamed
Module
Unnamed
Module

28. Liberty Layer
28 20/02/17
Module Dependencies
Boot layer
java.base
App Layer
com.myapp
java.logging java.xml
Unnamed
Module
Unnamed
Module
Automatic Modules
log4j.jar
commons-
lang3.jar

29. 29 20/02/17
Bottom-up vs. Top-down migration to JPMS
•Bottom-up migration is the most obvious adoption path for JPMS
1.App Servers adopt JPMS
2.Third-party software adopts JPMS
3.Applications adopt JPMS
•Top-down migration is also possible with automatic modules
1.Applications adopt JPMS
2.App Servers and third-party software used as automatic modules
•In a Java EE environment, top-down migration offers no compelling modularity benefits
•Simply let Java EE apps run in the “unnamed module” space
•Wait for software down the stack to adopt JPMS first, then convert apps to use JPMS

30. 30 20/02/17
Taking server minify one step further
•With Java 9 it will be possible to use the jlink utility to “minify” a JDK
•Once JPMS is fully adopted, server deployment sizes can be reduced by using a minified JDK
Full JDK
Liberty
kernel servlet
JDK 9
Liberty
kernel servlet
java.base
java.xml
…

31. 31 20/02/17
Size breakdown of a modular JDK
java.base
javafx.web
java.desktop
jdk.localedata
jdk.deploy
jdk.compiler
All modules = 120 MB

32. Summary
• Liberty will tolerate Java 9 quickly
• Applications may need command-line workarounds in jvm.options to run on Java 9
• See: ibm.biz/java9-compat
• Official JPMS + Java EE adoption will not happen for a while
• Wait for bottom-up migration
• Run apps as unnamed modules for now
• Full JPMS adoption will result in smaller deployment sizes, because of reduced JDK size

33. Sampling of Related Sessions…
• HAJ-4308: OpenJPA, EclipseLink, and the WebSphere Migration Toolkit
• Monday, Mar 20, 1:00pm-1:45pm, Mandalay Bay South, Level 2 – Reef B
• HAM-4393: MicroProfile, Java EE, and the Application Server
• Monday, Mar 20, 2:00-2:45pm, Mandalay Bay North, Level 0 – Islander F
• 1842: Technical Deep-Dive into IBM WebSphere Liberty
• Tuesday, Mar 21, 1:30-2:15pm, Mandalay Bay North, Level 0 – Islander G
• Tuesday, Mar 21, 4:45-5:30pm, Surf D
• 7014: Roundtable Discussion on Building Java Microservices with WebSphere Liberty
• Monday, Mar 20, 2:00-2:45pm, Tropics A
• Wednesday, Mar 22, 8:00-8:45am, Tropics A
• HAJ-4328: Java EE 7 Overview
• Wednesday, Mar 22, 8:00-8:45am, Mandalay Bay South, Level 2 – Reef B
• BAS-5676: Java EE 8 Introduction
• Wednesday, Mar 22, 2:00-2:45pm, Mandalay Bay North, Level 0 – South Pacific A
• BMC-4286: MicroProfile: A Programming Model for Microservices-Based Applications
• Wednesday, Mar 22, 4:15-5:00pm, Mandalay Bay North, Level 0 – South Pacific A
• HAJ-4344: Java SE 9 and the Application Server
• Thursday, Mar 23, 10:30-11:15am, Mandalay Bay South, Level 2 – Reef B
• 1835: Agile Development Using MicroProfile and IBM WebSphere Liberty (Lab)
• Thursday, Mar 23, 10:30-12:15pm, South Seas D
3333

34. Questions?

35. 35 4/3/17
Notices and disclaimers
Copyright © 2017 by International Business Machines Corporation (IBM).
No part of this document may be reproduced or transmitted in any form
without written permission from IBM.
U.S. Government Users Restricted Rights — use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM.
Information in these presentations (including information relating to
products that have not yet been announced by IBM) has been reviewed
for accuracy as of the date of initial publication and could include
unintentional technical or typographical errors. IBM shall have no
responsibility to update this information. This document is distributed
“as is” without any warranty, either express or implied. In no event
shall IBM be liable for any damage arising from the use of this
information, including but not limited to, loss of data, business
interruption, loss of profit or loss of opportunity. IBM products and
services are warranted according to the terms and conditions of the
agreements under which they are provided.
IBM products are manufactured from new parts or new and used parts.
In some cases, a product may not be new and may have been previously
installed. Regardless, our warranty terms apply.”
Any statements regarding IBM's future direction, intent or product
plans are subject to change or withdrawal without notice.
Performance data contained herein was generally obtained in a
controlled, isolated environments. Customer examples are presented
as illustrations of how those customers have used IBM products and
the results they may have achieved. Actual performance, cost, savings or
other results in other operating environments may vary.
References in this document to IBM products, programs, or services
does not imply that IBM intends to make such products, programs or
services available in all countries in which IBM operates or does
business.
Workshops, sessions and associated materials may have been prepared
by independent session speakers, and do not necessarily reflect the
views of IBM. All materials and discussions are provided for informational
purposes only, and are neither intended to, nor shall constitute legal or
other guidance or advice to any individual participant or their specific
situation.
It is the customer’s responsibility to insure its own compliance with legal
requirements and to obtain advice of competent legal counsel as to
the identification and interpretation of any relevant laws and regulatory
requirements that may affect the customer’s business and any actions
the customer may need to take to comply with such laws. IBM does not
provide legal advice or represent or warrant that its services or products
will ensure that the customer is in compliance with any law.

36. 36 4/3/17
Notices and disclaimers
continued
Information concerning non-IBM products was obtained from the
suppliers of those products, their published announcements or other
publicly available sources. IBM has not tested those products in
connection with this publication and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be
addressed to the suppliers of those products. IBM does not warrant the
quality of any third-party products, or the ability of any such third-party
products to interoperate with IBM’s products. IBM expressly disclaims
all warranties, expressed or implied, including but not limited to, the
implied warranties of merchantability and fitness for a particular,
purpose.
The provision of the information contained herein is not intended to, and
does not, grant any right or license under any IBM patents, copyrights,
trademarks or other intellectual property right.
IBM, the IBM logo, ibm.com, Aspera®
, Bluemix, Blueworks Live, CICS,
Clearcase, Cognos®
, DOORS®
, Emptoris®
, Enterprise Document
Management System™, FASP®
, FileNet®
, Global Business Services®
,
Global Technology Services®
, IBM ExperienceOne™, IBM SmartCloud®
,
IBM Social Business®
, Information on Demand, ILOG, Maximo®
,
MQIntegrator®
, MQSeries®
, Netcool®
, OMEGAMON, OpenPower,
PureAnalytics™, PureApplication®
, pureCluster™, PureCoverage®
,
PureData®
, PureExperience®
, PureFlex®
, pureQuery®
, pureScale®
,
PureSystems®
, QRadar®
, Rational®
, Rhapsody®
, Smarter Commerce®
,
SoDA, SPSS, Sterling Commerce®
, StoredIQ, Tealeaf®
, Tivoli®
Trusteer®
,
Unica®
, urban{code}®
, Watson, WebSphere®
, Worklight®
, X-Force®
and
System z®
Z/OS, are trademarks of International Business Machines
Corporation, registered in many jurisdictions worldwide. Other product
and service names might be trademarks of IBM or other companies. A
current list of IBM trademarks is available on the Web at "Copyright and
trademark information" at: www.ibm.com/legal/copytrade.shtml.

37. InterConnect
2017
37 4/3/17