70 lines
3 KiB
HTML
70 lines
3 KiB
HTML
|
<!doctype html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
|
||
|
|
<meta http-equiv="content-style-type" content="text/css">
|
||
|
|
<link rel="stylesheet" type="text/css" href="style.css">
|
||
|
|
<title>ProGuard Limitations</title>
|
||
|
|
<script type="text/javascript" language="JavaScript">
|
||
|
|
<!--
|
||
|
|
if (window.self==window.top)
|
||
|
|
window.top.location.replace("../index.html#"+window.location.pathname+window.location.hash);
|
||
|
|
else {
|
||
|
|
var hash="#"+window.location.pathname.replace(window.top.location.pathname.replace("index.html", ""), "");
|
||
|
|
if (window.top.location.hash!=hash)
|
||
|
|
window.top.location.hash=hash;
|
||
|
|
}
|
||
|
|
//-->
|
||
|
|
</script>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
|
||
|
|
<h2>Limitations</h2>
|
||
|
|
|
||
|
|
When using ProGuard, you should be aware of a few technical issues, all of
|
||
|
|
which are easily avoided or resolved:
|
||
|
|
<p>
|
||
|
|
<ul class="spacious">
|
||
|
|
|
||
|
|
<li>For best results, ProGuard's optimization algorithms assume that the
|
||
|
|
processed code never <b>intentionally throws NullPointerExceptions</b> or
|
||
|
|
ArrayIndexOutOfBoundsExceptions, or even OutOfMemoryErrors or
|
||
|
|
StackOverflowErrors, in order to achieve something useful. For instance,
|
||
|
|
it may remove a method call <code>myObject.myMethod()</code> if that call
|
||
|
|
wouldn't have any effect. It ignores the possibility that
|
||
|
|
<code>myObject</code> might be null, causing a NullPointerException. In
|
||
|
|
some way this is a good thing: optimized code may throw fewer exceptions.
|
||
|
|
Should this entire assumption be false, you'll have to switch off
|
||
|
|
optimization using the <code>-dontoptimize</code> option.</li>
|
||
|
|
|
||
|
|
<li>ProGuard's optimization algorithms currently also assume that the
|
||
|
|
processed code never creates <b>busy-waiting loops</b> without at least
|
||
|
|
testing on a volatile field. Again, it may remove such loops. Should this
|
||
|
|
assumption be false, you'll have to switch off optimization using
|
||
|
|
the <code>-dontoptimize</code> option.</li>
|
||
|
|
|
||
|
|
<li>If an input jar and a library jar contain classes in the <b>same
|
||
|
|
package</b>, the obfuscated output jar may contain class names that
|
||
|
|
overlap with class names in the library jar. This is most likely if the
|
||
|
|
library jar has been obfuscated before, as it will then probably contain
|
||
|
|
classes named 'a', 'b', etc. Packages should therefore never be split
|
||
|
|
across input jars and library jars.</li>
|
||
|
|
|
||
|
|
<li>When obfuscating, ProGuard writes out class files named
|
||
|
|
"<code>a.class</code>", "<code>b.class</code>", etc. If a package contains
|
||
|
|
a large number of classes, ProGuard may also write out
|
||
|
|
<b>"<code>aux.class</code>"</b>. Inconveniently, Windows refuses to create
|
||
|
|
files with this reserved name (among a few other names). It's generally
|
||
|
|
better to write the output to a jar, in order to avoid such problems.</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<hr />
|
||
|
|
<noscript><div><a target="_top" href="../index.html" class="button">Show menu</a></div></noscript>
|
||
|
|
<address>
|
||
|
|
Copyright © 2002-2011
|
||
|
|
<a target="other" href="http://www.lafortune.eu/">Eric Lafortune</a>.
|
||
|
|
</address>
|
||
|
|
</body>
|
||
|
|
</html>
|