This got me thinking about the need/current state of unpack200/pack200 (1)…
When creating nbm some (mainly older say Netbeans 8.x timeframe nbm) leveraged pack200 in attempts to save space. In more recent JDK versions in/pack200 capabilities were remove (2) as of JDK 14. I workaround was identified and a way to locate existing unpack was implemented (3) which required selecting the location of a pre-jdk14 version of unpack200 executables. There was other discussions/issue about this (4) prior to (3), during which finding alternatives was suggested like a forked version of the pack/unpack200 or leveraging Apache common compression. However each of these needed some work. I believe at the time: - There where no dependency artifacts available for using the fork and - The Apache compress while it did add functionality based on Apache harmony JDK, it was not compatible with newer unpack200 handling which would require further updates So in summary is it worth reviving this effort to allow support. If there is user interest I can move this over to the dev mailing list if preferred. (1) https://en.m.wikipedia.org/wiki/Pack200 (2) https://openjdk.java.net/jeps/367 (3) https://github.com/apache/netbeans/pull/2317 (4) https://issues.apache.org/jira/browse/NETBEANS-2842 On Sun, Jun 5, 2022 at 9:09 AM Ernie Rael <err...@raelity.com> wrote: > > I also wrote a script that repackages an nbm so that unpack200 isn't > required. > -- Eric Bresie ebre...@gmail.com
