JDK-8033472 : Webstart has a UI problem with lazily download jar files
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 7u60
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: windows_7
  • CPU: x86
  • Submitted: 2014-02-03
  • Updated: 2014-07-30
  • Resolved: 2014-02-05
Related Reports
Duplicate :  
Relates :  
Description
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���.

 
Comments
duplicate of JDK-6945639
05-02-2014

this is already implemented as https://bugs.openjdk.java.net/browse/JDK-6945639 you can designate a progress class, implementing a defined interface, and be in complete control of progress display for both eager and lazy resources. The suggest implementation in this request is different, and was considered, but rejected for various reasons in favor of the implementation done in 6945639. This should be closed as will not fix, or dupe of 6945639
05-02-2014