This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Parameterizing on incomplete types


On Dec 1, 2011, at 4:28 PM, Per Bothner wrote:

On 12/01/2011 01:21 PM, Jamison Hope wrote:
It probably makes sense to generate the bridge methods at the same
time as we check for missing implementations.

Where are they generated now?

My point is: they're not. That needs to be implemented.

At all? I thought you meant they weren't being generated here as a result
of you commenting out the relevant part of ClassExp or because they don't
yet work with this circular parameterization nonsense.


I just meant for the regular (non-parameterized) case. For instance,
when javac compiles:

// A.java
public class A
{
  public A get() { return null; }
}

// B.java
public class B extends A
{
  public B get() { return null; }
}

B.class ends up with an extra method:


Compiled from "B.java"

public class B extends A{
    public B();
    public B get();
    public A get();
}

The third method is marked SYNTHETIC|PUBLIC|BRIDGE (0x1041) and its implementation is

aload_0
invokevirtual 2   // call public B get()
areturn

and it exists so that B actually overrides A's get() method with an
identical signature.


But it turns out that when Kawa compiles the Scheme equivalent,


(define-simple-class A ()
  ((get) ::A #!null))

(define-simple-class B (A)
  ((get) ::B #!null))

B.class doesn't get the extra method:


Compiled from "bridge.scm"
public class bridge.B extends bridge.A{
    public bridge.B get();
    public bridge.B();
}


But maybe that's not what you're referring to as a bridge method. I can't
find any instance of the word "bridge" or 0x0040 as anything but ACC_VOLATILE
in the JVM spec.



Is that what the recursive call to
ClassExp#getImplMethods() is doing?

No, that just searches for possible implementation methods. This is done for each abstract method.

The key parts of the logic is:

           methods = compiledType.getAbstractMethods();
           nmethods = methods.length;
       ...
	for (int i = 0;  i < nmethods;  i++)
	  {
	    Method meth = methods[i];
           ...
           Vector vec = new Vector();
	    getImplMethods(compiledType, mname, ptypes, vec);
           if (vec.size() != 1)
	        error(...)

This logic needs to be made aware of parameterized types.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

-- Jamison Hope The PTR Group www.theptrgroup.com




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]