|
1 | 1 | # Troubleshooting |
2 | 2 |
|
3 | | -There are a couple of things you should be aware of when obfuscating and shrinking software. |
4 | | -The weakest part of an application considering name obfuscation and code shrinking is code that uses reflection to dynamically load classes, invoke methods etc. Therefore, you have to be especially careful when using the yguard task on applications that rely on reflection. |
| 3 | +There are a couple of things you should be aware of when obfuscating software. |
| 4 | +The weakest part of an application considering name obfuscation is code that uses reflection to dynamically load classes, invoke methods etc. Therefore, you have to be especially careful when using the yguard task on applications that rely on reflection. |
5 | 5 | The most important facts to keep in mind when using yGuard are described here briefly: |
6 | 6 |
|
7 | | -- If you use the `rename` task, code in the form of `MyApplication.class` will break if `MyApplication` will be obfuscated by name and the obfuscation switch [replaceClassNameStrings](task_documentation.md#the-rename-element) is set to `false`. The `shrink` task will currently recognize code in the form of `MyApplication.class` only if the java files were compiled using an arbitrary version of the standard javac compiler (although the shrinking engine might recognize the `.class` construct also if the classes were compiled using a compiler that generates similar bytecode). |
8 | | -- Automatic introspection and reflection will break in most cases, when you decide to obfuscate the corresponding methods and fields. If you use the `shrink` task and your application uses reflection you should explicitly designate all entities loaded per reflection as code entrypoints using the [keep](task_documentation.md#the-keep-element) element. |
9 | | -If your application is broken after using the `shrink` task, consider using the [createStubs](task_documentation.md#the-shrink-element) attribute of the `shrink` task to find out which additional entities you need to include in the keep element. |
10 | | -- `Class.forName(className)` will not work when using the `rename` task unless you use the obfuscated name string in your variable or the String is a local constant and [replaceClassNameStrings](task_documentation.md#the-keep-element) is not set or set to `true`. If you use the `shrink` task, `className` should be contained in the list of entrypoints using the `keep` element. |
11 | | -- The customized serialization mechanism will not work if you obfuscated or shrinked the writeObject and readObject methods as well as the serializationUID field. |
| 7 | +- If you use the `rename` task, code in the form of `MyApplication.class` will break if `MyApplication` will be obfuscated by name and the obfuscation switch [replaceClassNameStrings](task_documentation.md#the-rename-element) is set to `false`. |
| 8 | +- Automatic introspection and reflection will break in most cases, when you decide to obfuscate the corresponding methods and fields. |
| 9 | +- `Class.forName(className)` will not work when using the `rename` task unless you use the obfuscated name string in your variable or the String is a local constant and [replaceClassNameStrings](task_documentation.md#the-keep-element) is not set or set to `true`. |
| 10 | +- The customized serialization mechanism will not work if you obfuscated the writeObject and readObject methods as well as the serializationUID field. |
12 | 11 | - Simple bean introspection will not work, if you decide to obfuscate your public accessor methods, since it makes use of reflection. |
13 | 12 | - If you do not set the `-Xmx` property for the Java virtual machine, the `yguard` Ant task might fail due to a `java.lang.OutOfMemoryError`. |
14 | 13 | To solve this problem, set the `-Xmx` option in the `ANT_OPTS` variable, e.g.: |
|
0 commit comments