Problem with Java6 + applet + reading file from http
I've been using the below code since Java1.1 for downloading files from a http-server. But with Java6 it has stopped working. Or rather it downloads less bytes than the file actually is.
Ex. when loading a file that is actually 28.043 bytes, it consistently only loads 28.011 bytes.
connection is an instance of URLConnection.
InputStream input =new BufferedInputStream(connection.getInputStream(), 10240);
OutputStream output =new BufferedOutputStream(new FileOutputStream(savePath +"/" + download.name), 10240);
byte buf[] =newbyte[10240];
int read;
float total = 0;
while (true){
read = input.read(buf);
if (read < 0){
break;
}
output.write(buf, 0, read);
}
}
output.close();
input.close();
The problem only occurs when the code is running as an applet in a browser (IE + Firefox), not when beeing directly executed using java.exe or using the appletviewer.
I've tried removing BufferedInputStream - same result.
Can anyone help? Thanks.
[1635 byte] By [
droida38a] at [2007-11-26 20:04:23]
# 2
> when the code is running as an appletIs it a signed applet?As a general rule of thumb, you should use methods specifically tailored for the class, which is, in this case, read(byte[] b, int off, int len).
hiwaa at 2007-7-9 23:04:38 >
# 3
Why do you say that? There's nothing wrong with the code that I can see. The important thing with these copying loops is to use write(byte[], offset, len) rather than just write(byte[]), but as for that read method you cite, I've rarely had a use for it in 10 years of Java.
ejpa at 2007-7-9 23:04:38 >
# 5
It is indeed. This rationale is meaningless, and the grounds for any 'uncertainty' about an API which has been in use for ten or more years are getting pretty slim by now.
InputStream.read( byte[]) is specified to call InputStream.read(byte[], offset, length), which in turn is overridden by BufferedInputStream.
So the nett effect of your recommendation as against mine is zero, except that you are recommendng a more complicated calling sequence with three parameters instead of one, for no better reason than alleged 'uncertainty'.
There is no need here to specify offset and length.
Occam's razor applies here, also K.I.S.S.
ejpa at 2007-7-9 23:04:38 >
# 7
But if you want to assert a hitherto unknown 'general rule of thumb', it's up to you to prove it, not anyone else to disprove it, and you need much better reasons than 'urban legend or superstitional peace-of-mind ... a bit of uncertainty'. You need facts and reasons and rational arguments.
Fear/uncertainty/doubt don't count.
ejpa at 2007-7-9 23:04:38 >
