[source] rebuilding xj3d under OpenJDK 14: pack error

Brutzman, Donald (Don) (CIV) brutzman at nps.edu
Sun Mar 22 12:23:26 PDT 2020 

Am testing new OpenJDK 14.

Got an error right near the end of X3D build all, related to izpack.

build.xml:
    <ant antfile="build.xml" target="dist" />
    <mkdir dir="${installers.dir}"/>
    <echo message="Running IzPack to build the installers..."/>
    <izpack input="${win.linux.32.64.installer.file}"
            output="${installers.dir}/${win.linux.32.64.installer.jar}"
            installerType="standard"
            basedir="${basedir}"
            inheritAll="true"
            compression="deflate"
            compressionlevel="9"/>

console:

Running IzPack to build the installers...
Building installer jar: C:\x-nps-gitlab\xj3d\installers\xj3d-2.2-nps-win-linux-32-64-installer.jar
Copying 13 files into installer
Merging 11 jars into installer
Writing 2 Packs into installer
C:\x-nps-gitlab\xj3d\buildInstallers.xml:67: 
java.lang.NoClassDefFoundError: java/util/jar/Pack200
	at com.izforge.izpack.compiler.Packager.createAgressivePack200Packer(Unknown Source)
	at com.izforge.izpack.compiler.Packager.writePacks(Unknown Source)
	at com.izforge.izpack.compiler.PackagerBase.writeInstaller(Unknown Source)
	at com.izforge.izpack.compiler.Packager.createInstaller(Unknown Source)
	at com.izforge.izpack.compiler.Compiler.createInstaller(Unknown Source)
	at com.izforge.izpack.compiler.CompilerConfig.executeCompiler(Unknown Source)
	at com.izforge.izpack.ant.IzPackTask.execute(Unknown Source)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
	at jdk.internal.reflect.GeneratedMethodAccessor98.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
	at org.apache.tools.ant.Task.perform(Task.java:350)
	at org.apache.tools.ant.Target.execute(Target.java:449)
	at org.apache.tools.ant.Target.performTasks(Target.java:470)
	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1391)
	at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
	at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
	at org.apache.tools.ant.Project.executeTargets(Project.java:1254)
	at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:261)
	at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:574)
	at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:128)
Caused by: java.lang.ClassNotFoundException: java.util.jar.Pack200
	at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1383)
	at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1338)
	at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1093)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 22 more

sleuthing reveals:
================================
* JEP 367: Remove the Pack200 Tools and API
  https://openjdk.java.net/jeps/367

Summary
Remove the pack200 and unpack200 tools, and the Pack200 API in the java.util.jar package. These tools and API were deprecated for removal in Java SE 11 with the express intent to remove them in a future release.
[…]

Description
Three types in the java.base module previously annotated with @Deprecated(forRemoval=true) will be removed in the JDK feature release to which this JEP is ultimately targeted:
    java.util.jar.Pack200
    java.util.jar.Pack200.Packer
    java.util.jar.Pack200.Unpacker
The jdk.pack module, which contains the pack200 and unpack200 tools, was previously annotated with @Deprecated(forRemoval=true) and will also be removed in the JDK feature release to which this JEP is ultimately targeted.

Risks and Assumptions
We assume that developers who rely on Pack200 have had enough notice about its proposed removal to make alternative arrangements. The deprecation-for-removal of Pack200 in JDK 11 was proposed and confirmed in June 2018, with no further interest in the topic since that time. (The Eclipse community, a significant consumer of Pack200, held discussions of its own (1, 2) but no further progress was reported.) The deprecation-for-removal of the Pack200 API was flagged in the Platform JSR for Java SE 11, and subsequently for Java SE 12 and Java SE 13. No comments were received on the Platform JSR's mailing lists (1, 2) about the proposed removal.

We assume that developers who use pack200 to shrink application JARs can switch to either the jlink tool or the jpackage tool to create application-specific runtimes with an optimized form factor. See JEP 282 and JEP 343 for more information about these tools. An early-access build of JDK 14 that includes jpackage is available.
================================

So Terry, with your izpack experience can you try to fix this?

Initial ssearch was inconclusive.... then looking at http://www.izpack.org didn't talk about this (and was last changed apparently in 2018) but it did link to maven repository, which has some words about avoiding pack200:

IzPack Maven Plugin Reference
https://izpack.atlassian.net/wiki/spaces/IZPACK/pages/491628/IzPack+Maven+Plugin+Reference

==================================
[…]
comprFormat
	default | gz | bzip2 | xz | lzma | deflate
	default
Optional compression format for single files defined in <packs>. All files in all packs except those explicitly marked as <pack200/> are automatically added compressed in the given format and uncompressed later when the installer starts. This may significantly decrease the installer size, but take some more time to compile the installer and install the files later.
See also _Compressing pack files_ for more information on this feature.
Since: IzPack 5.1 (has been broken in 5.0)
==================================
Compressing pack files
https://izpack.atlassian.net/wiki/spaces/IZPACK/pages/67078184/Compressing+pack+files
Activating pack compression of any file

As of IzPack 5.1, pack compression of standard compression formats different to Pack200 can be enabled globally either at compiler level, like a Maven plugin or Ant option, or in the <info> section.

Only the raw data of the files packed to the installer is compressed using this method during compiling and automatically uncompressed by the installer.

The following formats are supported:

    GZIP ('gz')
    BZIP2 ('bzip2')
    XZ ('xz') (very good compression rate, but slower)
    LZMA ('lzma') (very good compression rate, but slower)
    Deflate/ZIP ('deflate')

The default is adding all files uncompressed to the installer jar, where just the native compression of the installer jar itself applies.
[…]

Example
<info>
    ...
    <pack-compression-format>xz</pack-compression-format>
</info>
[…] etc.

Ant builds

There is an compressionLevel attribute available at the IzPack Ant task for defining the compression algorithm.
Example:
<izpack compressionLevel="xz" ... />
==================================

Hoping you could upgrade izpack jar (if needed) and try to fix that under OpenJDK 13.0.2; then I could test your changes under OpenJDK 14.  TIA.

all the best, Don
--
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman

More information about the source mailing list