Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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