You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Philippe Mouawad <pm...@apache.org> on 2017/04/30 20:02:15 UTC
Any reason for not using java.util.zip.DeflaterInputStream
Hello,
For Deflate response encoded content, HC4 has a custom implementation
org.apache.http.client.entity.DeflateInputStream
Is there any reason for not using java.util.zip.DeflaterInputStream
available since Java 6.
Thanks
Regards
@philmdot
Re: Any reason for not using java.util.zip.DeflaterInputStream
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
Hi Oleg,
Thanks for your answer.
I didn't request for a change, I just wanted to know the historical reason
for that.
After making additional tests I see it breaks much more frequently that the
HC4 class.
Thanks
Regards
On Mon, May 1, 2017 at 4:05 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sun, 2017-04-30 at 23:02 +0200, Philippe Mouawad wrote:
> > Why not.
> > But why not just use the Java class instead of maintaining a custom
> > class
> > in HC ?
> >
>
> Philippe
>
> I replaced the existing implementation [1] with that from JRE and it
> broke our deflate compression tests [2].
>
> I also see little urgency in replacing custom DeflateInputStream given
> it uses standard Deflater class internally and is relatively small.
>
> However anyone willing to invest time into fixing the problem is very
> welcome to do so and raise a PR once the cause of test breakage is
> identified and resolved.
>
> Oleg
>
> [1] https://github.com/apache/httpclient/blob/trunk/httpclient5/src/mai
> n/java/org/apache/hc/client5/http/entity/DeflateInputStream.java
>
> [2] https://github.com/apache/httpclient/blob/trunk/httpclient5/src/tes
> t/java/org/apache/hc/client5/http/entity/TestDeflate.java
>
> > Thanks
> >
> > On Sun, Apr 30, 2017 at 10:22 PM, Gary Gregory <garydgregory@gmail.co
> > m>
> > wrote:
> >
> > > Maybe we should make it pluggable with an optional impl using
> > > Commons
> > > Compress?
> > >
> > > Gary
> > >
> > > On Apr 30, 2017 1:02 PM, "Philippe Mouawad" <pm...@apache.org>
> > > wrote:
> > >
> > > > Hello,
> > > > For Deflate response encoded content, HC4 has a custom
> > > > implementation
> > > > org.apache.http.client.entity.DeflateInputStream
> > > >
> > > > Is there any reason for not using
> > > > java.util.zip.DeflaterInputStream
> > > > available since Java 6.
> > > >
> > > >
> > > > Thanks
> > > > Regards
> > > > @philmdot
> > > >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
--
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie
UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>
UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>
Re: Any reason for not using java.util.zip.DeflaterInputStream
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2017-04-30 at 23:02 +0200, Philippe Mouawad wrote:
> Why not.
> But why not just use the Java class instead of maintaining a custom
> class
> in HC ?
>
Philippe
I replaced the existing implementation [1] with that from JRE and it
broke our deflate compression tests [2].
I also see little urgency in replacing�custom DeflateInputStream given
it uses standard Deflater class internally and is relatively small.
However anyone willing to invest time into fixing the problem is very
welcome to do so and raise a PR once the cause of test breakage is
identified and resolved.
Oleg
[1] https://github.com/apache/httpclient/blob/trunk/httpclient5/src/mai
n/java/org/apache/hc/client5/http/entity/DeflateInputStream.java
[2] https://github.com/apache/httpclient/blob/trunk/httpclient5/src/tes
t/java/org/apache/hc/client5/http/entity/TestDeflate.java
> Thanks
>
> On Sun, Apr 30, 2017 at 10:22 PM, Gary Gregory <garydgregory@gmail.co
> m>
> wrote:
>
> > Maybe we should make it pluggable with an optional impl using
> > Commons
> > Compress?
> >
> > Gary
> >
> > On Apr 30, 2017 1:02 PM, "Philippe Mouawad" <pm...@apache.org>
> > wrote:
> >
> > > Hello,
> > > For Deflate response encoded content, HC4 has a custom
> > > implementation
> > > org.apache.http.client.entity.DeflateInputStream
> > >
> > > Is there any reason for not using
> > > java.util.zip.DeflaterInputStream
> > > available since Java 6.
> > >
> > >
> > > Thanks
> > > Regards
> > > @philmdot
> > >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Any reason for not using java.util.zip.DeflaterInputStream
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
Why not.
But why not just use the Java class instead of maintaining a custom class
in HC ?
Thanks
On Sun, Apr 30, 2017 at 10:22 PM, Gary Gregory <ga...@gmail.com>
wrote:
> Maybe we should make it pluggable with an optional impl using Commons
> Compress?
>
> Gary
>
> On Apr 30, 2017 1:02 PM, "Philippe Mouawad" <pm...@apache.org> wrote:
>
> > Hello,
> > For Deflate response encoded content, HC4 has a custom implementation
> > org.apache.http.client.entity.DeflateInputStream
> >
> > Is there any reason for not using java.util.zip.DeflaterInputStream
> > available since Java 6.
> >
> >
> > Thanks
> > Regards
> > @philmdot
> >
>
--
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie
UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>
UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>
Re: Any reason for not using java.util.zip.DeflaterInputStream
Posted by Gary Gregory <ga...@gmail.com>.
Maybe we should make it pluggable with an optional impl using Commons
Compress?
Gary
On Apr 30, 2017 1:02 PM, "Philippe Mouawad" <pm...@apache.org> wrote:
> Hello,
> For Deflate response encoded content, HC4 has a custom implementation
> org.apache.http.client.entity.DeflateInputStream
>
> Is there any reason for not using java.util.zip.DeflaterInputStream
> available since Java 6.
>
>
> Thanks
> Regards
> @philmdot
>