Menu

#153 Consider making -dontwarn the default

Some sunny day
open
None
4
2014-05-07
2014-05-01
No

I think I have been going about Proguard all wrong.

As far as I can see, warnings (versus "notes") only deal with missing class references. Typically, my work process goes something this:

  1. Get an application working without Proguard.
  2. Add Proguard to the build process with obfuscation and optimization disabled.
  3. Spend days fixing the warnings.
  4. Spend hours fixing the notes.
  5. Enable obfuscation, fix related problems.
  6. Enable optimization, fix related problems.

The problem is that fixing warnings takes way longer than it should and the vast majority of warnings are actually false positives. Why? Because I already got the application working in step 1, so the only way a warning is relevant is if I forgot to pass a -libraryjars to Proguard.

Historically speaking, I am far more likely to run into false positives in the list of warnings than I am to forget a -libraryjars.

This led me to thinking: perhaps Proguard should default to -dontwarn, and users should only enable warnings for diagnostics purposes if/when they run into problems (which should be almost never).

The only reason I spent days trying to fix warnings (using class filters) in the first place was because I thought I had done something wrong. The FAQ also seems to hint in that direction. It instructs users on how to try to resolve warnings as opposed to explaining to them that 99% of the time, these are false positives and you are only meant to use this information for diagnostics purposes.

Let me know what you think.

Discussion

  • Eric Lafortune

    Eric Lafortune - 2014-05-06

    ProGuard acts like a compiler, which also insists on all dependencies being present, in order to perform properly. Missing classes can cause many problems for unsuspecting users: configuration not working as expected, errors while processing, processed code failing in unpredictable ways, etc. Identifying the cause of such problems can be very painful, all because ProGuard could accept sloppy input.

    The -dontwarn option is a concession to real life. It also forces developers to think about their code. The documentation tries to explain the problem and nudge developers in the direction of clean solutions first, which may require more effort. You're an experienced ProGuard user and you probably understand the issues. Feel free to use the option where necessary.

    Admittedly, extensive and incomplete dependencies on third-party libraries are becoming increasingly common. Also, standard build processes (for Android, for instance) generally make sure that the input is specified correctly. The option may make sense in such contexts.

     
  • Eric Lafortune

    Eric Lafortune - 2014-05-06

    Ticket moved from /p/proguard/bugs/517/

     
  • Eric Lafortune

    Eric Lafortune - 2014-05-06
    • assigned_to: Eric Lafortune
    • Group: v4.5 --> Next_Release_(example)
    • Priority: 5 --> 4
     
  • Gili Tzabari

    Gili Tzabari - 2014-05-07

    I no longer think it is realistic to correct warnings using file filters. As you mentioned, "extensive and incomplete dependencies on third-party libraries are becoming increasingly common". 10 years ago, filtering classes might have made sense, but over the past 5 years I haven't run across a single project that didn't depend on incomplete/optional third-party libraries.

    In my experience, the fastest way to add Proguard to a project is to:

    1. Get the project running 100% without Proguard.
    2. Add Proguard to the build process, with only shrinking enabled.

    At this point, you are guaranteed that 100% of warnings are false-positives (otherwise the project wouldn't have worked before you added Proguard).

    I think the documentation should guide users in this direction, instead of expecting them to fix warnings using file filters.

    Perhaps you should ask some other Proguard users what their experience has been. I am willing to bet that they are using the same procedure.

     

Log in to post a comment.