Class.forName() bug?

Robert S. Thau rst at ai.mit.edu
Mon Mar 31 15:32:44 PST 1997


  The JDK 1.1 API docs say:

  public static Class forName(String className) throws ClassNotFoundException
        Returns the Class object associated with the class with the given
        String name. Given the fully-qualified name for a class or interface,
        this method attempts to locate, load and link the class.

  Note that forName is not supposed to initialize the class.

But it is supposed to link it, and if I'm reading the code correctly,
Kaffe currently doesn't do that either.  (The stock Class_forName
native method just calls loadClass, not prepareClass or linkClass).

More to the point, it looks to me like the Sun docs may be implicitly
in conflict with themselves regarding this matter --- the JDK 1.1.1
API spec for the class java.sql.Driver does say...

  When a Driver class is loaded, it should create an instance of
  itself and register it with the DriverManager. This means that a
  user can load and register a driver by doing
  Class.forName("foo.bah.Driver").
  
...and I'm not sure how code for the foo.bah.Driver class can "create
an instance of itself and register it..." when "load[ed]" by
Class.forName unless the class gets initialized at that point (and, in
particular, its static initializers get run) --- especially since
creating an instance before the class has been initialized would leave
the VM containing live instances of, well, a class which hasn't been
initialized.  (This does assume a fairly loose use of the word "load"
in the passage above, but as I said, I don't see any other way to make
sense of it).

  If Sun's implementation of forName initializes
  the class, then their implementation does not match their specification,
  and we should complain.

I checked the Solaris JDK 1.0, and it does.  (Same five-line test case
as included in the earlier report).  

FWIW, it's probably fair for any complaint to point out that their own
recommended practices for use of JDBC seem to depend on the current
behavior of the JDK VM, and get broken by implementations which stick
to the spec.  It's certainly possible to interpret this as an
editorial error in documentation for java.lang.Class (leaving out the
word "initialize"), particularly given the loose usage of words like
"load" elsewhere...

rst



More information about the kaffe mailing list