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
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:01 EDT