IssueTracker

Thanks for the report. Nothing is changing java.util.zip.ZipFile as that is part of the devices bootclasspath and cannot be changed or overridden by your program. It looks like the apache library might be using some reflection in their zip library. Could you check if org.apache.commons.compress.archivers.zip.ZipArchiveEntry.getUnparseableOnly(ZipArchiveEntry.java:896) is making reflective calls? Does adding -keep org.apache.commons.compress.archivers.zip.ExtraFieldUtils { * } avoid the exception?

Did a quick scan of the apache code online and I can't see any indication of why ExtraFieldUtils would be eliminated, so it looks like there is a more complicated judgment going on. If you can share a compiler input dump of the failing build, I should be able to diagnose this locally. You can share it privately with zerny@google.com

Yes, sorry, forgot the class in the proposed rule.

Thanks for the log. That shows the point of failure and the reflection. Online I found the following code for ExtraFieldUtils.java:

class ExtraFieldUtils {
<snip>
static {
        IMPLEMENTATIONS = new ConcurrentHashMap<>();
        register(AsiExtraField.class);
        register(X5455_ExtendedTimestamp.class);
        register(X7875_NewUnix.class);
        register(JarMarker.class);
        register(UnicodePathExtraField.class);
        register(UnicodeCommentExtraField.class);
        register(Zip64ExtendedInformationExtraField.class);
        register(X000A_NTFS.class);
        register(X0014_X509Certificates.class);
        register(X0015_CertificateIdForFile.class);
        register(X0016_CertificateIdForCentralDirectory.class);
        register(X0017_StrongEncryptionHeader.class);
        register(X0019_EncryptionRecipientCertificateList.class);
        register(ResourceAlignmentExtraField.class);
    }
<snip>
    /**
     * Register a ZipExtraField implementation.
     *
     * <p>The given class must have a no-arg constructor and implement
     * the {@link ZipExtraField ZipExtraField interface}.</p>
     * @param c the class to register
     */
    public static void register(final Class<?> c) {
        try {
            final ZipExtraField ze = (ZipExtraField) c.newInstance();
            IMPLEMENTATIONS.put(ze.getHeaderId(), c);
        } catch (final ClassCastException cc) { // NOSONAR
            throw new IllegalArgumentException(c + " doesn't implement ZipExtraField"); //NOSONAR
        } catch (final InstantiationException ie) { // NOSONAR
            throw new IllegalArgumentException(c + " is not a concrete class"); //NOSONAR
        } catch (final IllegalAccessException ie) { // NOSONAR
            throw new IllegalArgumentException(c + "'s no-arg constructor is not public"); //NOSONAR
        }
    }
}

The register function is reflectively calling newInstance() on the class constants and assuming the are of type ZipExtraField. I'd add the following rule to capture this:

-keep class * extends org.apache.commons.compress.archivers.zip.ZipExtraField { <init>(); }

Or, you could make it conditional:

-if class * extends org.apache.commons.compress.archivers.zip.ZipExtraField
-keep class <1> { <init>(); }

With the latter rule, it should be such that if your project does not actually use the ExtraFieldUtils then it won't end up keeping those classes.

I'm happy to hear the rule works for you.

You can continue to use compatibility mode which can hide some cases such as these, but if it will work or not is a bit arbitrary (for example the reflective identification is brittle). Some users care a lot about size, in which case 300k on an already shrunk app is a lot. That saving is not possible in compatibility mode, thus we are providing full mode.

Regarding the "last issue", the use of reflection can cause issues in both compatibility mode and full mode. There is no way to avoid that when using a shrinker. We know that it is hard to debug these issues (regardless of which mode) and hope to improve our tooling and support as best we can. For now, that consists mostly of looking at the code.