add a field to java.lang.Object

Question

Hi,

I added a field to Object class , as in :

class Object {
   ...

   private Object _objInfo;
}

I changed java.lang.Object's source code and recompiled openjdk 6. I get the following exception when the VM boots:

Error occurred during initialization of VM
java.lang.IllegalStateException
at java.lang.Throwable.initCause(Throwable.java:337)
at java.lang.ExceptionInInitializerError.<init>(ExceptionInInitializerError.java:79)

The same problem occurs when I define my own Object class and prepended it to bootclasspath, as in:

java -Xbootclasspath/p:<path to my Object class>

Thanks, Horatiu

Answer 1

Error occurred during initialization of VM java.lang.IllegalStateException at java.lang.Throwable.initCause(Throwable.java:337) at java.lang.ExceptionInInitializerError.(ExceptionInInitializerError.java:79)

The java.lang.IllegalStateException is thrown if initCause() is called more than once. Sounds like your modification of Object is causing an exception and when the JVM tries to create an Exception object (which is a subclass of Object) it gets into a recursive loop and attempts to call initCause() more than once on the same Exception object.

Why do you want to modify the definition of Object?

Answer 2

I suspect that there is something inside the implementation of the JVM that assumes the size of Object. You've made it larger so that code is failing.

Because this is an error that the JVM implementors never considered, error handling breaks.

The answer: you can't modify Object without doing a lot more work.

Answer 3

Apparently, there are still a number of places in native code where field offsets are hardwired. Modifying some classes, such as Thread, mess this up. If you change Object, you mess them all up.

Answer 4

Don't modify Object. Don't modify anything in java.lang. I don't know if it's technically possible, but it is definitely an exceptionally bad idea, and basically breaks the Java platform ("Q: What's the contract of Object.equals()? A: It depends what the custom modifications to the JVM make it do...") - you wouldn't be able to get anything done.

Think about what you're doing - you're adding this class (and possible behaviour) to every object. ClassLoaders, Strings, Threads, InputStreams, Throwables, XMLGregorianCalendar, everything. This is almost certainly not what you intended.

Instead, an alternative approach would be to add your modifications to an abstract class AppnameSuperObject, and extend this for the classes that you really want to add this behaviour to.

---

On the other hand, if you really do want to do this for all objects for some kind of logging/profiling/etc kind of work, look at using aspect-oriented programming to weave the extra fields onto the classes at runtime.

Answer 5

I'd just like to point out that if you add fields to java.lang.Object you are likely to introduce incompatibilities with existing Java code. Your new "JVM" won't be a "Java (TM)" Virtual Machine, by any stretch of the terminology.

Of course, if this is just a private / experimental version, this won't matter. As long as you don't start calling it "Java" or a "JVM" in public places, and attract the attention of Oracle's IP lawyers.