[External] : Re: Unpack200 alternatives

[Ron Pressler]

I’m not sure I understand the issue. The JARs don’t need to be actively maintained to be decompressed,
and there is no code-level migration required; we’re talking about an offline tool. Decompress them once, 
put them in a public or private Maven repo, and then they can be used by new and old JDKs alike.

BTW, the removed functionality is open-source, with an established license, and anyone can fork
it in accordance with that license, as it seems someone already has.

As to the more general pain of migration, the encapsulation effort that is underway (JEPs 396 and 403), is
intended to address exactly that (as well as tools like jdeprscan).

— Ron


> On 23 Mar 2021, at 12:41, Eric Bresie <ebresie at gmail.com> wrote:
> 
> 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