Unpack200 alternatives

[Eric Bresie]

Yes that is one way...

However  these are legacy modules many of which are still of use but not
actively maintained.  So the IDE is expecting to load these modules but
because internally when running with a new JDK, it can no longer unpack
these, it would require extra manual steps to resolve this or use an old
JDK to install and then revert to a newer JDK for normal use.  None of that
seems to provide an ideal user experience.  Ideally an alternative can be
identified and the application can be updated to start using the
alternative without any complications for the user.

I’m sure the counter argument is probably, this has been deprecated for
some time and the application developers should had taken this
into consideration, but that is not always as cut and dry.  With the
frequency of releases, that doesn’t guarantee that projects will be able to
migrate immediately.  Migrating between JDK various on a massive project is
not necessarily an easy task nor is it potentially feasible when working
with volunteer effort without the resources of a fee/service based
development model.

It would have been nice to have the “removed” functionality , prior to
actual removal, get donated (including any potential licensing concerns) so
it can help in migrating and it can be maintained with any official
documentation for migrating reference the new open product for those that
may need it.  I guess the previously mentioned github project is a fork
prior to this so maybe that is the way forward.

Eric

On Tue, Mar 23, 2021 at 7:19 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

> Use the unpack200 tool of an old JDK to decompress those JARs and
> redistribute them before using them with a new JDK.
>
> — Ron
>
>
> > On 20 Mar 2021, at 13:46, Eric Bresie <ebresie at gmail.com> wrote:
> >
> > On another project, there are “modules” (not yet Java modules) that
> > leveraged the pack200 compression.  There are many legacy package that
> need
> > uncompressing.
> >
> > Given new JDK versions have remove pack200, with the proposed way of
> using
> > jpackage or Jlink when packaging new compressed packs, but how is one
> > expected to unpack pack200?
> >
> > Is pack compatible with another format (i.e. gzip) which could be used
> > instead?
> >
> > Or is it preferred to use something like
> > https://github.com/pack200/pack200 or other offshoots?
> >
> > Eric
> > --
> > Eric Bresie
> > ebresie at gmail.com
>
> --
Eric Bresie
ebresie at gmail.com