ricky/redmine-exception-handler
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Added proguard 4.7 files

Browse Source 
please note that proguard is not yet implmented
refs #17
This commit is contained in:
Ricky Barrette
2012-04-27 10:17:38 -04:00
parent e7b30ea692
commit bff7ed4848
66 changed files with 9695 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
public/proguard/docs/manual/limitations.html Normal file
View File

@@ -0,0 +1,69 @@
<!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 &copy; 2002-2011
<a target="other" href="http://www.lafortune.eu/">Eric Lafortune</a>.
</address>
</body>
</html>