re:Getting from File to FileInputStream is easy and no reason to add
compression algorithms to IO.
I want to compress file (or dir). I get file on input and file(or byte[])
on
output. I can't understand why it should't be placed to IO.
If you look throw the code it works with IO packeges most of the time.
That's a bogus argument. Just because I have code that uses mostly
java.io classes does not make me file a JSR. ZipEntry is java.util.zip
btw not java.io.zip.
BTW java.util.zip not java.io.zip is bogus argument too ;-) (probably it was
a mistake of java architect)
IMHO If code deals only with IO and have no sence without IO it is better to
be a part of IO.
I don't mind to add it to compressions if compression developers will allow
it and won't ask me to add it to IO
because my code deals with files while thier code deals with streams and
they love to separate conecrns very much too ;-))))
re:Sorry, but do you actually read my responses?
Yes. Hope you'll do same with mine ;-)
Regards,
Vitaliy S
On 6/19/06, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> The JarEntry and ZipEntry treat non ASCII symbols different.
> See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4244499 for
details
> (unfortunatly it is the only plase I found it explained).
So the general algorithm is the same only the handling of the entries
differs.
Fair enough. Thanks for the pointer.
> re:Getting from File to FileInputStream is easy and no reason to add
> compression algorithms to IO.
>
> I want to compress file (or dir). I get file on input and file(or
byte[]) on
> output. I can't understand why it should't be placed to IO.
> If you look throw the code it works with IO packeges most of the time.
That's a bogus argument. Just because I have code that uses mostly
java.io classes does not make me file a JSR. ZipEntry is java.util.zip
btw not java.io.zip.
> Also I don't think it was good idea to seporate compress from IO. ;-)
Well, I like to separate concerns ...putting all different kinds of
algroithm implementations into one project mixes concerns. And I don't
think *that'*s a good idea ;-)
> to me it is same as example with PrintWriter
>
> what aproach do you prefer
> this one
> FileWriter fout = new FileWriter("fred.txt");
> BufferedWriter bout = new BufferedWriter(fout);
> PrintWriter pout = new PrintWriter(bout);
> or that one
> PrintWriter pout = new PrintWriter("fred.txt");
>
> I prefer the second variant.
Sorry, but do you actually read my responses?
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Vitaliy S
