Eric Lafortune

You should specify the output jar in the "Input/Output" tab > "Add output..." ProGuard doesn't obfuscate the runtime jar rt.jar, but it does need it as a library jar to process your program jar correctly.

You generally can't know for sure. ProGuard by default uses names a, b, c,... for classes, fields and methods, but a developer can specify his or her own dictionaries. In the ProGuard examples, the source file name in a stack trace is set to "SourceFile" and many developers adopt that as well.

You should not just specify the class, but also its methods. The following should work: -keep,allowshrinking class com.myPackage.JVMSpecificCode { *; }

Thank you for your contribution. The original behavior was of course intentional: the input must be clean to avoid ambiguities. With your proposed change, class files are written with their fully quailified internal names . This also applies to the more common problem case where the input has unexpected directory prefixes; e.g. WEB-INF/classes/com/test/Data.class would become com/test/Data.class . I don't think this is desirable. We'll have to discuss this internally. Our upcoming renaming functionality...

A misjudgment exception occurs while preverifying

Thank you for your extensive research. This error typically occurs if ProGuard doesn't have the complete class hierarchy of all classes that are processed. Have you suppressed any warnings with -dontwarn or -ignorewarnings? Can you run ProGuard without these settings? If you get warnings about missing classes, can you add their jars to the input? See https://www.guardsquare.com/en/products/proguard/manual/troubleshooting#superclass

ProGuard doesn't support any features that are in the preview format, but not in the final format. At this time, ProGuard works fine with for example java version "13" 2019-09-17 Java(TM) SE Runtime Environment (build 13+33) Java HotSpot(TM) 64-Bit Server VM (build 13+33, mixed mode, sharing) We'll support any features that make in into Java 14...

support Java 13