This is the mail archive of the
mailing list for the Mauve project.
Re: classpath ./ChangeLog ./THANKYOU ./configure.in...
- From: Stephen Crawley <crawley at dstc dot edu dot au>
- To: Brian Jones <cbj at gnu dot org>
- Cc: Stephen Crawley <crawley at dstc dot edu dot au>, classpath at gnu dot org, "Raif S. Naffah" <raif at fl dot net dot au>, Mauve <mauve-discuss at sources dot redhat dot com>
- Date: Tue, 08 Apr 2003 02:09:01 +1000
- Subject: Re: classpath ./ChangeLog ./THANKYOU ./configure.in...
> Stephen Crawley <crawley at dstc dot edu dot au> writes:
> > I can confirm that there really is a problem running some of the Mauve
> > security testlets under the latest Kissme, Classpath and Mauve. It appears
> > to be a Kissme class loading problem, rather than the fault of the Classpath
> > security implementation. I'm trying to get to the bottom of it ...
The "bottom of it" is that the problem was not in Kissme or Classpath
The problem was that the failing test cases' constructors were not
declared public. On Kissme, this (correctly IMO) caused the call to
'Class.newInstance' to throw an InstantiationException. I have fixed
the Mauve testcases, and add a 'hint' to SimpleTestHarness to point
people in the right direction in future.
Three issues remain:
* There is a bug in the implementation of Class.getConstructor in
the Jikes RVM. It should not return a constructor unless it is
declared as 'public'.
* We need more comprehensive Mauve testcases for the the Java
APIs for reflective programming,
* There is a problem with Kissme's implementation of stack traces
when an exception is thrown in a native method. It is getting
the source line number wildly wrong.