webstart has always had a user-experience problem with lazily download jar files that they don’t want to deal with. This is easily demonstrated by turning on the trace logging.
· Turn on trace logging in the deployment.properties file
· Clear the webstart cache
· Click on a JNLP link to start an application with jars that are designated as LAZY.
The webstart splash will show while the “eager” files are downloaded. Then the application starts, and after that the “lazy” jar files (seems like all of them…whether they are going to be used or not) are then downloaded. This can easily be detected by watching the console. However, there is no end-user user feedback that these downloads are occurring…the application just stops. There is no easy way for an application developer to detect that this is happening to provide that feedback either.
check the RFEs: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6575167
This one shows that it was fixed, but don’t really see any changes.
A general DownloadListener still cannot be added, only by downloading a part explicitly can a listener be added. This puts application developers in the position where either we need to manage the resources manually, let the application kind of hang which this occurs in the background, or set all the jar files as “eager”.
· Turn on trace logging in the deployment.properties file
· Clear the webstart cache
· Click on a JNLP link to start an application with jars that are designated as LAZY.
The webstart splash will show while the “eager” files are downloaded. Then the application starts, and after that the “lazy” jar files (seems like all of them…whether they are going to be used or not) are then downloaded. This can easily be detected by watching the console. However, there is no end-user user feedback that these downloads are occurring…the application just stops. There is no easy way for an application developer to detect that this is happening to provide that feedback either.
check the RFEs: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6575167
This one shows that it was fixed, but don’t really see any changes.
A general DownloadListener still cannot be added, only by downloading a part explicitly can a listener be added. This puts application developers in the position where either we need to manage the resources manually, let the application kind of hang which this occurs in the background, or set all the jar files as “eager”.
- duplicates
-
JDK-6945639 Custom progress: ability to tune progress appearance from the web page
-
- Resolved
-
- relates to
-
JDK-6575167 DownloadServiceListener RFE for webstart
-
- Closed
-