DevNexus 2018 – Modules in Action

Title: Modules in Action
Speakers: Mark Reinhold

For more blog posts, see the DevNexus 2018 live blogging table of contents


Demo used Java 10 RC.

Using JShell to look at modules

  • “foo”.getClass().getModule() – module java.base
  • “foo”.getClass().getModule().getClass() – class java.lang.Module
  • new java.sql.Timestamp(0).getModule() – module java.sql

Modules

  • java –list-modules – ex: java.sql@10
  • There are 75 modules in Open JDK 10

JavaDoc

  • The Java 9 JavaDoc shows modules on the home page instead of all the packages.
  • Clicking a module shows you the packages in the module.
  • Java 9 JavaDoc has search box

Random facts

  • tree – unix commands that list what is in directory and children (not installed by default)
  • Showed that can use * in classpath to get all files in lib directory. (since Java 6)

Creating a bare bones module

  • Create module-info.java file in root of src folder
  • Simplest module file is one line: module moduleName { }
  • If run javap against the class file, you can see “requires java.base;” was added. This is like a constructor calling super(). It is mandatory so you don’t need to type it.
  • jar –file x.jar –describe-module – shows name of file, requires and the package contained
  • java –module-path lib -m moduleName/className – run the program
  • java -classpath jar className – can still run a modular jar on the classpath
  • jar –create –file x.jar –main-class class -C classes – create a jar that can run without specifying the class to run
  • java –modulepath lib -m moduleName – run the program without specifying it by name

Refactoring the module to split into two

  • module module1 { requires packageName; }
  • module module2 { exports packageName; }

Problems

  • If remove module2 and try to run, get java.lang.module.FindException on startup since can’t find module. Error inlcudes “Error occurred during initialization of boot layer”
  • If forgot to type “requires”, and compile get “package x is not visible”
  • If two modules require each other and compile, get “cyclic dependence involving package x”
  • If forget to type “exports” and compile, get “IllegalAccessError exception” along with long message about exporting

jlink

  • Optional Java linker
  • New directory jmods in JAVA_HOME.
  • Each module in the JDK has a file in jmods
  • JDK got a lot bigger with Java 9 because shipping two copies of each module – the main one and the jmods directory
  • jlink –module-path $JAVA_HOME.jmods –output jre –add-modules java.base – creates a JRE that is an order of magnitude smaller than the full one (44M vs 329B)
  • Can include your custom app into the image in addition to JDK
  • jlink –module-path $JAVA_HOME.jmods:lib –output jrePlusApp –add-modules java.base myCustomModule
  • jlink has a –compress flag to make file smaller
  • Not platform independent. Can cross link to create file for other operating system

Reflection

  • Want to make it so private really means private and final really means final. Vs reflection today.
  • Illegal reflective access – first time, get warning. The warning tells you how to enable more warnings. There probably are, but don’t want to blast you with them. Eventually, warning will turn into a hard error.
  • Not planning to disallow illegal reflective access until after Java 11.
  • Supplementing “exports”, is “open. It allows extra reflection

Inside a jmod

  • jmods are like a zip file with extra structure.
  • classes directory with all of the classes
  • conf directory for files in runtime image
  • include directory for jni header files
  • legal directory with licenses if any
  • bin directory for launchers
  • lib directory for native code

My take

I like the live demo approach along with the emphasis on both concepts and common problems. I also like that Mark left a lot of time for Q&A.

 

Leave a Reply

Your email address will not be published. Required fields are marked *