How do you stop proguard from devirtualizing a class's members?
When using
-keep com.myPackage.JVMSpecificCode
proguard keeps the public method name and signature but changes it from an instance method to a static method. While normally this is a great optimization for methods that do not access instance state it is causing problems for my particular scenario resulting in the following error:
I am applying proguard on a mult-release jar file where 99% of the code is JVM agnostic. This is done by:
1) Classes under META-INF/versions are filtered out
2) Classes that containing JVM specific code is identified and placed into a -keep list in a generated proguard config file.
However proguard still applies devirtualization on classes listed with the keep parameter, while the filtered out classes under META-INF/versions are still instance methods, causing errors when run with JVM that pulls classes from META-INF/version instead of the jar root.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How do you stop proguard from devirtualizing a class's members?
When using
-keep com.myPackage.JVMSpecificCode
proguard keeps the public method name and signature but changes it from an instance method to a static method. While normally this is a great optimization for methods that do not access instance state it is causing problems for my particular scenario resulting in the following error:
java.lang.IncompatibleClassChangeError: Expected static method....
I am applying proguard on a mult-release jar file where 99% of the code is JVM agnostic. This is done by:
1) Classes under META-INF/versions are filtered out
2) Classes that containing JVM specific code is identified and placed into a -keep list in a generated proguard config file.
However proguard still applies devirtualization on classes listed with the keep parameter, while the filtered out classes under META-INF/versions are still instance methods, causing errors when run with JVM that pulls classes from META-INF/version instead of the jar root.
You should not just specify the class, but also its methods. The following should work:
Thanks for the reply. You are right that was it. I should have read the
docs better.
On Mon, Nov 4, 2019, 12:24 AM Eric Lafortune lafortune@users.sourceforge.net wrote: