If you have a profiler, you should use it to measure where your code is
spending all your time. However, from a quick glance, my guess is that the
slowestp art is string concatenation. Use a StringBuilder instead:

URL url = new URL(fileName);
URLConnection conn = url.openConnection();
conn.setRequestProperty("Cookie", myCookieCode);
conn.connect();
BufferedReader dis = new BufferedReader(new
InputStreamReader(conn.getInputStream()));
StringBuilder tempHtmlCode = new StringBuilder();
do {
 String inputLine = dis.readLine();
 tempHtmlCode.append(inputLine);
} while (inputLine != null)
htmlCode = tempHtmlCode.toString();

   - Oliver

In general the buffering should be immediately around the lowest-level stream
(the one that does real IO).  There may be circumstances where you need
buffering at outer levels too, but that's not so common.

   Reader reader = new InputStreamReader(
                               new BufferedInputStream(
                                       conn.getInputStream()));

BTW, /don't/ forget about the character encoding -- in this context it is very
unlikely to be an issue you can safely ignore.

   -- chris

While I agree with Oliver that your String concatenation code is pretty
inefficient, I wouldn't think it could cause that kinds of delays
(unless the number of lines was very very large).

One probable cause ( a guess really) is that the HttpUrlConnection
class tries to keep the connection open in anticipation of futher
traffic to the same URL, and so the reader returning null (indicating
the end of output) is delayed till the connection is eventually
dropped. Browsers on the other hand would keep the connection open, but
would look at headers to see the length of the expected response, and
terminate the read when the expecteed number of bytes were received.

I suggest that you try out another client (like say jakarta's
HttpClient) , and see if it helps. Sun's implementation had quite afew
issues like this in the past - and was really never meant to be
full-fledged HttpClient - but rather a simplistic mechanism for loading
Jar files from a remote source.

BK