pack200 support in tycho

[laeubi]

As announced here the plan is to drop (native) pack200 support. Also as mentioned here there seem to be some approach to have pack200 "in code" by the Apache commons project.

So I'd like to open this discussion if we at least should support reading of pack200 artifacts in tycho.

[joakime]

pack200 had it's day.
At this point it can be viewed as a historical curiosity.

Some history.

• Pack200 was specified in 2004 as part of JSR 200.
• It was released into the JVM classlib for Java 1.5
• Back in 2004 ...
  • The average web page size was 20KB
  • The average software update over the internet was 1MB
  • The average mobile app (predates android/iphone, so think j2me) was 500KB
  • The average java application had 15 dependencies
  • The google homepage was 3KB total (all resources)
  • Google proudly announced that it had saved 2 bytes on the homepage which saved significant bandwidth and improved page load times.
  • USB Thumb Drives were 500MB at 480 Mbit/second
  • Internet speeds were (38 kbps dial-up, 861 kbps DSL, and 2,178 kpbs Cable)

Things have changed, a lot.

Today in 2021

• Pack200 was deprecated as part of JEP 336 in JDK 11 in 2018
• Pack200 was removed from the JVM as part of JEP 367 in JDK 14 in 2020
• The average web page size is now approaching 40MB (all resources included).
• The average software update is now over 2GB (thanks to the skewing that video games and os's bring to the table).
  • Windows 10 security updates are 100MB
  • Windows 10 feature upgrades are 4.8GB
  • Android security updates are 12MB
  • Android minor release updates are 400MB
  • Android major version updates are 2.8GB
• The average mobile app size is 60MB (81MB for iOS and 43MB for Android)
• The average java application now has 70 dependencies (number from a conference discussion about github dependabot and java)
• USB Thumb Drives are now at 1TB at 150 Mbytes/second
• Internet speed are now 85 Mbps

IMO, the byte savings that pack200 brings to the table are not worth the effort, manpower, maintenance, and complexity.
I have a feeling that the Apache Commons Compress for pack200 will always be behind the curve with new JDK releases/bytecode anyway.

[mickaelistria]

I fully approve this comment; trying to keep pack200 alive is going to become more and more expansive for less and less value. Pack200 will soon be not supported anymore by Eclipse Platform nor p2 and there is no intention in Platform to use alternative implementations if this is abandoned from the JDK. So anyone willing to invest (a lot) in keeping production of pack200 artifacts possible with Tycho needs to understand that there soon will be about 0 clients able to consume them.

[laeubi]

I have a feeling that the Apache Commons Compress for pack200 will always be behind the curve with new JDK releases/bytecode anyway.

So anyone willing to invest (a lot) in keeping production of pack200 artifacts

I'd like to highlight one important aspect of my text that might got missed a bit:

if we at least should support reading of pack200 artifacts

That would be pure backward-compatibility for update-sites that already contain pack200 artifacts! But if anyone is fine with dropping support I'm fine with it also...

[joakime]

if we at least should support reading of pack200 artifacts

That would be pure backward-compatibility for update-sites that already contain pack200 artifacts! But if anyone is fine with dropping support I'm fine with it also...

This feels like the "big bang" moment for Eclipse and Tycho (just like Jakarta EE and it's namespace change).
No backward compat offered. etc.

[mickaelistria]

I'm not aware of any p2 repo offering only .pack.gz artifacts, so I don't think it'd be a big bang, maybe a few small bangs in the worst case.