“Legacy Developer’s Guide to Java 9”

Speaker: Wayne Citrin

For more blog posts from JavaOne, see the table of contents

Multi-Release Jar Files

• Pre Java 9, can use late binding where probe API at runtime and fall back to old approach. Reflection is ugly
• add Multi-Release: true to manifest
• Can specify folders for different version of Java
• Can only specify versions Java 9 or later in folders. But can target Java 1.7 or 1.8 or whatever in root folder and provide Java 9 options in the “9” folder. Good for backward compatibility
• Unknown how increased release cadance will affect this
• New jar tool so can pass -legacyFolder and -release options.

Modules

• Can use ordinary jar files aongside modularized jars and include in module path
• A modularied jar file in the classpath is treated like any other jar file – the module rules are not enforced – no wins, but does work; good for migration
• All ars in the classpath are considered part of a single unnabled module – exports everything to other odules and can access al other modules
• If you hae a modularized app (aka you have a module path) but some old jars, just put in classpath
• If put non-modularized jar in modpath, it becomes an automatic module with the module name using the name of the jar file. It exposes everything and can acess everything. Still useful so other modules can refer to it as a dependency
• A package can only be in one named module (including automatic module – if not, will get runtime error
• Can often put legacy jars in mod path

JLink
For sending custom JDK distros

My take: Wayne said this was intended to be a talk vs a BOF. So he had slides. Worked out well since this is a topic where more people have ideas than can offer information. Good end to the day.