Use ProGuard with Gradle

I've never used ProGuard in Gradle, so make a note of how to do it.

Note: This article is * not * about Android. When you say ProGuard in Gradle, there are only articles for Android, but this is not the case.

build.gradle

buildscript {
    dependencies {
        classpath(
                'net.sf.proguard:proguard-gradle:6.0.3'
        )
    }
}

//Omission...

jar {
    manifest {
        attributes 'Main-Class': 'rip.deadcode.Main'  //Modify according to your Main class
    }
    //Make Fat Jar
    from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA'
}

task proguard(type: proguard.gradle.ProGuardTask, dependsOn: jar) {

    def javaHome = System.getProperty('java.home')

    //JAR for Shrink
    injars jar.archivePath

    libraryjars files(
            "${javaHome}/lib/rt.jar",  //Java SE runtime
            "${javaHome}/lib/jce.jar"  //crypto module
    )

    //If you don't use Fat JAR, add dependent libraries to libraryjars
//    libraryjars configurations.compile.files

    //Output destination please as you like
    outjars("${jar.destinationDir}/proguarded.jar")

    //Classes that do not shrink
    keep("public class ${jar.manifest.attributes['Main-Class']} { public static void main(java.lang.String[]); }")

    dontwarn("ch.qos.logback.**")
    dontwarn('afu.org.checkerframework.**')
    dontwarn("org.checkerframework.**")
    dontwarn('org.slf4j.**')
}

//ProGuard when assembling
assemble.dependsOn(proguard)

point

• Add net.sf.proguard: proguard-gradle: 6.0.3 to the buildscript classpath. The official sample referred to the local JAR, but that's true ... I couldn't find out if this was the official JAR, so if you're worried, check out your own repository.
• Can be run with proguard.gradle.ProGuardTask. In most cases, the target to shrink is the JAR of the project, so here we rely on the jar task.
• Specify jar.archivePath in ʻinjars` to target the JAR generated by the jar task.
• You need to add the JDK JAR to libraryjars. Here, the JAR path is obtained from JAVA_HOME, but if you want to execute it in a JVM different from the JVM at build time, you need to refer to that.
• This time, the libraries etc. are also put together in one JAR. If you do not include the dependent libraries in the building JAR, you must also specify the dependent library JARs in library jars. However, there is no need to shrink when creating a library ...
• You can specify the output destination ʻoutjars` if you like. In the example, it is output to the same place as the input JAR.
• Specify a class that should not be shrunk with keep. Most of the time, the main method is the target. In addition, if there is a problem with reflection, specify it here.
• dontwarn suppresses warnings when a class is not found in the classpath. I wonder if it usually happens, but there are quite a few libraries such as SLF4J that have the behavior of "when there is XX in the classpath".
• ʻAssemble` Make the task created this time depend on the task so that ProGuard will be executed at build time.
• Source

ProGuard on AWS Lambda

I'd like to remove unnecessary code as much as possible to improve the speed at cold start, but various settings are required.

keep("public class rip.deadcode.bot.Application { *; }")  //Method implementing RequestHandler
keep("public interface com.amazonaws.services.lambda.runtime.RequestHandler { *; }")
keep("class com.amazonaws.** { *; }")
keep("class com.fasterxml.** { *; }")
keepattributes("Signature,*Annotation*")

• It is necessary to specify variously in keep
• A method that implements RequestHandler. Necessary because it will be an entry point.
• The RequestHandler interface itself. It seems that if the name changes, it will not be correctly recognized as a lambda function.
• ʻOrg.apache.commons.logging`. Conflict with the logger of the context passed to the handler.
• com.amazonaws. ** and com.fasterxml. **. Problems occur in relation to serialization. I think the scope will be shortened more, but I gave up because there were many errors that were difficult to debug. An expert investigation is awaited. In fact, it's sad that the file size is rather large because of this.
• Added ʻorg.apache.commons.logging. ** and ʻorg.joda.time. ** to dontwarn. I'd like Joda Time to move to Java 8, but I wonder if it will not be so if it becomes a huge service like AWS.

With RequestStreamHandler, it seems that many parts of this time will not be a problem, so it may be necessary to use it instead of wearing it sideways.