[JAVA] Utiliser ProGuard avec Gradle

Je n'ai jamais utilisé ProGuard dans Gradle, alors notez comment le faire.

Remarque: cet article ne concerne * pas * Android. En ce qui concerne ProGuard dans Gradle, il n'y a que des articles pour Android, mais ce n'est pas le cas.

build.gradle

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

//Omission...

jar {
    manifest {
        attributes 'Main-Class': 'rip.deadcode.Main'  //Modifiez en fonction de votre classe principale
    }
    //Faire un pot de graisse
    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 pour Shrink
    injars jar.archivePath

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

    //Si vous n'utilisez pas Fat JAR, ajoutez des bibliothèques dépendantes aux libraryjars
//    libraryjars configurations.compile.files

    //Destination de sortie s'il vous plaît comme vous le souhaitez
    outjars("${jar.destinationDir}/proguarded.jar")

    //Classes qui ne rétrécissent pas
    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 lors de l'assemblage
assemble.dependsOn(proguard)

point

• Ajoutez net.sf.proguard: proguard-gradle: 6.0.3 au chemin de la classe buildscript. L'échantillon officiel faisait référence au JAR local, mais c'est vrai ... Je n'ai pas pu savoir s'il s'agissait du JAR officiel, donc si vous êtes inquiet, consultez votre propre référentiel.
• Peut être exécuté avec proguard.gradle.ProGuardTask. Dans la plupart des cas, la cible à réduire est le JAR du projet, nous nous appuyons donc ici sur la tâche jar.
• Spécifiez jar.archivePath dans ʻinjars` pour cibler le JAR généré par la tâche jar.
• Vous devez ajouter le JDK JAR à libraryjars. Ici, le chemin du JAR est obtenu à partir de JAVA_HOME, mais si vous voulez l'exécuter sur une JVM différente de la JVM lors de la construction, vous devez vous y référer.
• Cette fois, les bibliothèques etc. sont également rassemblées dans un JAR. Si vous n'incluez pas la bibliothèque dépendante dans le JAR de construction, vous devez également spécifier le JAR de la bibliothèque dépendante dans jars de bibliothèque. Cependant, il n'est pas nécessaire de réduire lors de la création d'une bibliothèque ...
• Vous pouvez spécifier la destination de sortie ʻoutjars` si vous le souhaitez. Dans l'exemple, il est émis au même endroit que le JAR d'entrée.
• Spécifiez une classe qui ne doit pas être réduite avec keep. Dans la plupart des cas, la méthode «main» est la cible. De plus, s'il y a un problème de réflexion, spécifiez-le ici.
• dontwarn supprime les avertissements lorsqu'une classe n'est pas trouvée sur le chemin de la classe. Je me demande si cela arrive habituellement, mais il y a pas mal de bibliothèques telles que SLF4J qui ont le comportement de "quand il y a XX dans le chemin de classe".
• ʻAssemble` Faire en sorte que la tâche créée cette fois dépende de la tâche afin que ProGuard soit exécuté au moment de la construction.
• Source

ProGuard sur AWS Lambda

Je voudrais supprimer le code inutile autant que possible pour améliorer la vitesse au démarrage à froid, mais divers paramètres sont nécessaires.

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

• Il est nécessaire de spécifier diversement dans keep
• Une méthode qui implémente RequestHandler. Requis pour être un point d'entrée.
• L'interface RequestHandler elle-même. Il semble que si le nom change, il ne sera pas correctement reconnu comme une fonction lambda.
• ʻOrg.apache.commons.logging`. Conflit avec le logger du contexte passé au handler.
• com.amazonaws. ** et com.fasterxml. **. Un problème survient en relation avec la sérialisation. Je pense que la portée sera plus raccourcie, mais j'ai abandonné de nombreuses erreurs difficiles à déboguer. Une enquête par un expert est attendue. En fait, il est triste que la taille du fichier soit plutôt grande à cause de cela.
• Ajout de ʻorg.apache.commons.logging. ** et ʻorg.joda.time. ** à dontwarn. J'aimerais que Joda Time passe à Java 8, mais je me demande si ce ne sera pas le cas pour un énorme service comme AWS.

Avec RequestStreamHandler, il semble que de nombreuses parties de ce temps ne seront pas un problème, il peut donc être préférable de l'utiliser au lieu de le porter sur le côté.