This got me curious as to how exactly Method:invoke(...) performs the automatic unwrapping of the 'args' parameters to their primitive types - whether they do what Riven suggested, or something more 'magic'.
I wish now that I hadn't looked, as it was:
a) a waste of time
b) shocking.
Apparently Method:invoke(...) falls through to the MethodAccessor interface; a concrete implementation of which is obtained from a MethodAccessorGenerator.
The MethodAccessorGenerator.generate(...) is the shocking part - it contains code to generate (at runtime) the bytecode representation of a class file (a subclass of 'MagicAccessorImpl' that implements the MethodAccessor interface.), that it subsequently defines, instanciates & returns.
Ergo there is no source code to read, or class file in the rt.jar to decompile, to see exactly how Method:invoke(...) does it's magic

I suppose if you were *realy* interested you could try to hack the jre to store the runtime generated class definition somewhere... but I've a feeling the reason they don't create the class file definition until runtime, is because this stuff is so low level it probably has to account for the code mangling that jit & hotspot are doing.