Instrumented String class for app, and original class for agent?

[softwarepearls_com]

I've got a java.lang.instrument-compliant agent which instruments
java.lang.String. As soon as the venerable String class is modified
this way, any agent logic which uses Strings is itself triggering
instrumented code. What I'd like to have is that all of the agent's
logic can stick to the original String class, and all other logic (ie
the app running with the agent installed) uses the instrumented String
class. My guts tell me this should be possible, but I'm not seeing the
light. Anyone any ideas on this?

 

[Daniel Pitts]

I've got a java.lang.instrument-compliant agent which instruments
java.lang.String. As soon as the venerable String class is modified
this way, any agent logic which uses Strings is itself triggering
instrumented code. What I'd like to have is that all of the agent's
logic can stick to the original String class, and all other logic (ie
the app running with the agent installed) uses the instrumented String
class. My guts tell me this should be possible, but I'm not seeing the
light. Anyone any ideas on this?

I have no experience with this, but here is thought:
Instead of instrumenting String directly, create a new class
InstrumentedStringWrapper. Then instrument all other non-agent classes
to use the InstrumentedStringWrapper class instead.

My gut tells me that instrumenting anything in java.lang is bound to be
troublesome.

 

[softwarepearls_com]

I have no experience with this, but here is thought:
Instead of instrumenting String directly, create a new class
InstrumentedStringWrapper. Then instrument all other  non-agent classes
to use the InstrumentedStringWrapper class instead.

My gut tells me that instrumenting anything in java.lang is bound to be
troublesome.

Hmmm.. sounds like this would require ClassLoading hocus pocus ;-)

Thx for the idea.