harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Pack200 -- can now obtain files stored in archive
Date Wed, 21 Jun 2006 09:40:08 GMT
Alex,

Don't worry too much about the code being in the archive module, I agree
that it makes sense to keep the Pack200 code separate so that it can be
reused in Eclipse/Classpath/whatever and putting it into archive does
not preclude that.

The harmony archive component keeps it separated for access control
reasons (based on people's prior access as declared in the contributor
questionnaire) and for harmony corresponds to a packaging/modularity
story (the code will go into archive.jar).

As you know, you have a separate package space in archive
(o.a.h.a.i.pack200) and there is no reason why that package (or any
others that you need with that prefix) cannot be extracted, built and
packaged separately for sharing.  Obviously you have to continue to
ensure that you implement with Java APIs that will be found elsewhere,
and harmony will ensure that there is loose coupling into the pack200
implementation.

So keep going!  If you would prefer to see a separate target in the
archive build.xml that produces just a pack200.jar then I'm sure that
could be arranged too.

Thanks for the continued contribution.

Regards,
Tim

Alex Blewitt wrote:
> On 21/06/06, Stepan Mishura <stepan.mishura@gmail.com> wrote:
>> On 6/21/06, Alex Blewitt wrote:
>>
>> We agreed to separate providers implementation [1]. But I'm not sure the
>> same should be done for a concrete class implementation. In you case it
>> is implementation of java.util.jar.Pack200 but there are lots of other
>> cases
>> ,for example, java.security.Policy. So we'll got a lot of modules with
>> only
>> one class inside.
> 
> It's not just a concrete class, though. The API basically boils down
> to two methods:
> 
> unpack()
> pack()
> 
> The thing is, that an implementation of this JSR isn't just a simple
> class that provides a couple of methods. There's a lot of detail in
> the coding, decoding, and subsequent parsing that goes on. There's
> also a few other utilities that would be useful for performing
> compression on data streams if people would be interested in using
> them.
> 
> So don't confuse a simple API with a simple solution :-) The
> providers/ would be exactly the right place for this kind of code to
> live (at least, for the implementation). There are stub classes that
> are needed in the archive/ module, such as java.util.jar.Packer along
> with the factory code to instantiate the provider; but the factory
> instantiating the provider is actually specified as part of the
> Packer's static access methods.
> 
> Alex.
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message