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

Running jnlp causes npe when Java cache disabled

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P3 P3
    • None
    • 6u10
    • deploy
    • x86
    • windows_xp

      FULL PRODUCT VERSION :
      java version "1.6.0_19"
      Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
      Java HotSpot(TM) Client VM (build 16.2-b04, mixed mode, sharing)


      ADDITIONAL OS VERSION INFORMATION :
      Microsoft Windows XP [version: 5.1.2600]
      ( Hungarian version )

      A DESCRIPTION OF THE PROBLEM :
      Running a jnlp application causes a NullPointerException when the latest Java update installed (1.6.0_19) and the Java cache was turned out.
      The jnlp contains only one jar resource and it signed so the problem is not with the signing.
      The bug is possibly in the java.util.jar package but it seems that the com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar shouldn't use a com.sun.deploy.cache.DeployCacheJarAccessImpl object when the cache not used. Anyway in the java.util.jar.JarVerifier.mapSignersToCodeSource method the url parameter is null and that's why the map will be null.
      Sorry for my english.

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      - install java version "1.6.0_19" jre
      - turn off the Java caching (Keep temporary files on my computer).
      - the jnlp file must contain the security section with the all-permissions or the j2ee-application-client-permissions privileges.



      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      java.lang.NullPointerException
      at java.util.jar.JarVerifier.mapSignersToCodeSource(Unknown Source)
      at java.util.jar.JarVerifier.mapSignersToCodeSources(Unknown Source)
      at java.util.jar.JarVerifier.getCodeSources(Unknown Source)
      at java.util.jar.JarFile.getCodeSources(Unknown Source)
      at java.util.jar.JavaUtilJarAccessImpl.getCodeSources(Unknown Source)
      at com.sun.deploy.cache.DeployCacheJarAccessImpl.getCodeSources(Unknown Source)
      at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
      at com.sun.javaws.security.SigningInfo.check(Unknown Source)
      at com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(Unknown Source)
      at com.sun.javaws.LaunchDownload.checkSignedResources(Unknown Source)
      at com.sun.javaws.Launcher.prepareResources(Unknown Source)
      at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
      at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
      at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
      at com.sun.javaws.Launcher.launch(Unknown Source)
      at com.sun.javaws.Main.launchApp(Unknown Source)
      at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
      at com.sun.javaws.Main$1.run(Unknown Source)
      at java.lang.Thread.run(Unknown Source)


      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      /*
       * 1. make a GTest.jar from MainClass
       * 2. sign it with the jarsigner
       * 3. make the following jnlp to run with javaws:
       * <?xml version="1.0" encoding="UTF-8" standalone="no"?>
       * <jnlp codebase="http://www.example.hu" href="/GTest.jnlp">
       * <information>
       * <title>GTest</title>
       * <vendor>Molnar Gabor</vendor>
       * </information>
       * <security>
       * <all-permissions/>
       * </security>
       * <resources>
       * <j2se href="http://java.sun.com/products/autodl/j2se" version="1.5+"/>
       * <jar href="/GTest.jar" download="eager"/>
       * </resources>
       * <application-desc/>
       * </jnlp>
       * 4. run with javaws
       *
       */
      public class MainClass
      {
      public static void main(String[] args)
      {
      System.out.println("ItWorks");
      }
      }

      ---------- END SOURCE ----------

      CUSTOMER SUBMITTED WORKAROUND :
      Delete the security section from the jnlp file. But it only works when the application can run without the all-permissions or the j2ee-application-client-permissions privileges.

      Release Regression From : 6u17
      The above release value was the last known release where this
      bug was not reproducible. Since then there has been a regression.

            dgu Dennis Gu (Inactive)
            igor Igor Nekrestyanov (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: