-
Bug
-
Resolution: Fixed
-
P2
-
5.0
-
b42
-
x86
-
windows_xp
When a file is downloaded through HTTP/HTTPS/FTP, it would normally through URLConnection.getInputStream(). In the current J2RE implementation, the InputStream would be wrapped by sun.net.www.MeteredStream in most cases in HTTP/HTTPS/FTP before it is returned from URLConnection.getInputStream() method.
sun.net.www.MeteredStream is basically a filtered stream for tracking progress of how far a stream has been read, and it would call sun.net.ProgressData for every read() call to report its latest progress. This is unnnecessary performance penalty for most developers because:
- sun.net.ProgressData was used by HotJava years ago and it is no longer in use.
- For every read() call in sun.net.www.MeteredStream, sun.net.ProgressData is called. If developers do not wrap the stream with a buffered stream, the number of read() will be very high thus generating many unnecessary notification.
- sun.net.ProgressData extends from java.util.Observable, thus every notification also trigger execution of the Observable logics which is totally necessary in this case.
Since HotJava has been EOLed, there is no reason why every Java programs need to pay the performance penalty for the MeteredStream if they are not interested in progress monitoring. Also, the ProgressData class is already half-broken due to various changes in HttpClient in recent years; although some developers may still be interested in doing progress monitoing, the implementation needs a major update in order to be useful again. Because of these reasons, the progress monitoring code should be updated to make it functional again, and we should disable the monitoring support by default for performance reason.
This bug is in the JRE since the early days of Java, and it is applicable on all platforms. This bug seriously affects the startup time and runtime performance of any networked applications. On the client side, it significantly affects the performance of Java Plug-in and Java Web Start because the applications use many input streams from URLConnection.getInputStream() directly (direct call) and indirectly (through classloading).
###@###.### 2004-02-13
###@###.### 2004-03-09
sun.net.www.MeteredStream is basically a filtered stream for tracking progress of how far a stream has been read, and it would call sun.net.ProgressData for every read() call to report its latest progress. This is unnnecessary performance penalty for most developers because:
- sun.net.ProgressData was used by HotJava years ago and it is no longer in use.
- For every read() call in sun.net.www.MeteredStream, sun.net.ProgressData is called. If developers do not wrap the stream with a buffered stream, the number of read() will be very high thus generating many unnecessary notification.
- sun.net.ProgressData extends from java.util.Observable, thus every notification also trigger execution of the Observable logics which is totally necessary in this case.
Since HotJava has been EOLed, there is no reason why every Java programs need to pay the performance penalty for the MeteredStream if they are not interested in progress monitoring. Also, the ProgressData class is already half-broken due to various changes in HttpClient in recent years; although some developers may still be interested in doing progress monitoing, the implementation needs a major update in order to be useful again. Because of these reasons, the progress monitoring code should be updated to make it functional again, and we should disable the monitoring support by default for performance reason.
This bug is in the JRE since the early days of Java, and it is applicable on all platforms. This bug seriously affects the startup time and runtime performance of any networked applications. On the client side, it significantly affects the performance of Java Plug-in and Java Web Start because the applications use many input streams from URLConnection.getInputStream() directly (direct call) and indirectly (through classloading).
###@###.### 2004-02-13
###@###.### 2004-03-09