JSR 335 spec, chapter "15.28.2 Run-time Evaluation of Method References" contains following assertion:

If the method reference has the form super :: NonWildTypeArgumentsopt Identifier or TypeName . super :: NonWildTypeArgumentsopt Identifier, the body of the invocation method similarly has the effect of invoking the compile-time declaration of the method reference, as described in 15.12.4.3, 15.12.4.4, 15.12.4.5.[jsr335-15.28.2-42

This assertions refers to chapter "15.12.4.3. Check Accessibility of Type and Method" which specifies:

An implementation of the Java programming language must ensure, as part of linkage, that the method m still exists in the type T. If this is not true, then a NoSuchMethodError (which is a subclass of IncompatibleClassChangeError) occurs. (jls-15.12.4.3-110)

But InvocationTargetException is thrown instead of NoSuchMethodError.

This does happen for b103 Windows7x64 platform.

The minimized sources reproducing this problem are attached.

In order to reproduce the problem following steps should be performed in exactly specified order:
1) compile Test.java;
2) _after_ that, compile bad.java;
3) execute Test.main.

The following output is to produced:

Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:491)
at Test.main(Test.java:22)
Caused by: java.lang.NoSuchMethodError: MethodSupplier.m(I)V
at MethodInvoker.lambda$0$bridge(Test.java:12)
at MethodInvoker$$Lambda$1.invokeMethodReference(Unknown Source)
at MethodInvoker.doInvoke(Test.java:13)
at MethodInvoker.invoke(Test.java:16)
... 5 more

However NoSuchMethodError should have been thrown as it follows from the specification.