-
Bug
-
Resolution: Won't Fix
-
P4
-
None
-
1.4.1
-
sparc
-
solaris_8
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)
======================================================================
- relates to
-
JDK-4502051 non jar files in lib/ext cause exceptions to be thrown
-
- Closed
-
-
JDK-4331896 Extensions mechanism loads non-jar files too!
-
- Closed
-