[quote]I.e. the selection of which method to invoke based on signature etc is performed at compile-time. This is why when you provide two methods with signatures that differ only in that some of the args are subtypes of some of the others, the JVM does NOT choose which one to invoke based upon the types of the arguments in the invocation; it was determined at compile-time.
[/quote]
There’s no alternative in this situation. As an overloaded (not overridden) method has a different method signature, it can throw different exceptions and return different values. And allowing the runtime to invoke based on the arguments’ runtime types in some circumstances but not others would cause too much chaos to be worthwhile.
This is definitely an area where some extension to the language would make a lot of sense - being able to “extend” a method so as to provide different arguments but leave the rest of the signature alone would be an interesting possibility. The only workaround I’ve seen that makes much sense is to turn each method into a sort of “callback”, where the object of the specific type is asked to call a specific method on the calling object, using a correctly-typed reference. It ain’t cute, but it works. :-/
[quote]In the spirit of the forum ;), how? Sorry to be thick here, but I’m getting stuck trying to work out how it will work without requiring copy-n-paste code into each loaded class.
[/quote]
No need for any copy-n-paste. As I said, you can use one of the bytecode manipulators to append your boiler-plate code to the class after you’ve read it from disk but before letting the VM know about it.
