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]
