classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Eclipse 3.0


From: Robert Lougher
Subject: Re: Eclipse 3.0
Date: Mon, 5 Jul 2004 13:08:26 +0100

Hi,

On Sun, 04 Jul 2004 14:35:38 +0200, Mark Wielaard <address@hidden> wrote:
 
> Found the bug in jamvm. This happens when the interface method
> in question is one of the Object methods hashCode(), equals(),
> toString(), etc. and (re)defined in one of the super interfaces of the
> interface on which the actual method is called.
> 

It occurs because resolution of the interface method finds it on
Object before it finds it on the super-interface.  I forgot about this
case when implementing interface method tables -- Object isn't an
interface and so isn't contained in the classes' itable (hence
unimplemented interface).

> The attached patch was the quickest way I could think of to work around
> it. Apply against jamvm 1.1.4. Robert will surely yell and scream if
> this is horribly wrong and provide a nice clean solution I am sure :)
> 

OK, I'm yelling :)  Please don't use Mark's patch!

It "fixes" it by stopping resolution finding the method on Object. 
However, it is legal to have an invokeinterface on an Object method
(as all interfaces subclass Object).

Instead, please use the attached patch to the interpreter.  This
converts an invokeinterface on an Object method into an invokevirtual
(which is what 1.4 javac does anyway, but not jikes or 1.3 javac).

> > Then I finally get:
> >
> > java.lang.NoClassDefFoundError: org/eclipse/swt/custom/CTabFolder
> >    at org.eclipse.ui.internal.presentations.PaneFolder.<init>
> > (PaneFolder.java:197)
> >
> > Which doesn't make sense :{
> 
> Correct! It doesn't make sense. Jamvm isn't that good at handling out of
> memory situations and Eclipse demands lots and lots of memory. So apply
> the attached patch to jamvm. Update your GNU Classpath from CVS (it now
> contains all Anthony his URL patches). Follow the rest of the
> instructions above, but now start it with a little bit more memory like:
> 

JamVM's OOM handling is generally very good :)  This strange result
happens because OutOfMemory was thrown during class-loading (loadClass
called on class loader).  I convert it into NoClassDefFoundError
(loadClass throws ClassNotFound).  In this case I should leave it as
OOM.

Anyway, thanks to Mark for highlighting this bug and proving that
JamVM can run Eclipse 3.0!

Rob.

Attachment: interp.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]