Problems With Decorating

I finally found some time to test the decoration. The problem I have right now is that some methods might be final and thus should not be overridden. I have two choices here:

  1. Change the decoree’s method so that it’s not final.
  2. Give the method a different name in the decorator and reroute all calls to that new method. The new method still delegates to the old, final method

If the first way works, that might actually be the easiest. Theoretically, the possibility exists that someone might try to override the now not-final method, but since all of these programs will first be compiled with the regular compiler, those things should be caught. I’m just worried that this way might not work.

The second way would most definitely work, but it makes these changes global, i.e. all files have to be changed. That’s a lot more work. Also, it introduces new names, which may have to be hidden later when I try to fix reflection.

Talking of reflection: The change to ProperObject might be a lot harder to pull off than I originally thought, at least if reflection is used. Right now it seems like I have to modify class Class and class Constructor so that whenever a request for a new java.lang.Object instance is made, a new ProperObject is created. Furthermode, ProperObject.getClass() should really return java.lang.Object.class, but that’s not really possible: Object.getClass() is native and final. Ugh. getName(), isInstance, isAssignable in class Class will probably have to be hacked, too. The idea is to always work with Object.class but always create ProperClass.class. I just don’t quite know how to do that yet.

I think I might ignore that for now and push on. Reflection on java.lang.Object and java.lang.String is probably pretty rare.


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