Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java 6 compatibility #876

Merged
merged 2 commits into from
Nov 22, 2017

Conversation

matthiasblaesing
Copy link
Member

This is a partial fix to restore Java 6 compatibility:

  • unittests for jna can be compiled with a Java 6 JDK
  • the jna-platform can be compiled with a Java 6 JDK
  • the unittests for the jna-plaform still require a Java 7 JDK

@matthiasblaesing
Copy link
Member Author

@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.

@lwahonen
Copy link

lwahonen commented Nov 19, 2017

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!

@matthiasblaesing
Copy link
Member Author

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.

addSuppressed was added to Throwable in JDK7, to be compatible with
Java 6 it can't be called directly. To replace the functionality
reflection is used. A helper method "addSuppressedRelfected" was
introduced into the only class, that currently uses suppressed 
exceptions (Win32Exception).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants