1 files changed, 64 insertions, 0 deletions
diff --git a/docs/manual/limitations.html b/docs/manual/limitations.html
new file mode 100644
index 0000000..cfe0ff5
--- /dev/null
+++ b/docs/manual/limitations.html
@@ -0,0 +1,64 @@
+<!doctype html PUBLIC "-//W3C//DTD HTML 3.2 Final//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>
+</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>
+
+<li>For efficiency, ProGuard always ignores any <b>private or package visible
+    library classes</b> while reading library jars. If any of them are
+    extended by public library classes, and then extended again by input
+    classes, ProGuard will complain it can't find them. In that case, you'll
+    have to use the <code>-dontskipnonpubliclibraryclasses</code> option, and
+    maybe even the <code>-dontskipnonpubliclibraryclassmembers</code> option.
+    The graphical user interface has checkboxes for these settings.
+    <p>
+
+<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.
+    <p>
+
+<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.
+    <p>
+
+<li>When obfuscating, ProGuard will write out class files named
+    "<code>a.class</code>", "<code>b.class</code>", etc. If there is a large
+    numbers of classes in the same package, it may also write out
+    <b>"<code>aux.class</code>"</b>. Windows doesn't allow creating files with
+    this reserved name (among a few other names), so it's generally better to
+    write the output to a jar, in order to avoid such problems.
+    <p>
+
+</ul>
+<p>
+
+<hr>
+<address>
+Copyright &copy; 2002-2009
+<a href="http://www.graphics.cornell.edu/~eric/">Eric Lafortune</a>.
+</address>
+</body>
+</html>