Re: [cp-patches] [generics] RFC : implementation of jjava.lang.instrument package

[Mark Wielaard]

Hi Nicolas,

On Thu, 2005-12-01 at 17:51 +0100, Nicolas Geoffray wrote:
> >Also if something went wrong with the transformation
> >of any of them we might want to have a cancelRedefineClass() to let
> the
> >VM know we won't be applying any prepared classes.
> >
> I had in mind that the VM wouldn't need a cancel method. The
> prepareRedefineClass gives a vm internal representation
> of a class, and if redefinition is canceled this representation would
> be garbage collected and forgotten by the vm. But maybe some vm
> would like to be noticed. I added the method since it might be
> usefull.

My idea was even that a VM might only want to have one redefine
prepare/apply cycle running at the same time. Then it can easily cleanup
anything not used. But this might be optimizing for an unusual case. We
can probably assume that transformers will actually transform correctly.

> >Why does the private callTransformers() implementation take a
> >ProtectionDomain? Isn't that
> classBeingRedefined.getProtectionDomain()?
> >
> Yes, but the classBeingRedefined might be null, if the method is
> called
> by the vm from the native ClassLoader.defineClass method. Therefore,
> the vm gives as arguments the protectionDomain it has.

Aha. Sorry I missed the dual nature of the
ClassFileTransFormer.transform() method. I see you documented this in
your original patch. In that case I really do think we should move these
to vm/reference/java/lang and make this method package private.

> >Normally we like to provide some default/noop implementation for the
> VM
> >reference classes. Is it possible to provide the necessary hooks in
> >ClassLoader/VMClassLoader to call the transformers just before
> >defineClass() is called? 
> >
> It's possible, but it could break all existing vms lying on the vm 
> reference classes.
> The VMClassLoader would need an extra defineClass method and an extra
> field
> for an InstrumentationImpl object. The extra defineClass method would 
> check if the
> InstrumentationImpl is null and if not, call the 
> InstrumentationImpl.callTransformers
> method.

Right, I see we need to break the VM interface for this :{
Probably best not to do that for the first release (0.20) but lets
suggest how we would like to change the interface for 0.21 so runtime
implementers can prepare and scream about it. On the other hand this is
the generics branch only, not very many VMs depend on it yet. But not
very urgent I guess before we have this working with at least one VM.

> Yeah, documentation to write! :). I will create a documentation file
> for the java.lang.instrument package,
> and change the vm integration guide (should I create a new paragraph
> for generics?)

Just make a new paragraph for Instrumentation. Then mention that it
currently only is on the generics branch since it uses some new language
features.

Cheers,

Mark