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

Plan 1 depends on whether it is legally allowed to implement a deprecated specification (JSR 200). Peter and I asked in the OpenJDK mailing list but did not (yet) get a response (see http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001467.html).

Currently plan 2 seems most likely for JREs that no longer ship pack200.

Dani



From:        Mickael Istria <mistria@xxxxxxxxxx>
To:        "eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
Date:        26.06.2018 09:31
Subject:        [eclipse.org-architecture-council] JEP 336: deprecate pack200
Sent by:        eclipse.org-architecture-council-bounces@xxxxxxxxxxx




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.orgscale 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