Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimized Proguard won't work with Rhino Proguard 'rules' #388

Closed
vanniktech opened this issue Feb 5, 2018 · 5 comments
Closed

Optimized Proguard won't work with Rhino Proguard 'rules' #388

vanniktech opened this issue Feb 5, 2018 · 5 comments

Comments

@vanniktech
Copy link

The following proguard 'rules' - which are basically keep everything - work for the normal proguard round:

# Rhino
-keep class org.mozilla.** { *; }
-dontwarn org.mozilla.javascript.**
-dontwarn org.mozilla.classfile.**

However they won't work when doing optimizations via: proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'

It'll fail with:

Removing unused program classes and class elements...
  Original number of program classes: 10328
  Final number of program classes:    5623
Inlining subroutines...
Optimizing...
  Number of finalized classes:                 1313
  Number of unboxed enum classes:              19
  Number of vertically merged classes:         0   (disabled)
  Number of horizontally merged classes:       0   (disabled)
  Number of removed write-only fields:         0   (disabled)
  Number of privatized fields:                 0   (disabled)
  Number of inlined constant fields:           0   (disabled)
  Number of privatized methods:                1630
  Number of staticized methods:                745
  Number of finalized methods:                 11904
  Number of removed method parameters:         812
  Number of inlined constant parameters:       275
  Number of inlined constant return values:    110
  Number of inlined short method calls:        3846
  Number of inlined unique method calls:       4627
  Number of inlined tail recursion calls:      41
  Number of merged code blocks:                167
  Number of variable peephole optimizations:   17571
  Number of arithmetic peephole optimizations: 0   (disabled)
  Number of cast peephole optimizations:       0   (disabled)
  Number of field peephole optimizations:      69
  Number of branch peephole optimizations:     5588
  Number of string peephole optimizations:     1494
  Number of simplified instructions:           1499
  Number of removed instructions:              8560
  Number of removed local variables:           762
  Number of removed exception blocks:          272
  Number of optimized local variable frames:   6951
Shrinking...
Removing unused program classes and class elements...
  Original number of program classes: 5623
  Final number of program classes:    5518
Optimizing...
Unexpected error while performing partial evaluation:
  Class       = [org/mozilla/javascript/tools/debugger/SwingGui]
  Method      = [showStopLine(Lorg/mozilla/javascript/tools/debugger/Dim$StackFrame;)V]
  Exception   = [java.lang.IllegalArgumentException] (Can't find common super class of [org/mozilla/javascript/tools/debugger/FileWindow] (with 1 known super classes) and [java/lang/String] (with 2 known super classes))
Warning: Exception while processing task java.io.IOException: java.lang.IllegalArgumentException: Can't find common super class of [org/mozilla/javascript/tools/debugger/FileWindow] (with 1 known super classes) and [java/lang/String] (with 2 known super classes)

The moment I switch back to proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' it works again.

Is there any solution to this? Unfortunately, I have to rely on optimizations since I want to shrink some bytes of the final APK.

@sainaen
Copy link
Contributor

sainaen commented Feb 5, 2018

Sorry, I don’t know much about Proguard, but I think the culprit is the Debugger UI that depends on Swing, which is not present on Android.

  1. I found this proguard.pro in one of the Facebook's repos, perhaps it could be useful for you as an example to try?
  2. There are several answers on StackOverflow that advise removing tools directory from the rhino.jar. Maybe we could consider adding Android-specific build that doesn't include debugger (or anything else useless there), but until then would it be hard for you to do this on your own?

@vanniktech
Copy link
Author

Those proguard rules are pretty much the same. Maybe they're slightly less restrictive but

-keep class org.mozilla.** { *; }

covers all of those:

-keep class org.mozilla.classfile.** { *; }
-keep class org.mozilla.javascript.* { *; }
-keep class org.mozilla.javascript.annotations.** { *; }
-keep class org.mozilla.javascript.ast.** { *; }
-keep class org.mozilla.javascript.commonjs.module.** { *; }
-keep class org.mozilla.javascript.commonjs.module.provider.** { *; }
-keep class org.mozilla.javascript.debug.** { *; }
-keep class org.mozilla.javascript.jdk13.** { *; }
-keep class org.mozilla.javascript.jdk15.** { *; }
-keep class org.mozilla.javascript.json.** { *; }
-keep class org.mozilla.javascript.optimizer.** { *; }
-keep class org.mozilla.javascript.regexp.** { *; }
-keep class org.mozilla.javascript.serialize.** { *; }
-keep class org.mozilla.javascript.typedarrays.** { *; }
-keep class org.mozilla.javascript.v8dtoa.** { *; }
-keep class org.mozilla.javascript.xml.** { *; }
-keep class org.mozilla.javascript.xmlimpl.** { *; }

Solution #2 seems like the way to go and also the proper way. I should be able to get something up and running however I'd favor an official release from you that fixes this. Also that way everyone can benefit from the improvements.

What are the exact steps for achieving this? Do we want a separate build or find a tool to strip out the package from the built jar and then release it with some new maven coordinates?

@sainaen
Copy link
Contributor

sainaen commented Feb 6, 2018

covers all of those

Yeah, I though so, but figured maybe -keep class org.mozilla.** { *; } is too broad? Notice that they don’t keep org.mozilla.javascript.tools.**, which is causing problems in your case.

What are the exact steps for achieving this? Do we want a separate build or find a tool to strip out the package from the built jar and then release it with some new maven coordinates?

Sorry, I’m not a maintainer, these questions will have to be resolved with @gbrail. Though, I’d imagine a separate build to be an easier way.

@vanniktech
Copy link
Author

Yeah, I though so, but figured maybe -keep class org.mozilla.** { *; } is too broad? Notice that they don’t keep org.mozilla.javascript.tools.**, which is causing problems in your case.

That might be a valid point. I tried it out and so far it seems to work. I'll close this then and investigate whether any additional rules are needed or not.

Thanks already.

@sainaen
Copy link
Contributor

sainaen commented Feb 6, 2018

@vanniktech
Great! Glad I could help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants