Re: [javaflow] a problem in ResourceTransformer abstraction

[Torsten Curdt]

I found a problem in the current ResourceTransformer abstraction.



  // note that in bytecode, type of local
  // variables aren't available
  var x;

  if(...) {
    x = new Foo();
  } else {
    x = new Bar();
  }

  someMethodCall();

  if(...) {
    new Thread(x);
  } else {
    new TreeSet(x);
  }

Sometimes, a proper instrumentation of a class requires information about other classes. Consider the following code: Proper stack frame restoration at "someMethodCall" requires an identification of the common base class between Foo and Bar (so that an object of the right type will be set to local variable 'x'), which in turns requires information about Foo and Bar.

Hmmm.... so we imply that x must be the common base of Foo and Bar, right?

  interface ClassImageLoader {
    byte[] load(String className);
  }

... and change ResourceTransformer as follows:

  interface ResourceTransformer {
    byte[] transform(String className, ClassImageLoader loader);
  }

Can I make this change?

The current ResourceTransformer just takes the class file image to be transformed, and therefore a ResourceTransformer implementation is supposed to magically resolve Foo and Bar to the right class file --- which is impossible. This is breaking my workflow engine that uses multiple class loaders (where 'Foo' may resolve to different symbols, depending on the context.) So I suggest we introduce a mechanism to resolve symbols to their class files:

Hmmm.... can you elaborate a bit more. (I am currently in the middle
of moving so don't have much time to dig into it myself)

If possible I would really keep the ResourceTransformer interface
as simple as possible!

So you want to find the base class from the "ClassImageLoader"?

P.S. Also how stable is the ASM implementation? Should we concentrate our effort on that side going forward?

Yes, I would rather like to concentrate on the ASM implementation.
...they have a great and vital community around ASM ...or what do
you think?

cheers
--
Torsten

PGP.sig
Description: This is a digitally signed message part