[source] rebuilding xj3d under OpenJDK 14: pack error
Don Brutzman
brutzman at nps.edu
Thu Mar 26 17:12:02 PDT 2020
Thanks for good session today Terry, we are much farther along now that izPack is building again. Looking forward to tuning the installer further.
Status:
* https://gitlab.nps.edu/Savage/xj3d/issues/4
On 3/22/2020 12:23 PM, Brutzman, Donald (Don) (CIV) wrote:
> 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
>
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