Some possible changes for defining yield methods.

[mikeb01]

Hi,

I am currently looking into using Yielder to implement a simple micro-
process framework (http://kamaelia.sourceforge.net/MiniAxon/). One of
the problems I am having at the moment is that any class that I want
to have a yield method in must be a direct sub-class of Yielder. This
is proving awkward as I would like to have a deeper hierarchy (Yielder-
>Microprocess->Component->CustomComponent) and require that the yield
method be implemented by the CustomComponent.

One possibility is to add support for annotating a yield method and
creating a static yieldReturn Method. I.e. the code would then look
like:

public class Foo {

@Yeildable
public int next() {
int i = 0;
while (true) {
Yielder.yieldReturn(i++);
}
}
}

I am going to have a go at implementing this.

Mike.

[aviad.in...@gmail.com]

Enjoy your try. But how will you implement the Iterator?

And a different approach, maybe: The restriction for the direct sub-
classing only comes from YieldChecker class. A more thorough check
could be made there to find out if the class is a sub-class of Yield
at any level, and if so manipulate it. That might make it easier, and
more intuitive too (in my opinion, annotations are going to make it
less intuitive together with annonymous classes).

What do you think?

[aviad.in...@gmail.com]

To make it into code, that's what I mean:
{{{
public static boolean isYielderInHierarchyTree(String className) {
try {
return
Class.forName(className).isAssignableFrom(Yielder.class);
} catch (ClassNotFoundException e) {
return false;
}
}
}}}

And then, YielderChecker calls this utility method (located in the
Util class) with the superName parameter.

[mikeb01]

You're right about the iterator bit. My previous suggestion won't
work. Determining whether the class is a Yielder from the full
hierarchy is probably the write approach, but I haven't found an easy
way to see the full hierarchy via asm. Using isAssignableFrom doesn't
work either as you can't call any methods on the Class object because
that class has not loaded yet (it just throws ClassNotFoundException
every time). I am open to any other implementation suggestions.

I have implemented a quick solution which just puts an @Yieldable
annotation on the subclass and the agent checks for both the
superclass and the annotation. Not elegant but works for the moment.

Mike.

[aviad.in...@gmail.com]

I haven't tried my suggestion even though I checked it into the trunk
for the moment..

It should work though! The class wasn't classloaded but maybe it needs
some fine-tuning, such as making sure the Yielder class is always not
manipulated (easy to do, just check the className parameter), the
direct sub-class of Yielder will be manipulated (easy to check,
compare superName to Yielder.class.getName()) and any other sub-class
could go up the hierarchy - the Yielder and direct sub-classes should
load properly.

This is theoretical, but from my understanding of class loading it
should work this way... Shouldn't it?

[mikeb01]

I tried it and all I got was ClassNotFoundException when I called
Class.forName(className). My understanding is that the class
transformer is called before the class is loaded. Therefore the JVM
does not know about the class represented by the string className.

Mike.

[aviad.in...@gmail.com]

But did you call the method with the superName as the parameter?

[mikeb01]

Okay, I was calling with the className and not the superName. This
seems to work (using superName):

public static boolean isYielderInHierarchy(String className) {
String name = className.replace('/', '.');
try {
return Yielder.class.isAssignableFrom(Class.forName(name));
} catch (ClassNotFoundException e) {
e.printStackTrace();
return false;
}
}

Mike.

[aviad.in...@gmail.com]

Whoops I forgot the replacement of slashes!

Okay, I'll check in the changes with some JUnits to test it.

[aviad.in...@gmail.com]

Made the change. Check it out and let me know if it works for you.