|Re: [eclipse.org-architecture-council] JEP 336: deprecate pack200|
Hey! +1 for dropping pack200 support (plan 2). Cheers, -Martin > Am 26.06.2018 um 09:31 schrieb Mickael Istria <mistria@xxxxxxxxxx>: > > Hi all, > > On the p2-dev mailing-list, a user/contributor has mentioned this JEP: http://openjdk.java.net/jeps/336 . It's about removing pack200 from JRE. > The user message and a following discussion are available at https://dev.eclipse.org/mhonarc/lists/p2-dev/msg05770.html > > 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 download.eclipse.org > > Plan 2 has the big advantage of requiring less effort. The big question is would download.eclipse.org 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. > > Cheers, > > -- > Mickael Istria > Eclipse IDE developer, for Red Hat Developers > _______________________________________________ > eclipse.org-architecture-council mailing list > eclipse.org-architecture-council@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council > > IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
Back to the top