How to Treat Object and String

When I talked to Corky, my advisor, today, I found out that you may actually have plain Object instances, and that they are actually used frequently too for the purpose of synchronization. That means I do have to be able to treat Object just like the other classes too. Now I have problems with both Object and String.

Fortunately, we came up with two ways to proceed: The first one is easier but less general and satisfying. We could just punt and decide to not support Object and String right now. This is not entirely unreasonable. Using strings as synchronization events is something neither of us has ever seen, and any class can be substituted in place of Object for synchronization purposes.

The other idea is to dynamically rewrite uses of Object and String to make use of added subclasses ProperObject and ProperString which just extend the original classes with the required field. In general, this isn’t hard to do, but any kind of reflection or instanceof done on these objects might be lead astray. I have to think about how to handle this the best way. So far, I haven’t cared a lot about reflection, though. The fields and methods that I add and rename, of course, have to be hidden as well.

Right now, though, I’m very happy to again find a path ahead of me. Dead ends suck.


About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in Concurrent Unit Testing. Bookmark the permalink.

Leave a Reply