commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
Subject Re: [compress] Protected API
Date Wed, 18 Mar 2009 06:02:03 GMT
Hi,

I think restrict visibility whereever possible would be a good idea
too. You can loosen later if one wants to.

I just checked out CPIO, AR and JAR. The latter two contain so less
code, everything looks good. But CPIO needs some work...

However, I guess you want to:

CpioArchiveInputStream
- make singleByteBuf and tmpbuf  final
- make byteArray2long static and move to helper

CpioArchiveOutputStream
- make "names"  final (this map is beeing used to detect duplicate entries)
- make setFormat to private. The class lets you set the format in the
constructor of the class OR sets the format for the first entry you
put, if you don't have a format specified. setFormat would make it
possible to change the Fomat while putting.
- Several methods are synchronized. I don't think that makes very much
sense. I'm speaking of putNextEntry, closeEntry, write and finish.
- move long2byteArray to helper

Question: its possible to add ArchiveEntrys with different format. I
think this is illegal and should be checked in putArchiveEntry - if
so, we need a FIXME here :-)

CpioArchiveEntry:
- Default Constructor should set a format
- setFormat should be private (and final? This is checked in the
stream classes, noone can easily override this - or should do that)

If you agree with the CPIO changes, I can do the patch.
Cheers
Christian


On Wed, Mar 18, 2009 at 6:23 AM, Stefan Bodewig <bodewig@apache.org> wrote:
> On 2009-03-18, Stefan Bodewig <bodewig@apache.org> wrote:
>
>> I'd like to remove some fields, make them private or final and maybe
>> move some methods around before our first release.  In particular:
>
> I just saw sebb's patch attached to SANDBOX-294 and he seems to agree
> with most of my points.  In addition the patch makes some package
> private fields bzip2 private - which I think is a a good idea as well.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message