Question

I generally oppose extension since it creates a very strong connection between classes, which is easy to accidentally break.

However, I finally thought I’d found a reasonable case for it – I want to optionally use a compressed version of a file type in an existing system. The compressed version would be almost as quick as the uncompressed, and would have exactly the same methods available (i.e. read and write) – the only difference would be in the representation on disk. Therefore, I had the compressed version extend the uncompressed version so that either kind of file could be used, just by optionally insantiating the other type.

public class CompressedSpecialFile extends SpecialFile(){ ... }

if (useCompression){
    SpecialFile = new CompressedSpecialFile();
} else {
    SpecialFile = new SpecialFile();
}

However, at a later point in the program, we use reflection:

Object[] values = new Object[]{SpecialFile sf, Integer param1, String param2, ...}
Class myclass = Class.forName(algorithmName);
Class[] classes = // created by calling .getClass on each object in values
constructor = myclass.getConstructor(classes); 
Algorithm = (Algorithm) constructor.newInstance(values)

Which all worked fine, but now the myclass.getConstructor class throws a NoSuchMethodException since the run-time type of the SpecialFile is CompressedSpecialFile.

However, I thought that was how extension is supposed to work – since CompressedSpecialFile extends SpecialFile, any parameter accepting a SpecialFile should accept a CompressedSpecialFile. Is this an error in Java’s reflection, or a failure of my understanding?

Answer 1

Hmm, the response to this bug report seems to indicate that this is intentional.
https://bugs.java.com/bugdatabase/view_bug?bug_id=4301875

We cannot make this change for compatibility reaons. Furthermore, we
would expect that getConstructor should behave analogously to getDeclaredMethod,
which also requires an exact match, thus it does not make sense to change one
without changing the other. It would be possible to add an additional suite of
methods that differed only in the way in which the argument types were matched,
however.
There are certainly cases where we might want to apply at runtime during
reflection the same overload-resolution algorithm used statically by the
compiler, i.e., in a debugger. It is not difficult to implement this
functionality with the existing API, however, so the case for adding this
functionality to core reflection is weak.

That bug report was closed as a duplicate of the following one, which provides a bit more implementation detail:
https://bugs.java.com/bugdatabase/view_bug;jsessionid=1b08c721077da9fffffffff1e9a6465911b4e?bug_id=4287725

Work Around
Users of getMethod must be precise identifying the Class passed to the argument.

Evaluation
The essence of this request is that the user would like for Class.getMethod
to apply the same overloading rules as the compiler does. I think this is
a reasonable request, as I see a need for this arising frequently in certain
kinds of reflective programs, such as debuggers and scripting interpreters,
and it would be helpful to have a standard implementation so that everybody
gets it right. For compatibility, however, the behavior of the existing
Class.getMethod should be left alone, and a new method defined. There is
a case for leaving this functionality out on the basis of footprint, as it
can be implemented using existing APIs, albeit somewhat inefficiently.
See also 4401287.
Consensus appears to be that we should provide overload resolution in
reflection. Exactly when such functionality is provided would depend largely
on interest and potential uses.
For compatibility reasons, the Class.get(Declared)+{Method,Constructor}
implementation should not change; new method should be introduced. The
specification for these methods does need to be modified to define "match". See
bug 4651775.

You can keep digging into those referenced bugs and the actual links I provided (where there’s discussion as well as possible workarounds) but I think that gets at the reasoning (though why a new method reflecting java’s oop in reflection as well has not yet been implemented, I don’t know).

In terms of workarounds, I suppose that for the one-level-deep version of inheritance, you can just call getSuperclass() on each class whose name is that of the extending class, but that’s extremely inelegant and tied to you using it only on your classes implementing in the prescribed manner. Very kludgy. I’ll try and look for another option though.