Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] JEP 336: deprecate pack200

Hi all,

On the p2-dev mailing-list, a user/contributor has mentioned this JEP: . It's about removing pack200 from JRE.
The user message and a following discussion are available at

pack200 is heavily used by p2 to reduce download size/time.
The big question is, if it's not standard any more, what are the possible choices and their pros/cons:
* Plan1: p2 contributors switch p2 to an alternative implentation of pack200
  ** Pros
     *** No functional change
     *** Still smaller download size/time
  ** Cons
     *** Need to find a good pack200 un/compression engine (seems like a hard task), or to help one if getting good enough to be a substitute (slightly harder), or to author a good one (extremely harder); and help maintaining them on the long run (hard)
     *** Adapt p2 to use a newer compression engine
     *** overall, the 2 ones fail in the category "it's a lot of work".
* Plan2: drop pack200 from p2 on future Java
  ** Pros
    *** relatively simple, p2 most likely has the switches to ignore pack200 already, so we can just configure those according to whether JRE ships pack200
    *** sustainable and easier maintenance on the long run
  ** Cons
    *** Bigger downloads when updating, more load on

Plan 2 has the big advantage of requiring less effort. The big question is would scale enough to serve non-packed artifacts?
And maybe other questions to discuss?

Note that for the architecture council, I think the right grain of discussion is mostly to evaluate whether dropping pack200 support would be a major issue or not.
For technical implementation details (p2 dynamically chosing pack200 or not according to JRE, considering other compression formats...), then the p2 bugtracker and mailing-lists are more appropriate.


Mickael Istria
Eclipse IDE developer, for Red Hat Developers

Back to the top