Weaving and generics

[Rubén Barroso]

Hi,

I have the following interface that I plan to use as simple version of a Future:

interface Response<T> {

  T get() throws Pausable;

}

A dummy implementation just returns a specific object:

class ResponseImpl<T> implements Response<T> {

   private final T instance;

   public ResponseImpl(T instance) {

     this.instance = instance;

   }

   @Override

   public T get() throws Pausable {

     return instance;

   }

}

This is a call site to the get() method:

Response<String> response ... // I have a reference to a response

String str = response.get();

After all classes are woven, when I run the code above, I get the following error at such call site:

java.lang.NoSuchMethodError: test.Response.get()Ljava/lang/Object;

...

Can anyone shed some light on this?

-Ruben

[Sriram Srinivasan]

Oops. This is a regression.

There seems to be a problem weaving a simple implementation through an interface. Using just ResponseImpl works correctly. I'll look into it.

--sriram

> --
> You received this message because you are subscribed to the Google Groups "kilimthreads" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kilimthreads...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Sriram Srinivasan]

Fixed.




-----------------
Details if you are interested ...

A method declaration of the form
void get() throws Pausable { ... implementation ....}

gets turned into two versions for a class
void get() throws Pausable { throw "class not woven" }
void get(Fiber) throws Pausable { ... woven implementation .... }

But for an interface, only the second one was being generated. I forget the reason why I explicitly did not generate a method with the original signature.

------------------

On Nov 27, 2013, at 10:36 PM, Rubén Barroso <rube...@gmail.com> wrote:

[Jason Pell]

pretty sure that particular 'feature' or 'regression' has been there for years.

I remember trying to use an interface with a throws Pausable and got that error probably 3 years ago.

Did not realise it was bug, thought it was feature, now I can go back and see what hack I introduced to work around it.

[Sriram Srinivasan]

You are right, that it has always been there, in spite of tests around to check for it. And it had nothing to do with generics. There were even tests for it, but the bug wasn't caught due to a horrible reason: depended on the order in which the files were woven.

--------------------------------------
Yawn-inducing details follow.

Consider:

interface Response {
String get() throws Pausable
}

and a code that uses it:

class Foo {
Response resp ..
resp.get();
}

Now, if the weaver tackles Foo first, it looks at the invocation of resp.get(), determines from the signature that Response.get() is Pausable, and everything works as expected.

But if Response is woven first, the method gets an extra Fiber method.
interface Response {
String get(Fiber)
}

Now when Foo() is woven, the weaver looks for Response.get(), but only has access to Response.get(Fiber). It determines erroneously that the method is not pausable.

[Rubén Barroso]

Sriram - the fix works perfectly. Thank you guys for your prompt response!

[Jason Pell]

I released a kilim 1.0.4 to my maven repo if anyone requires it

http://pellcorp.github.io/maven2/releases/