Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7108169

Lazily downloaded jar files do not work any more


    • Subcomponent:
    • Introduced In Version:
    • Resolved In Build:
    • CPU:
    • OS:
    • Verification:
      Not verified



        J2SE Version (please include all output from java -version flag):

        Does this problem occur on J2SE 1.4.x, 1.5 or 6? Yes / No (pick one)

        Operating System Configuration Information (be specific):
        Windows Vista Business SP2

        Hardware Configuration Information (be specific):
        HP Pavillion dv9000
        Windows Vista Business SP2 32 bit
        3 GB RAM
        Intel Core 2 Duo T9300

        Bug Description:
        Bug#7092324 is fixed, but now there is a problem that is equally as significant…
        lazily downloaded jar files do not work.

        With a clean cache, application starts, but it doesn’t seem like any of
        lazily downloaded jar files are transferred. Then, next time the app is run,
        it tries to validate these and the validation fails.

        Unerstand that jar files marked as lazy may not be downloaded, but the log shows
        that they are.The log files for both failed runs were attached

        Steps to Reproduce (be specific):

        During the first run (again, in the logs) every lazily downloaded jar file
        is followed by: (There are about 100 of these exceptions in the log file)

        java.util.zip.ZipException: error in opening zip file
                        at java.util.zip.ZipFile.open(Native Method)
                        at java.util.zip.ZipFile.<init>(Unknown Source)
                        at java.util.zip.ZipFile.<init>(Unknown Source)
                        at java.util.jar.JarFile.<init>(Unknown ! Source)
                        at java.util.jar.JarFile.<init>(Unknown Source)
                        at com.sun.deploy.cache.CachedJarFile.<init>(Unknown Source)
                        at com.sun.deploy.cache.CacheEntry$4.run(Unknown Source)
                        at roller.doPrivileged(Native Method)
                        at com.sun.deploy.cache.CacheEntry.getJarFile(Unknown Source)
                        at com.sun.deploy.net.DownloadEngine.getCachedJarFile(Unknown Source)
                        at com.sun.deploy.net.DownloadEngine.getUpdatedJarFile(Unknown Source)
                        at com.sun.jnlp.JNLPClassLoader$2.run(Unknown Source)
                        at java.security.AccessController.doPrivileged(Native Method)
                        at com.sun.jnlp.JNLPClassLoader.getJarFile(Unknown Source)
                        at com.sun.jnlp.JNLPCachedJarURLConnection.connect(Unknown Source)

        Do two more test runs to create more log files and attached them.
        The second run failure with the lazy downloading is just confusing
        the issue and is probably not relevant as it is likely caused by
        the errors on the initial run. So let’s forget about this for now
        and just compare and the functional case.

        Log file explanation

        ·Using Lazily downloaded jar files
          o log.lazy.zip
          o 48.batik-all.jar.lazy.zip
            (is the cache directory containing the downloaded
             cache entry for the batik-all.jar file (I determined this from the logs)

        ·Using Eagerly downloaded jar files
          o log.eager.zip are the log files
          o 48.batik-all.jar.eager.zip

        It is easily seen that the size of the cache entry for this file is drastically
        different in both cases. It seems that all the lazily downloaded jar files
        are corrupted, which is why my application throws a bunch of

        This error seems like something that they could easily reproduce.
        Creating a test case is difficult for this because it i ation of
        their internal resources that I cannot control. If they
        are having trouble reproducing it, I would be happy to discuss
        the differences in our configurations and work through producing
        a test case that is valid in both of our environments.


            Issue Links



                • Assignee:
                  nam Nam Nguyen (Inactive)
                  tyao Ting-Yun Ingrid Yao (Inactive)
                • Votes:
                  0 Vote for this issue
                  0 Start watching this issue


                  • Created: