I am currently working on a platform which makes heavy use of dynamic byte code modification routines via the ASM library. I have been able to successfully instrument all required system classes apart from the array class. (i.e String[], int[], etc) this is because the array class is, itself, a dynamic type thus there is actually no class file in the rt.jar to instrument as far as i’m aware.
However, It did occur to me that even the array type extends java.lang.Object so although modifying the Object class would be less than ideal, not least because it would cause any changes to be propagated to all sub classes, it would possibly allow me to indirectly add an extra primitive field to the array class which, incidentally, is all i’m seeking to achieve.
Aside from the obvious caveats I’ve mentioned would this cause any other platform related problems?
Instead of instrumenting Object, the simplest thing to do is replace it with a compiled version of your choice. Assuming this works, you can instrument it to make it more portable.
Note: I have found JVMs don’t like Object to have additional methods (If you add more than one you get strange errors)