JBossDeveloper

> Can we instrument system classes, e.g. in the
> java.lang package ? For example arrays ? I'm thinking
> of the follwing case:
>
> Person:
> String name;
> int age;
> String[] hobbies;
>
>
> I want to know when somebody does
> p.getHobbies()[0]="bla";

I see, yes you want to transparently instrument access to the variable with System types.

What I heard from Bill is that you can already mark the access code with "instrument" so that field access is intrumented in the calling class. The solution is close to what timfox describes for constructors.

What ELI is saying is that static analysis of the bytecode coming in tells you that information (or does it?) and we got CPUs for something right ?


>
> Is this possible ?
> Bela

Marc-

> I thought that in JDK1.4 you could specify your own
> system classloader for the VM. That let's you use
> specific classloaders for system classes and bypass
> the chicken and egg problem.

Unfortunately when Sun refers to "system classloader" they actually mean the classloader that is used to load the main() class of your app.
This is the one you can replace.
The "system" classes (ie those that start with java.*) need to be loaded with the "bootstrap loader" which you can't replace AFAICT. (Check out defineClass method in ClassLoader.java in JDK source).
If you attempt to load a system class with the non-bootstrap classloader I believe it will go splat.
So IMO (as previously mentioned) if you want to instrument the system classes you need to change all the code that references the system classes AT ALL, on load to instead reference wrappers for the system classes, which are actually in your jboss.aop package (or whatever).
These classes could be auto generated from the system classes, and would basically delegate calls to the wrapped member which is the real system class.
(You couldn't just extend the classes because of final methods/classes).
So it sounds maybe possible but quite involved. You'd also have to watch out for hardcoded refs to system classes in the code.

> Unfortunately when Sun refers to "system classloader"
> they actually mean the classloader that is used to
> load the main() class of your app.

I see... so that is out.

> So IMO (as previously mentioned) if you want to
> instrument the system classes you need to change all
> the code that references the system classes AT ALL,
> on load to instead reference wrappers for the system
> classes, which are actually in your jboss.aop package
> (or whatever).

Eli came by the office this morning and was explaining that it is what they did for JOrchestra, that they created wrappers for the System Classes statically and that they can instrument that.

> These classes could be auto generated from the system
> classes, and would basically delegate calls to the
> wrapped member which is the real system class.
> (You couldn't just extend the classes because of
> final methods/classes).
> So it sounds maybe possible but quite involved. You'd
> also have to watch out for hardcoded refs to system
> classes in the code.

yeah... hmmmm. It seems to me that instrumenting the String and Array like bela points out is an important feature for the automated cache replication.

This is one for static analysis of callers. I hear that Eli has that code already so maybe it is the way.

It is starting to sound complicated, I don't like complicated stuff.

Bottom line: instrumenting our classes/application classes is easy, instrumenting System Classes is a bitch...