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

Looks like pack200 is way more efficient.
http://www.cs.mun.ca/java-api-1.5/guide/deployment/deployment-guide/pack200.html#gzip_compression

Also tested for a few Eclipse plug-ins and had similar results, here
is for JDT core:

-rw-r--r-- 1 vogella vogella 6501661 Jun 26 10:26 jdt.core.jar.gz
-rw-r--r-- 1 vogella vogella 2344237 Jun 26 10:27 jdt.core.jar.pack.gz



On Tue, Jun 26, 2018 at 10:13 AM, Aleksandar Kurtakov
<akurtako@xxxxxxxxxx> wrote:
>
>
> On Tue, Jun 26, 2018 at 10:53 AM, Lars Vogel <lars.vogel@xxxxxxxxxxx> wrote:
>>
>> Hi Mickael,
>>
>> AFAIK the webserver is typically the one which should do the
>> compression (using Gzip compression).
>>
>> So maybe it is better to do this on the transport layer?
>
>
> Is there any measurement about the compress ratio of httpservers gzip and
> pack200 and gzip+pack200 ? It would be nice to have some data so we would
> know what the real loss would be before deciding what the solution would be.
>
>>
>>
>> The fastest HTTP engine to my knowledge it OKHttp, which is the one
>> used in Android devices. http://square.github.io/okhttp/  OKHttp
>> supports transparent GZIP.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=477524 as an enhancement
>> request for ECF to support OKHttp.
>>
>> Best regards, Lars
>>
>> On Tue, Jun 26, 2018 at 9:31 AM, Mickael Istria <mistria@xxxxxxxxxx>
>> wrote:
>> > 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.
>>
>>
>>
>> --
>> Eclipse Platform project co-lead
>> CEO vogella GmbH
>>
>> Haindaalwisch 17a, 22395 Hamburg
>> Amtsgericht Hamburg: HRB 127058
>> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
>> USt-IdNr.: DE284122352
>> Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web:
>> http://www.vogella.com
>> _______________________________________________
>> 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.
>
>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
>
> _______________________________________________
> 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.



-- 
Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com


Back to the top