Re: Method.equals()

[Brian Jones]

Mark Wielaard <address@hidden> writes:

> Hi,
> 
> On Sat, 2002-03-02 at 16:04, Mark Wielaard wrote:
> > There is now also a corresponding Mauve test case. Although I have been
> > unable to test it because for some reason my Orp doesn't like the CVS
> > Classpath anymore :(
> 
> OK, found it. The refactoring of Class was to blame.
> The following patch (which reverts that patch to rev 1.8) makes
> Classpath work again with Orp 1.0.9:
> 
> Index: vm/reference/java/lang/Class.java
> ===================================================================
> RCS file: /cvsroot/classpath/classpath/vm/reference/java/lang/Class.java,v
> retrieving revision 1.19
> diff -u -r1.19 Class.java
> --- vm/reference/java/lang/Class.java 23 Feb 2002 09:19:52 -0000      1.19
> +++ vm/reference/java/lang/Class.java 3 Mar 2002 14:03:14 -0000
> @@ -136,11 +136,15 @@
>     * @throws ExceptionInInitializerError if the class loads, but an exception
>     *         occurs during initialization
>     */
> -  public static Class forName(String name) throws ClassNotFoundException
> +  //XXX This does not need to be native.
> +  public static native Class forName(String name)
> +    throws ClassNotFoundException;
> +  /*
>    {
>      return forName(name, true,
>                     VMSecurityManager.getClassContext()[1].getClassLoader());
>    }
> +  */
>  
>    /**
>     * Use the specified classloader to load and link a class. If the loader
> 
> Have not yet investigated why. But with this I could at least check
> the Method.equals() changes with mauve (it really fixes the test case
> I added, yeah!)

Mark & Michal,

Should we open a bug on ORP for this in Sourceforge?  This seems like
a VM dependent layer change that should be documented if it has the
potential of breaking a VM.

Brian
-- 
Brian Jones <address@hidden>