On 21/06/06, Stepan Mishura <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
