@lwahonen Will could you have a look at this changeset? I had a look at the "Java 6 compatibility" problem, and this would be my suggestion for a fix. The usage of reflection will creation of the exception down, but considering this is the already slow exception path I consider this acceptable. In turn this keeps the functionality for newer JDKs in place.

What do you think? If you agree, I'll backport this to the 4.5.1-dev branch and will do a release for that.

Should we log the suppressed error here?

        if(addSuppressedMethod == null) {
-            // Make this a NOOP on an unsupported JDK
+            Logger.getLogger(Win32Exception.class.getName()).log(Level.SEVERE, "Suppressed exception will not be visible on JVM 6", exception);
            return;
        }

Other than that, I think your solution is much better than my quick-and-dirty hack was. Thank you!

I would not change that. addSuppressedMethod can only be null if either the method is not present or not reflectively callable. If the latter is the case a log message is created on severity SEVERE. On a recent JVM i see this only happening for VMs not supporting reflection (I'm willing to risk that).

This leaves the first case: If the method is not present, its companion getSuppressed must also be present to be usable. If a library/application depends on the knowledge about the suppressed exceptions, it needs to call getSuppressed, so this prevents the library to work on Java prior to 7 and so addSuppressed is either present or without any use.