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

Optional package handling inconsistent

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: P4 P4
    • None
    • 1.4.1
    • core-libs



      Name: gm110360 Date: 11/18/2003


      FULL PRODUCT VERSION :
      java version "1.4.1_01"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
      Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

      FULL OPERATING SYSTEM VERSION :
      SunOS starbase 5.8 Generic_108528-06 sun4u sparc
      SUNW,Ultra-60 (although why you need my node name (implied
      by -a) is odd.

      ADDITIONAL OPERATING SYSTEMS :
      Windows XP

      A DESCRIPTION OF THE PROBLEM :
      Optional packages are confounded by inconsistent handling
      between installed optional packages when used by an
      application versus those used by an applet.

      If you're an application, installed optional packages are
      any JAR file found in the java.ext.dirs directories.

      If you're an applet, installed optional packages are any
      JAR file *that ends in .zip or .jar* referenced in your
      manifest.

      You may say, well who wouldn't have a JAR file in (1) that
      doesn't end in .zip or .jar? The answer: MANY PEOPLE. A
      common idiom in debugging and system administration is to
      disable a suspect module by renaming only the "extension"
      part of the file name, ie: suspect.jar becomes suspect.off
      or suspect.jar.off. C.f. bug 4331896.

      But, as the spec says, a JAR file is any file regardless
      of name. After all, even if 99% of the Java installations
      are on filesystems that support arbirtrary names, even
      those whose last for characters are ".jar", we've got to
      support that last 1% of Java installations that don't
      support so-called "extensions" in filenames, silly though
      those users may be.

      But, if that's the case, why is there a fix to bug
      #4502051? ExtensionDependency and JarFilter made it into
      the Merlin release specifically to support the common
      idiom (99%?) of "extensions" in filenames.

      While the larger issue is that Sun is causing man-years of
      lost productivity by looking in jre/lib/ext for any file
      instead of jre/lib/ext/*.jar, the issue HERE is that the
      refusal to fix 4331896 and the fix to 4502051 are
      inconsistent, and that itself is a bug.

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      public class Hide {
        public static String seek() { return "Found me!"; }
      }

      public class Seek {
        public static void main() {
          System.out.println(Hide.seek());
        }
      }

      Put Hide.class into hide.jar; put hide.jar into
      jre/lib/ext. Run Seek. Note output. Rename hide.jar to
      hide.off. Run Seek. Note identical output, instead of
      ClassNotFoundException.

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      Expected: ClassNotFoundException.

      Actual: Found me!

      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      See "Steps to Reproduce".
      ---------- END SOURCE ----------
      (Incident Review ID: 179237)
      ======================================================================

            mchung Mandy Chung (Inactive)
            gmanwanisunw Girish Manwani (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: