Instrumental array via java.lang.Object

I am currently working on a platform that actively uses dynamic byte code modification routines through the ASM library. I was able to successfully use all the necessary classes of the system except the array class. (i.e. String [], int [], etc.), this is because the array class itself is a dynamic type, so the rt.jar file actually does not have a class file, as far as I know.

However, it seemed to me that even the type of the array extends java.lang.Object, although the modification of the Object class will be less ideal, not least because this will lead to the fact that any changes will be distributed to the entire subclass, this will allow me to indirectly add an extra primitive field to the array class, which, by the way, is all that I want to achieve.

Besides the obvious caveats that I mentioned, will it cause any other platform related issues?

+7
source share
2 answers

Instead of the Object toolkit, the easiest way is to replace it with the compiled version of your choice. Assuming this works, you can measure it to make it more portable.

Note. I found that JVMs do not like Object to have additional methods (if you add more than one, you get strange errors)

+4
source

It may be difficult for you to get and set the field.

The description of the JVM specification for getfield and putfield (if I understand them correctly) states that they should not be used on arrays. To indicate for getfield :

The type of objectref must not be an array type.

and putfield :

The objectref class should not be an array.

However, if any restriction ("required" or "should not") in the description of the instruction is not executed at run time, the behavior of the Java virtual machine is undefined ', so it can just work.

+3
source

All Articles