Replacement of pack200 in Java 17

[Rajib Sahaa]

Hi,

Currently in our project, we have used Java - 8.

We are planning to upgrade to Java Machine - 17.

In Java-8, we have used pack200 in several places like below
==============
pack200 -J-Xmx512m --no-gzip work.jar.pack work.jar
==============

Now, in Java-17, we don't have pack200.

How we can achieve the above example in Java-17 in different way?

As per documentation, I need to use jlink and jpackage. But, I am not getting how to use these to replace pack200 for my use case.
Can anyone of you please help me ?

Regards
Rajib

[Carey Brown]

Have you tried using the .jar file uncompressed? Unless there's a specific need, omitting the compression step would probably be the path of least resistance going forward.

[Maarten Bodewes]

Well, uncompressed... Jar files are still compressed using zip DEFLATE. Pack200 simply isn't used anymore because it was Java / class file specific. That's a good way of quickly and often strongly compressing stuff, but it does mean that you have to update the tool each time the class file / byte code changes. The main question becomes: why would you explicitly disable zipping if you want to compress?

Very basically you're asking an XY-problem. You should ask yourself what the requirements are and then act on that. If you cannot find the requirements (such as download times etc.) then simply remove the conversion. Less is more.

[Rajib Sahaa]

Carey Brown wrote:Have you tried using the .jar file uncompressed? Unless there's a specific need, omitting the compression step would probably be the path of least resistance going forward.

Thanks Carey for your suggestion. Our product is more than 20 years old. Not aware of all the history. Considering your suggestion to see the options of not using pack200 to see the consequence.

[Rajib Sahaa]

Maarten Bodewes wrote:Well, uncompressed... Jar files are still compressed using zip DEFLATE. Pack200 simply isn't used anymore because it was Java / class file specific. That's a good way of quickly and often strongly compressing stuff, but it does mean that you have to update the tool each time the class file / byte code changes. The main question becomes: why would you explicitly disable zipping if you want to compress?

Very basically you're asking an XY-problem. You should ask yourself what the requirements are and then act on that. If you cannot find the requirements (such as download times etc.) then simply remove the conversion. Less is more.

Thanks Maarten for your suggestion and points. Our product is more than 20 years old. Not aware of all the history. I got your point to understand the need of it. Trying of not using pack200 to see the consequence in the product.

[Paul Clapham]

Rajib Sahaa wrote:Our product is more than 20 years old.

Indeed, it may be that the compression was done 20 years ago to reduce bandwidth or memory usage, for example, but that reduction is much less significant today.