ad5cd31498
* Add shrinker-test examples with never-referenced constructors R8 can do some optimizations that assume values of types whose constructors are never referenced are `null`. (A bit confused why the rules here are sufficient to avoid that optimization in the case of a class whose sole constructor has arguments and is unreferenced, since the keep rule only refers to `<init>()` instead of `<init>(...)`. Does R8 have special behavior for `<init>()` where attempting to keep that makes it assume a class is constructable even if it doesn't have a no-args constructor?) Also rename some test classes/names to refer to `NoArgs` instead of `Default` constructors. The examples here care about whether a no-argument constructor is present. While a no-argument constructor (explicitly defined or not) is used by default in some circumstances, the Java documentation consistently uses "default constructor" to refer only to constructors whose implementation is implicitly provided by the complier (all default constructors are no-argument constructors, but not vice versa). * Update shrinker-test/src/main/java/com/example/ClassWithNoArgsConstructor.java Accept review suggestion Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com> * Update shrinker-test/src/main/java/com/example/NoSerializedNameMain.java Accept review suggestion Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com> * Further adjust test class/method names for consistency * Update shrinker-test/src/main/java/com/example/NoSerializedNameMain.java Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com> --------- Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| src | ||
| README.md | ||
| common.pro | ||
| pom.xml | ||
| proguard.pro | ||
| r8.pro | ||
README.md
shrinker-test
This Maven module contains integration tests which check the behavior of Gson when used in combination with code shrinking and obfuscation tools, such as ProGuard or R8.
The code which is shrunken is under src/main/java; it should not contain any important assertions in case the code shrinking tools affect these assertions in any way. The test code under src/test/java executes the shrunken and obfuscated JAR and verifies that it behaves as expected.
The tests might be a bit brittle, especially the R8 test setup. Future ProGuard and R8 versions might cause the tests to behave differently. In case tests fail the ProGuard and R8 mapping files created in the target directory can help with debugging. If necessary rewrite tests or even remove them if they cannot be implemented anymore for newer ProGuard or R8 versions.
Important: Because execution of the code shrinking tools is performed during the Maven build, trying to directly run the integration tests from the IDE might not work, or might use stale results if you changed the configuration in between. Run mvn clean verify before trying to run the integration tests from the IDE.