You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <pe...@zeus.net.au> on 2020/06/08 04:58:53 UTC

Pack200 and Deflate / Zip compression

Hello River folk,

A couple of years or so ago I was working on using Pack200 for 
compression of proxy codebases, then it was deprecated and more recently 
removed from Java 14.

Initially I took pack 200 from Harmony and started working on that, at 
the time I thought the JDK version was written in C.  But then it turned 
out there was a java version of Pack200 in the openJDK.

I haven't focused on this recently, however I registered the pack200.net 
domain, so that I could release on Maven Central.  The OpenJDK version 
supports Java 8, while the Harmony version is Java 5.   It also seem 
that not a lot of work is required to get this up to date for the latest 
bytecode.

https://github.com/pfirmstone/pack200

https://github.com/pfirmstone/Pack200-ex-openjdk

The other thing I've long considered using is deflate, gzip or zip 
compression of marshalled streams.   This is actually very easy to code 
up into a JERI InvocationLayerFactory implementation, however I've had 
other priorities and never gotten around to.

I wanted to determine whether there is interest in improving performance 
using compression?

Regards,

Peter.


Re: Pack200 and Deflate / Zip compression

Posted by Peter Firmstone <pe...@zeus.net.au>.
Well after many years of thinking about it, it didn't take long to 
implement, below is a configuration file entry for deflate 
compression.   Performance impact is no noticeable I'm not getting any 
hotspot's for compression / decompression.   It would probably make 
sense for a registrar, but not so much for a service that doesn't return 
a large number of results or is unlikely to receive large parameters.

Cheers,

Peter.

     /* the exporter for test listeners */
     integrityExporter = new BasicJeriExporter(
     SslServerEndpoint.getInstance(0),
     new AtomicILFactory(
         new StringMethodConstraints(
             new InvocationConstraints(
                     new InvocationConstraint[]{
                         Integrity.YES,
                         AtomicInputValidation.YES},
                     null
                 )
             ),
         AccessPermission.class,
             org.apache.river.test.share.BaseQATest.class,
             Compression.DEFLATE
     )
     );

On 6/8/2020 2:58 PM, Peter Firmstone wrote:
> Hello River folk,
>
> A couple of years or so ago I was working on using Pack200 for 
> compression of proxy codebases, then it was deprecated and more 
> recently removed from Java 14.
>
> Initially I took pack 200 from Harmony and started working on that, at 
> the time I thought the JDK version was written in C.  But then it 
> turned out there was a java version of Pack200 in the openJDK.
>
> I haven't focused on this recently, however I registered the 
> pack200.net domain, so that I could release on Maven Central.  The 
> OpenJDK version supports Java 8, while the Harmony version is Java 
> 5.   It also seem that not a lot of work is required to get this up to 
> date for the latest bytecode.
>
> https://github.com/pfirmstone/pack200
>
> https://github.com/pfirmstone/Pack200-ex-openjdk
>
> The other thing I've long considered using is deflate, gzip or zip 
> compression of marshalled streams.   This is actually very easy to 
> code up into a JERI InvocationLayerFactory implementation, however 
> I've had other priorities and never gotten around to.
>
> I wanted to determine whether there is interest in improving 
> performance using compression?
>
> Regards,
>
> Peter.
>