Re: Class.newInstance always locates default constructor (fwd)

Date view Thread view Subject view Author view

From: Godmar Back (gback@cs.utah.edu)
Date: Thu Oct 29 1998 - 01:59:56 EST


 I put in a fix for the constructor problem Alexandre pointed out.

This fix has two immediate consequences for VM code/native libs:

a) the presence of no-args constructors can no longer be assumed.
   (Since they're no longer falsely inherited from Object).
   This broke Float.c and Double.c, fortunately, both had constructors
   I could use for the purpose, so no changes to Java code were
   necessery.
   It also broke ZipEntry.java ZipEntry.java does have a (String mn)
   constructor that could probably be used instead; however, I wasn't
   sure and so I just added a no-arg constructor for internal use.
   (This way it'll work exactly the same way it worked before.)

b) the existence of constructors of superclasses that take a String
   arg but are not declared in a class can no longer be assumed,
   because they're also no longer falsely inherited.
   This was the case with ThreadDeath, which was used in SignalError,
   which requires a String-taking constructor. For convenience and to
   be able to keep using SignalError, I added such a constructor to
   ThreadDeath.

Note that you must have a new Klasses.jar and that the new vm code
won't run with the old one to compile a new one. I also added
Alexandre's testcase.

I am convinced that more stuff is broken that the tests did not
pick up. Basically, look for NoSuchMethodException: <init> message
when you run your code, and fix the appropriate code.

        - Godmar


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:01 EDT