RubyGems - sometsome - Versions diffs - 1.0.2 → 3.10.42 - Mend

sometsome 1.0.2 → 3.10.42

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (732) hide show

data/lib/proguard4.7/docs/manual/retrace/usage.html ADDED

@@ -0,0 +1,127 @@
+<!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>ReTrace Usage</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>Usage</h2>
+You can find the ReTrace jar in the <code>lib</code> directory of the
+ProGuard distribution. To run ReTrace, just type:
+<p>
+<p class="code">
+<code><b>java -jar retrace.jar </b></code>[<i>options...</i>]
+         <i>mapping_file</i> [<i>stacktrace_file</i>]
+</p>
+These are the arguments:
+<dl>
+<dt><i>mapping_file</i></dt>
+<dd>Specifies the name of the mapping file, produced by ProGuard with the
+    option
+    "<a href="../usage.html#printmapping"><code>-printmapping</code></a> <i>mapping_file</i>",
+    while obfuscating the application that produced the stack trace.</dd>
+<dt><i>stacktrace_file</i></dt>
+<dd>Optionally specifies the name of the file containing the stack trace. If
+    no file is specified, a stack trace is read from the standard input. Blank
+    lines and unrecognized lines are ignored, as far as possible.</dd>
+</dl>
+The following options are supported:
+<dl>
+<dt><code><b>-verbose</b></code></dt>
+<dd>Specifies to print out more informative stack traces that include not only
+    method names, but also method return types and arguments.</dd>
+<dt><code><b>-regex</b></code> <i>regular_expression</i></dt>
+<dd>Specifies the regular expression that is used to parse the lines in the
+    stack trace. Specifying a different regular expression allows to
+    de-obfuscate more general types of input than just stack traces. The
+    default is suitable for stack traces produced by most JVMs:
+    <pre>
+    (?:\s*%c:.*)|(?:\s*at\s+%c.%m\s*\(.*?(?::%l)?\)\s*)
+    </pre>
+    The regular expression is a Java regular expression (cfr. the documentation
+    of <code>java.util.regex.Pattern</code>), with a few additional wildcards:
+    <table cellspacing="10">
+    <tr><td valign="top"><code><b>%c</b></code></td>
+        <td>matches a class name (e.g.
+            "<code>myapplication.MyClass</code>").</td></tr>
+    <tr><td valign="top"><code><b>%C</b></code></td>
+        <td>matches a class name with slashes (e.g.
+            "<code>myapplication/MyClass</code>").</td></tr>
+    <tr><td valign="top"><code><b>%t</b></code></td>
+        <td>matches a field type or method return type (e.g.
+            "<code>myapplication.MyClass[]</code>").</td></tr>
+    <tr><td valign="top"><code><b>%f</b></code></td>
+        <td>matches a field name (e.g.
+            "<code>myField</code>").</td></tr>
+    <tr><td valign="top"><code><b>%m</b></code></td>
+        <td>matches a method name (e.g.
+            "<code>myMethod</code>").</td></tr>
+    <tr><td valign="top"><code><b>%a</b></code></td>
+        <td>matches a list of method arguments (e.g.
+            "<code>boolean,int</code>").</td></tr>
+    <tr><td valign="top"><code><b>%l</b></code></td>
+        <td>matches a line number inside a method (e.g.
+            "<code>123</code>").</td></tr>
+    </table>
+    Elements that match these wildcards are de-obfuscated, when possible. Note
+    that regular expressions must not contain any capturing groups. Use
+    non-capturing groups instead: <code>(?:</code>...<code>)</code>
+    </dd>
+</dl>
+The restored stack trace is printed to the standard output. The completeness
+of the restored stack trace depends on the presence of line number tables in
+the obfuscated class files:
+<ul>
+<li>If all line numbers have been preserved while obfuscating the application,
+    ReTrace will be able to restore the stack trace completely.</li>
+<li>If the line numbers have been removed, mapping obfuscated method names
+    back to their original names has become ambiguous. Retrace will list all
+    possible original method names for each line in the stack trace. The user
+    can then try to deduce the actual stack trace manually, based on the logic
+    of the program.</li>
+</ul>
+<p>
+Preserving line number tables is explained in detail in this <a
+href="../examples.html#stacktrace">example</a> in the ProGuard User Manual.
+<p>
+Unobfuscated elements and obfuscated elements for which no mapping is available
+will be left unchanged.
+<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>

data/lib/proguard4.7/docs/manual/sections.html ADDED

@@ -0,0 +1,60 @@
+<!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-script-type" content="text/javascript">
+<meta http-equiv="content-style-type" content="text/css">
+<link rel="stylesheet" type="text/css" href="../style.css">
+<title>Sections</title>
+</head>
+<body class="navigation">
+<ul class="navigation">
+<li><a href="../sections.html">&lt;&lt; Main menu</a></li>
+<li class="title">ProGuard Manual</li>
+<li><a target="main" href="introduction.html">Introduction</a></li>
+<li><a target="main" href="usage.html">Usage</a></li>
+<li><a target="main" href="limitations.html">Limitations</a></li>
+<li><a target="main" href="examples.html">Examples</a></li>
+<li><a target="main" href="troubleshooting.html">Troubleshooting</a></li>
+<li><a target="main" href="refcard.html">Ref Card</a></li>
+<li><a target="main" href="gui.html">GUI</a></li>
+<li><a target="main" href="ant.html">Ant Task</a></li>
+<li><a target="main" href="wtk.html">JME WTK</a></li>
+<li class="title">ReTrace Manual</li>
+<li><a target="main" href="retrace/introduction.html">Introduction</a></li>
+<li><a target="main" href="retrace/usage.html">Usage</a></li>
+<li><a target="main" href="retrace/examples.html">Examples</a></li>
+</ul>
+<p>
+<center>
+<small>With support of</small>
+<p>
+<a href="http://sourceforge.net/projects/proguard/" target="other">
+<script type="text/javascript" language="JavaScript">
+<!--
+document.write("<img src=\"");
+document.write(document.location.hostname == "proguard.sourceforge.net" ?
+  "http://sourceforge.net/sflogo.php?group_id=54750&amp;type=1" :
+  "../sflogo.png");
+document.write("\" width=\"88\" height=\"31\" alt=\"SourceForge\" />");
+//-->
+</script>
+<noscript>
+<img src="../sflogo.png" width="88" height="31" alt="SourceForge" />
+</noscript>
+</a>
+<p>
+<a href="http://www.saikoa.com/" target="_top">
+<img src="../saikoalogo.png" width="88" height="19" alt="Saikoa" /></a>
+</center>
+</body>
+</html>

data/lib/proguard4.7/docs/manual/style.css ADDED

@@ -0,0 +1,105 @@
+@charset "iso-8859-1";
+/* Global settings. */
+body {
+  background: #FFFFFF;
+}
+h1 {
+  text-align: center;
+}
+h2 {
+  background: #EEEEFF;
+  padding: 10px;
+}
+dt {
+  padding: 6px;
+}
+dt div
+{
+  color: grey;
+  float: right;
+}
+dd {
+  padding: 6px;
+}
+pre {
+  padding: 10px;
+  background: #E0E0E0;
+}
+ul.spacious li
+{
+  padding: 8px;
+}
+a
+{
+  text-decoration: none;
+}
+a.button {
+  color: #000000;
+  text-decoration: none;
+  background: #E0E0E0;
+  border: 1px outset #FFFFFF;
+  float: right;
+}
+/* Settings for variable width code. */
+p.code {
+  padding: 10px;
+  background: #E0E0E0;
+}
+/* Settings for diagrams. */
+table.diagram {
+  padding: 8px;
+  border: none;
+  border-spacing: 2px;
+}
+td.transparentblock {
+  text-align: center;
+  padding: 10px 0px;
+}
+td.whiteblock {
+  width: 100px;
+  text-align: center;
+  border: 1px solid #C0C0C0;
+  background: #E0E0E0;
+  padding: 10px 0px;
+}
+td.lightblock {
+  width: 100px;
+  text-align: center;
+  border: 1px solid #8888FF;
+  background: #BBBBFF;
+  padding: 20px 0px;
+}
+td.darkblock {
+  width: 100px;
+  text-align: center;
+  background: #8888FF;
+  padding: 20px 0px;
+}
+/* Settings for buttons. */
+td.button {
+  background: #E0E0E0;
+  border: 1px outset #FFFFFF;
+  font-weight: bold;
+}

data/lib/proguard4.7/docs/manual/troubleshooting.html ADDED

@@ -0,0 +1,729 @@
+<!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 Troubleshooting</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>Troubleshooting</h2>
+While preparing a configuration for processing your code, you may bump into a
+few problems. The following sections discuss some common issues and solutions:
+<h3><a href="#processing">Problems while processing</a></h3>
+<ul>
+<li><a href="#dynamicalclass">Note: can't find dynamically referenced class</a></li>
+<li><a href="#dynamicalclasscast">Note: ... calls '(...)Class.forName(variable).newInstance()'</a></li>
+<li><a href="#dynamicalclassmember">Note: ... accesses a field/method '...' dynamically</a></li>
+<li><a href="#descriptorclass">Note: the configuration keeps the entry point '...', but not the descriptor class '...'</a></li>
+<li><a href="#classmembers">Note: the configuration doesn't specify which class members to keep for class '...'</a></li>
+<li><a href="#duplicateclass">Note: duplicate definition of program/library class</a></li>
+<li><a href="#duplicatezipentry">Warning: can't write resource ... Duplicate zip entry</a></li>
+<li><a href="#unresolvedclass">Warning: can't find superclass or interface</a></li>
+<li><a href="#unresolvedclass">Warning: can't find referenced class</a></li>
+<li><a href="#superclass">Error: Can't find any super classes of ... (not even immediate super class ...)</a></li>
+<li><a href="#superclass">Error: Can't find common super class of ... and ...</a></li>
+<li><a href="#unresolvedclassmember">Warning: can't find referenced field/method</a></li>
+<li><a href="#unresolvedenclosingmethod">Warning: can't find enclosing class/method</a></li>
+<li><a href="#dependency">Warning: library class ... depends on program class ...</a></li>
+<li><a href="#unexpectedclass">Warning: class file ... unexpectedly contains class ...</a></li>
+<li><a href="#mappingconflict1">Warning: ... is not being kept as ..., but remapped to ...</a></li>
+<li><a href="#mappingconflict2">Warning: field/method ... can't be mapped to ...</a></li>
+<li><a href="#unsupportedclassversion">Error: Unsupported class version number</a></li>
+<li><a href="#keep">Error: You have to specify '-keep' options</a></li>
+<li><a href="#filename">Error: Expecting class path separator ';' before 'Files\Java\...' (in Windows)</a></li>
+<li><a href="#macosx">Error: Can't read [.../lib/rt.jar] (No such file or directory) (in MacOS X)</a></li>
+<li><a href="#startinggui">Internal problem starting the ProGuard GUI (Cannot write XdndAware property) (in Linux)</a></li>
+<li><a href="#outofmemoryerror">OutOfMemoryError</a></li>
+<li><a href="#stackoverflowerror">StackOverflowError</a></li>
+<li><a href="#unexpectederror">Unexpected error</a></li>
+<li><a href="#otherwise">Otherwise...</a></li>
+</ul>
+<h3><a href="#afterprocessing">Unexpected observations after processing</a></h3>
+<ul>
+<li><a href="#disappearingclasses">Disappearing classes</a></li>
+<li><a href="#notkept">Classes or class members not being kept</a></li>
+<li><a href="#notobfuscated">Variable names not being obfuscated</a></li>
+</ul>
+<h3><a href="#dalvik">Problems while converting to Android Dalvik bytecode</a></h3>
+<ul>
+<li><a href="#simexception">SimException: local variable type mismatch</a></li>
+<li><a href="#conversionerror">Conversion to Dalvik format failed with error 1</a></li>
+</ul>
+<h3><a href="#preverifying">Problems while preverifying for Java Micro Edition</a></h3>
+<ul>
+<li><a href="#invalidclassexception1">InvalidClassException, class loading error, or verification error</a></li>
+</ul>
+<h3><a href="#runtime">Problems at run-time</a></h3>
+<ul>
+<li><a href="#stacktraces">Stack traces without class names or line numbers</a></li>
+<li><a href="#noclassdeffounderror">NoClassDefFoundError</a></li>
+<li><a href="#classnotfoundexception">ClassNotFoundException</a></li>
+<li><a href="#nosuchmethodexception">NoSuchMethodException</a></li>
+<li><a href="#missingresourceexception">MissingResourceException or NullPointerException</a></li>
+<li><a href="#disappearingannotations">Disappearing annotations</a></li>
+<li><a href="#invalidjarfile">Invalid or corrupt jarfile</a></li>
+<li><a href="#invalidjarindexexception">InvalidJarIndexException: Invalid index</a></li>
+<li><a href="#invalidclassexception2">InvalidClassException, class loading error, or verification error (in Java Micro Edition)</a></li>
+<li><a href="#nosuchfieldormethod">Error: No Such Field or Method, Error verifying method (in a Java Micro Edition emulator)</a></li>
+<li><a href="#failingmidlets">Failing midlets (on a Java Micro Edition device)</a></li>
+<li><a href="#disappearingloops">Disappearing loops</a></li>
+<li><a href="#securityexception">SecurityException: SHA1 digest error</a></li>
+<li><a href="#classcastexception">ClassCastException: class not an enum</a></li><li><a href="#classcastexception">IllegalArgumentException: class not an enum type</a></li>
+<li><a href="#arraystoreexception">ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy</a></li>
+<li><a href="#compilererror">CompilerError: duplicate addition</a></li>
+<li><a href="#classformaterror1">ClassFormatError: repetitive field name/signature</a></li>
+<li><a href="#classformaterror2">ClassFormatError: Invalid index in LocalVariableTable in class file</a></li>
+<li><a href="#nosuchmethoderror">NoSuchMethodError or AbstractMethodError</a></li>
+<li><a href="#verifyerror">VerifyError</a></li>
+</ul>
+<h2><a name="processing">Problems while processing</a></h2>
+ProGuard may print out some notes and non-fatal warnings:
+<dl>
+<dt><a name="dynamicalclass"><b>Note: can't find dynamically referenced class</b></a></dt>
+<dd>ProGuard can't find a class or interface that your code is accessing by
+    means of introspection. You should check if you want to add the jar that
+    contains this class.</dd>
+<dt><a name="dynamicalclasscast"><b>Note: ... calls '(...)Class.forName(variable).newInstance()'</b></a></dt>
+<dd>ProGuard lists all class casts of dynamically created class instances,
+    like "<code>(MyClass)Class.forName(variable).newInstance()</code>".
+    Depending on your application, you may need to keep the mentioned classes
+    with an option like "<code>-keep class MyClass</code>", or their
+    implementations with an option like "<code>-keep class * implements
+    MyClass</code>". You can switch off these notes by specifying the
+    <a href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
+<dt><a name="dynamicalclassmember"><b>Note: ... accesses a field/method '...' dynamically</b></a></dt>
+<dd>ProGuard lists a number of constructs like
+    "<code>.getField("myField")</code>". Depending on your application, you
+    may need to figure out where the mentioned class members are defined and
+    keep them with an option like "<code>-keep class MyClass { MyFieldType
+    myField; }</code>". Otherwise, ProGuard might remove or obfuscate the
+    class members, since it can't know which ones they are exactly. It does
+    list possible candidates, for your information. You can switch off these
+    notes by specifying the <a
+    href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
+<dt><a name="descriptorclass"><b>Note: the configuration keeps the entry point '...', but not the descriptor class '...'</b></a></dt>
+<dd>Your configuration contains a <code>-keep</code> option to preserve the
+    given method (or field), but no <code>-keep</code> option for the given
+    class that is an argument type or return type in the method's descriptor.
+    You may then want to keep the class too. Otherwise, ProGuard will
+    obfuscate its name, thus changing the method's signature. The method might
+    then become unfindable as an entry point, e.g. if it is part of a public
+    API. You can switch off these notes by specifying the <a
+    href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
+<dt><a name="classmembers"><b>Note: the configuration doesn't specify which class members to keep for class '...'</b></a></dt>
+<dd>Your configuration contains
+    a <code>-keepclassmembers/-keepclasseswithmembers</code> option to
+    preserve fields or methods in the given class, but it doesn't specify
+    which fields or methods. This way, the option simply won't have any
+    effect. You probably want to specify one or more fields or methods, as
+    usual between curly braces. You can specify all fields or methods with a
+    wildcard "<code>*;</code>". You can switch off these notes by specifying
+    the <a href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
+<dt><a name="duplicateclass"><b>Note: duplicate definition of program/library class</b></a></dt>
+<dd>Your program jars or library jars contain multiple definitions of the
+    listed classes. ProGuard continues processing as usual, only considering
+    the first definitions. The warning may be an indication of some problem
+    though, so it's advisable to remove the duplicates. A convenient way to do
+    so is by specifying filters on the input jars or library jars. You can
+    switch off these notes by specifying the <a
+    href="usage.html#dontnote"><code>-dontnote</code></a> option.</dd>
+<dt><a name="duplicatezipentry"><b>Warning: can't write resource ... Duplicate zip entry</b></a></dt>
+<dd>Your input jars contain multiple resource files with the same name.
+    ProGuard continues copying the resource files as usual, skipping any files
+    with previously used names. Once more, the warning may be an indication of
+    some problem though, so it's advisable to remove the duplicates. A
+    convenient way to do so is by specifying filters on the input jars. There
+    is no option to switch off these warnings.</dd>
+</dl>
+<p>
+ProGuard may terminate when it encounters parsing errors or I/O errors, or
+some more serious warnings:
+<dl>
+<dt><a name="unresolvedclass"><b>Warning: can't find superclass or interface</b><br/><b>Warning: can't find referenced class</b></a></dt>
+<dd>If there are unresolved references to classes or interfaces, you most
+    likely forgot to specify an essential library. For proper processing, all
+    libraries that are referenced by your code must be specified, including
+    the Java run-time library. For specifying libraries, use
+    the <a href="usage.html#libraryjars"><code>-libraryjars</code></a> option.
+    <p>
+    For example, if ProGuard complains that it can't find a
+    <code>javax.crypto</code> class, you probably still have to specify
+    <code>jce.jar</code>, next to the more common <code>rt.jar</code>.
+    <p>
+    If you're missing a library and you're absolutely sure it isn't used
+    anyway, you can try your luck with the <a
+    href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option,
+    or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a>
+    option. Only use these options if you really know what you're doing
+    though.
+    <p>
+    For example, if you're developing for Android, and ProGuard complains that
+    it can't find a <code>java.awt</code> class, then some library that you
+    are using is referring to <code>java.awt</code>. This is a bit shady, since
+    Android doesn't have this package at all, but if your application works
+    anyway, you can let ProGuard accept it with "<code>-dontwarn
+    java.awt.**</code>".</dd>
+<dt><a name="superclass"><b>Error: Can't find any super classes of ... (not even immediate super class ...)</b><br/><b>Error: Can't find common super class of ... and ...</b></a></dt>
+<dd>It seems like you tried to avoid the warnings from the previous paragraph
+    by specifying
+    <a href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a>
+    or <a href="usage.html#dontwarn"><code>-dontwarn</code></a>, but it didn't
+    work out. ProGuard's optimization step and preverification step really
+    need the missing classes to make sense of the code. Preferably, you would
+    solve the problem by adding the missing library, as discussed. If you're
+    sure the class that references the missing class isn't used either, you
+    could also try filtering it out from the input, by adding a filter to the
+    corresponding <a href="usage.html#injars"><code>-injars</code></a> option:
+    "<code>-injars
+    myapplication.jar(!somepackage/SomeUnusedClass.class)</code>". Hopefully,
+    you can access the configuration of your build process for such a
+    modification. As a final solution, you could switch off optimization
+    (<a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>) and
+    preverification
+    (<a href="usage.html#dontpreverify"><code>-dontpreverify</code></a>).</dd>
+<dt><a name="unresolvedclassmember"><b>Warning: can't find referenced field/method</b></a></dt>
+<dd>If there are unresolved references to class members in input classes, your
+    class files are most likely inconsistent. Possibly, some class file didn't
+    get recompiled properly, or some class file was left behind after its
+    source file was removed. Try removing all class files, recompiling them,
+    zipping them up, and running ProGuard again.
+    <p>
+    If your program classes reside in the same packages as library classes,
+    and refer to their package visible class members, then you should also
+    specify the
+    <a href="usage.html#dontskipnonpubliclibraryclassmembers"><code>-dontskipnonpubliclibraryclassmembers</code></a>
+    option.</dd>
+<dt><a name="unresolvedenclosingmethod"><b>Warning: can't find enclosing class/method</b></a></dt>
+<dd>If there are unresolved references to classes that are defined inside
+    methods in your input, once more, your class files are most likely
+    inconsistent. Possibly, some class file didn't get recompiled properly, or
+    some class file was left behind after its source file was removed. Try
+    removing all class files, recompiling them, zipping them up, and running
+    ProGuard again.</dd>
+<dt><a name="dependency"><b>Warning: library class ... depends on program class ...</b></a></dt>
+<dd>If any of your library classes depend on your program classes, by
+    extending, implementing or just referencing them, your processed code will
+    generally be unusable. Program classes can depend on library classes, but
+    not the other way around. Program classes are processed, while library
+    classes always remain unchanged. It is therefore impossible to adapt
+    references from library classes to program classes, for instance if the
+    program classes are renamed. You should define a clean separation between
+    program code (specified with <a
+    href="usage.html#injars"><code>-injars</code></a>) and library code
+    (specified with <a
+    href="usage.html#libraryjars"><code>-libraryjars</code></a>), and try
+    again.</dd>
+<dt><a name="unexpectedclass"><b>Warning: class file ... unexpectedly contains class ...</b></a></dt>
+<dd>The given class file contains a definition for the given class, but the
+    directory name of the file doesn't correspond to the package name of the
+    class. ProGuard will accept the class definition, but the current
+    implementation will not write out the processed version. Please make sure
+    your input classes are packaged correctly. Notably, class files that are
+    in the <code>WEB-INF/classes</code> directory in a war should be packaged
+    in a jar and put in the <code>WEB-INF/lib</code> directory. If you don't
+    mind these classes not being written to the output, you can specify the <a
+    href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option,
+    or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a>
+    option.</dd>
+<dt><a name="mappingconflict1"><b>Warning: ... is not being kept as ..., but remapped to ...</b></a></dt>
+<dd>There is a conflict between a <code>-keep</code> option in the
+    configuration, and the mapping file, in the obfuscation step. The given
+    class name or class member name can't be kept by its original name, as
+    specified in the configuration, but it has to be mapped to the other given
+    name, as specified in the mapping file. You should adapt your
+    configuration or your mapping file to remove the conflict. Alternatively,
+    if you're sure the renaming won't hurt, you can specify the <a
+    href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option,
+    or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a>
+    option.</dd>
+<dt><a name="mappingconflict2"><b>Warning: field/method ... can't be mapped to ...</b></a></dt>
+<dd>There is a conflict between some new program code and the mapping file, in
+    the obfuscation step. The given class member can't be mapped to the given
+    name, because it would conflict with another class member that is already
+    being mapped to the same name. This can happen if you are performing
+    incremental obfuscation, applying an obfuscation mapping file from an
+    initial obfuscation step. For instance, some new class may have been added
+    that extends two existing classes, introducing a conflict in the name
+    space of its class members. If you're sure the class member receiving
+    another name than the one specified won't hurt, you can specify the <a
+    href="usage.html#ignorewarnings"><code>-ignorewarnings</code></a> option,
+    or even the <a href="usage.html#dontwarn"><code>-dontwarn</code></a>
+    option. Note that you should always use the <a
+    href="usage.html#useuniqueclassmembernames"><code>-useuniqueclassmembernames</code></a>
+    option in the initial obfuscation step, in order to reduce the risk of
+    conflicts.</dd>
+<dt><a name="unsupportedclassversion"><b>Error: Unsupported class version number</b></a></dt>
+<dd>You are trying to process class files compiled for a recent version of
+    Java that your copy of ProGuard doesn't support yet. You should check if
+    there is a more recent release
+    <a href="http://proguard.sourceforge.net/downloads.html">on-line</a>.</dd>
+<dt><a name="keep"><b>Error: You have to specify '-keep' options</b></a></dt>
+<dd>You either forgot to specify <a
+    href="usage.html#keep"><code>-keep</code></a> options, or you mistyped the
+    class names. ProGuard has to know exactly what you want to keep: an
+    application, an applet, a servlet, a midlet,..., or any combination of
+    these. Without the proper seed specifications, ProGuard would shrink,
+    optimize, or obfuscate all class files away.</dd>
+<dt><a name="filename"><b>Error: Expecting class path separator ';' before 'Files\Java\</b>...<b>'</b> (in Windows)</a></dt>
+<dd>If the path of your run-time jar contains spaces, like in "Program Files",
+    you have to enclose it with single or double quotes, as explained in the
+    section on <a href="usage.html#filename">file names</a>. This is actually
+    true for all file names containing special characters, on all
+    platforms.</dd>
+<dt><a name="macosx"><b>Error: Can't read [</b>...<b>/lib/rt.jar] (No such file or directory)</b> (in MacOS X)</a></dt>
+<dd>In MacOS X, the run-time classes may be in a different place than on most
+    other platforms. You'll then have to adapt your configuration, replacing
+    the path <code>&lt;java.home&gt;/lib/rt.jar</code> by
+    <code>&lt;java.home&gt;/../Classes/classes.jar</code>.</dd>
+<dt><a name="startinggui"><b>Internal problem starting the ProGuard GUI (Cannot write XdndAware property)</b> (in Linux)</a></dt>
+<dd>In Linux, at least with Java 6, the GUI may not start properly, due to
+    <a href="http://bugs.sun.com/view_bug.do?bug_id=7027598">Sun
+    Bug #7027598</a>. The work-around at this time is to specify the JVM
+   option <code>-DsuppressSwingDropSupport=true</code> when running the
+   GUI.</dd>
+<dd>
+</dl>
+<p>
+Should ProGuard crash while processing your application:
+<dl>
+<dt><a name="outofmemoryerror"><b>OutOfMemoryError</b></a></dt>
+<dd>You can try increasing the heap size of the Java virtual machine (with the
+    usual <code>-Xms</code> and <code>-Xmx</code> options). You can also
+    reduce the amount of memory that ProGuard needs by removing unnecessary
+    library jars from your configuration, or by filtering out unused library
+    packages and classes. Remember that only classes or interfaces that are
+    extended or implemented by classes in your input jars are required.</dd>
+<dt><a name="stackoverflowerror"><b>StackOverflowError</b></a></dt>
+<dd>This error might occur when processing a large code base on Windows
+    (surprisingly, not so easily on Linux). In theory, increasing the stack
+    size of the Java virtual machine (with the usual <code>-Xss</code> option)
+    should help too. In practice however, the <code>-Xss</code> setting
+    doesn't have any effect on the main thread, due to <a
+    href="http://bugs.sun.com/view_bug.do?bug_id=4362291">Sun Bug
+    #4362291</a>. As a result, this solution will only work when running
+    ProGuard in a different thread, e.g. from its GUI.</dd>
+<dt><a name="unexpectederror"><b>Unexpected error</b></a></dt>
+<dd>ProGuard has encountered an unexpected condition, typically in the
+    optimization step. It may or may not recover. You should be able to avoid
+    it using the <a
+    href="usage.html#dontoptimize"><code>-dontoptimize</code></a> option. In
+    any case, please report the problem, preferably with the simplest example
+    that causes ProGuard to crash.</dd>
+<dt><a name="otherwise"><b>Otherwise...</b></a></dt>
+<dd>Maybe your class files are corrupt. See if recompiling them and trying
+    again helps. If not, please report the problem, preferably with the
+    simplest example that causes ProGuard to crash.</dd>
+</dl>
+<p>
+<h2><a name="afterprocessing">Unexpected observations after processing</a></h2>
+If ProGuard seems to run fine, but your processed code doesn't look right,
+there might be a couple of reasons:
+<dl>
+<dt><a name="disappearingclasses"><b>Disappearing classes</b></a></dt>
+<dd>If you are working on Windows and it looks like some classes have
+    disappeared from your output, you should make sure you're not writing your
+    output class files to a directory (or unpacking the output jar). On
+    platforms with case-insensitive file systems, such as Windows, unpacking
+    tools often let class files with similar lower-case and upper-case names
+    overwrite each other. If you really can't switch to a different operating
+    system, you could consider using ProGuard's <a
+    href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a>
+    option.
+    <p>
+    Also, you should make sure your class files are in directories that
+    correspond to their package names. ProGuard will read misplaced class
+    files, but it will currently not write their processed versions. Notably,
+    class files that are in the <code>WEB-INF/classes</code> directory in a
+    war should be packaged in a jar and put in the <code>WEB-INF/lib</code>
+    directory.</dd>
+<dt><a name="notkept"><b>Classes or class members not being kept</b></a></dt>
+<dd>If ProGuard is not keeping the right classes or class members, make sure
+    you are using fully qualified class names. If the package name of some
+    class is missing, ProGuard won't match the elements that you might be
+    expecting. It may help to double-check for typos too. You can use the <a
+    href="usage.html#printseeds"><code>-printseeds</code></a> option to see
+    which elements are being kept exactly.
+    <p>
+    If you are using marker interfaces to keep other classes, the marker
+    interfaces themselves are probably being removed in the shrinking step.
+    You should therefore always explicitly keep any marker interfaces, with
+    an option like "<code>-keep interface MyMarkerInterface</code>".
+    <p>
+    Similarly, if you are keeping classes based on annotations, you may have to
+    avoid that the annotation classes themselves are removed in the shrinking
+    step. You can explicitly keep all annotation classes in your program code
+    with an option like "<code>-keep @interface *</code>".<dd>
+<dt><a name="notobfuscated"><b>Variable names not being obfuscated</b></a></dt>
+<dd>If the names of the local variables and parameters in your obfuscated code
+    don't look obfuscated, because they suspiciously resemble the names of
+    their types, it's probably because the decompiler that you are using is
+    coming up with those names. ProGuard's obfuscation step does remove the
+    original names entirely, unless you explicitly keep the
+    <code>LocalVariableTable</code> or <code>LocalVariableTypeTable</code>
+    attributes.</dd>
+</dl>
+<h2><a name="dalvik">Problems while converting to Android Dalvik bytecode</a></h2>
+If ProGuard seems to run fine, but the dx tool in the Android SDK subsequently
+fails with an error:
+<dl>
+<dt><a name="simexception"><b>SimException: local variable type mismatch</b></a></dt>
+<dd>This error indicates that ProGuard's optimization step has not been able
+    to maintain the correct debug information about local variables. This can
+    happen if some code is optimized radically. Possible work-arounds: let the
+    java compiler not produce debug information (<code>-g:none</code>), or let
+    ProGuard's obfuscation step remove the debug information again
+    (by <i>not</i> keeping the attributes <code>LocalVariableTable</code>
+    and <code>LocalVariableTypeTable</code>
+    with <a href="usage.html#keepattributes"><code>-keepattributes</code></a>),
+    or otherwise just disable optimization
+    (<a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>).</dd>
+<dt><a name="conversionerror"><b>Conversion to Dalvik format failed with error 1</b></a></dt>
+<dd>This error may have various causes, but if dx is tripping over some code
+    processed by ProGuard, you should make sure that you are using the latest
+    version of ProGuard. You can just copy the ProGuard jars
+    to <code>android-sdk/tools/proguard/lib</code>. If that doesn't help,
+    please report the problem, preferably with the simplest example that still
+    brings out the error.</dd>
+</dl>
+<h2><a name="preverifying">Problems while preverifying for Java Micro Edition</a></h2>
+If ProGuard seems to run fine, but the external preverifier subsequently
+produces errors, it's usually for a single reason:
+<dl>
+<dt><a name="invalidclassexception1"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b></a></dt>
+<dd>If you get any such message from the preverifier, you are probably working
+    on a platform with a case-insensitive file system, such as Windows. The
+    <code>preverify</code> tool always unpacks the jars, so class files with
+    similar lower-case and upper-case names overwrite each other. You can use
+    ProGuard's <a
+    href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a>
+    option to work around this problem.
+    <p>
+    If the above doesn't help, there is probably a bug in the optimization
+    step of ProGuard. Make sure you are using the latest version. You should
+    be able to work around the problem by using the <a
+    href="usage.html#dontoptimize"><code>-dontoptimize</code></a> option. You
+    can check the bug database to see if it is a known problem (often with a
+    fix). Otherwise, please report it, preferably with the simplest example on
+    which you can find ProGuard to fail.</dd>
+</dl>
+Note that it is no longer necessary to use an external preverifier. With the
+<a href="usage.html#microedition"><code>-microedition</code></a> option,
+ProGuard will preverify the class files for Java Micro Edition.
+<p>
+<h2><a name="runtime">Problems at run-time</a></h2>
+If ProGuard runs fine, but your processed application doesn't work, there
+might be several reasons:
+<dl>
+<dt><a name="stacktraces"><b>Stack traces without class names or line numbers</b></a></dt>
+<dd>If your stack traces don't contain any class names or lines numbers,
+    even though you are keeping the proper attributes, make sure this debugging
+    information is present in your compiled code to start with. Notably the Ant
+    javac task has debugging information switched off by default.</dd>
+<dt><a name="noclassdeffounderror"><b>NoClassDefFoundError</b></a></dt>
+<dd>Your class path is probably incorrect. It should at least contain all
+    library jars and, of course, your processed program jar.</dd>
+<dt><a name="classnotfoundexception"><b>ClassNotFoundException</b></a></dt>
+<dd>Your code is probably calling <code>Class.forName</code>, trying to create
+    the missing class dynamically. ProGuard can only detect constant name
+    arguments, like <code>Class.forName("mypackage.MyClass")</code>. For
+    variable name arguments like <code>Class.forName(someClass)</code>, you
+    have to keep all possible classes using the appropriate <a
+    href="usage.html#keep"><code>-keep</code></a> option, e.g. "<code>-keep
+    class mypackage.MyClass</code>" or "<code>-keep class * implements
+    mypackage.MyInterface</code>".</dd>
+<dt><a name="nosuchmethodexception"><b>NoSuchMethodException</b></a></dt>
+<dd>Your code is probably calling something like
+    <code>myClass.getMethod</code>, trying to find some method dynamically.
+    Since ProGuard can't always detect this automatically, you have to keep
+    the missing method in using the appropriate <a
+    href="usage.html#keep"><code>-keep</code></a> option, e.g. "<code>-keep
+    class mypackage.MyClass { void myMethod(); }</code>".
+    <p>
+    More specifically, if the method reported as missing is
+    <code>values</code> or <code>valueOf</code>, you probably have to keep
+    some methods related to <a
+    href="examples.html#enumerations">enumerations</a>.</dd>
+<dt><a name="missingresourceexception"><b>MissingResourceException</b> or <b>NullPointerException</b></a></dt>
+<dd>Your processed code may be unable to find some resource files. ProGuard
+    simply copies resource files over from the input jars to the output jars.
+    Their names and contents remain unchanged, unless you specify the options
+    <a
+    href="usage.html#adaptresourcefilenames"><code>-adaptresourcefilenames</code></a>
+    and/or <a
+    href="usage.html#adaptresourcefilecontents"><code>-adaptresourcefilecontents</code></a>.
+    <p>
+    Furthermore, directory entries in jar files aren't copied, unless you
+    specify the option <a
+    href="usage.html#keepdirectories"><code>-keepdirectories</code></a>.
+    Note that Sun advises against calling <code>Class.getResource()</code> for
+    directories (<a href="http://bugs.sun.com/view_bug.do?bug_id=4761949">Sun
+    Bug #4761949</a>).</dd>
+<dt><a name="disappearingannotations"><b>Disappearing annotations</b></a></dt>
+<dd>By default, the obfuscation step removes all annotations. If your
+    application relies on annotations to function properly, you should
+    explicitly keep them with
+    <code><a href="usage.html#keepattributes">-keepattributes</a>
+    *Annotation*</code>.</dd>
+<dt><a name="invalidjarfile"><b>Invalid or corrupt jarfile</b></a></dt>
+<dd>You are probably starting your application with the java option
+    <code>-jar</code> instead of the option <code>-classpath</code>. The java
+    virtual machine returns with this error message if your jar doesn't
+    contain a manifest file (<code>META-INF/MANIFEST.MF</code>), if the
+    manifest file doesn't specify a main class (<code>Main-Class:</code> ...),
+    or if the jar doesn't contain this main class. You should then make sure
+    that the input jar contains a valid manifest file to start with, that this
+    manifest file is the one that is copied (the first manifest file that is
+    encountered), and that the main class is kept in your configuration,</dd>
+<dt><a name="invalidjarindexexception"><b>InvalidJarIndexException: Invalid index</b></a></dt>
+<dd>At least one of your processed jar files contains an index file
+    <code>META-INF/INDEX.LIST</code>, listing all class files in the jar.
+    ProGuard by default copies files like these unchanged. ProGuard may however
+    remove or rename classes, thus invalidating the file. You should filter the
+    index file out of the input
+    (<code>-injars in.jar(!META-INF/INDEX.LIST)</code>) or update the file
+    after having applied ProGuard (<code>jar -i out.jar</code>).
+    </dd>
+<dt><a name="invalidclassexception2"><b>InvalidClassException</b>, <b>class loading error</b>, or <b>verification error</b> (in Java Micro Edition)</a></dt>
+<dd>If you get such an error in Java Micro Edition, you may have forgotten to
+    specify the <a
+    href="usage.html#microedition"><code>-microedition</code></a> option, so
+    the processed class files are preverified properly.</dd>
+<dt><a name="nosuchfieldormethod"><b>Error: No Such Field or Method</b>, <b>Error verifying method</b> (in a Java Micro Edition emulator)</a></dt>
+<dd>If you get such a message in a Motorola or Sony Ericsson phone emulator,
+    it's because these emulators don't like packageless classes and/or
+    overloaded fields and methods. You can work around it by not using the
+    options <code><a href="usage.html#repackageclasses">-repackageclasses</a>
+    ''</code> and <a
+    href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a>.
+    If you're using the JME WTK plugin, you can adapt the configuration
+    <code>proguard/wtk/default.pro</code> that's inside the
+    <code>proguard.jar</code>.</dd>
+<dt><a name="failingmidlets"><b>Failing midlets</b> (on a Java Micro Edition device)</a></dt>
+<dd>If your midlet runs in an emulator and on some devices, but not on some
+    other devices, this is probably due to a bug in the latter devices. For
+    some older Motorola and Nokia phones, you might try specifying the <a
+    href="usage.html#useuniqueclassmembernames"><code>-useuniqueclassmembernames</code></a>
+    option. It avoids overloading class member names, which triggers a bug in
+    their java virtual machine.
+    <p>
+    You might also try using the <a
+    href="usage.html#dontusemixedcaseclassnames"><code>-dontusemixedcaseclassnames</code></a>
+    option. Even if the midlet has been properly processed and then
+    preverified on a case-sensitive file system, the device itself might not
+    like the mixed-case class names. Notably, the Nokia N-Gage emulator works
+    fine, but the actual device seems to exhibit this problem.</dd>
+<dt><a name="disappearingloops"><b>Disappearing loops</b></a></dt>
+<dd>If your code contains empty busy-waiting loops, ProGuard's optimization
+    step may remove them. More specifically, this happens if a loop
+    continuously checks the value of a non-volatile field that is changed in a
+    different thread. The specifications of the Java Virtual Machine require
+    that you always mark fields that are accessed across different threads
+    without further synchronization as <code>volatile</code>. If this is not
+    possible for some reason, you'll have to switch off optimization using the
+    <a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>
+    option.</dd>
+<dt><a name="securityexception"><b>SecurityException: SHA1 digest error</b></a></dt>
+<dd>You may have forgotten to sign your program jar <i>after</i> having
+    processed it with ProGuard.</dd>
+<dt><a name="classcastexception"><b>ClassCastException: class not an enum</b>, or <br /><b>IllegalArgumentException: class not an enum type</b></a></dt>
+<dd>You should make sure you're preserving the special methods of enumeration
+    types, which the run-time environment calls by introspection. The required
+    options are shown in the <a
+    href="examples.html#enumerations">examples</a>.</dd>
+<dt><a name="arraystoreexception"><b>ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy</b></a></dt>
+<dd>You are probably processing annotations involving enumerations. Again, you
+    should make sure you're preserving the special methods of the enumeration
+    type, as shown in the examples.</dd>
+<dt><a name="compilererror"><b>CompilerError: duplicate addition</b></a></dt>
+<dd>You are probably compiling or running some code that has been obfuscated
+    with the <a
+    href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a>
+    option. This option triggers a bug in
+    <code>sun.tools.java.MethodSet.add</code> in Sun's JDK 1.2.2, which is
+    used for (dynamic) compilation. You should then avoid this option.</dd>
+<dt><a name="classformaterror1"><b>ClassFormatError: repetitive field name/signature</b></a></dt>
+<dd>You are probably processing some code that has been obfuscated before with
+    the <a
+    href="usage.html#overloadaggressively"><code>-overloadaggressively</code></a>
+    option. You should then use the same option again in the second processing
+    round.</dd>
+<dt><a name="classformaterror2"><b>ClassFormatError: Invalid index in LocalVariableTable in class file</b></a></dt>
+<dd>If you are keeping the <code>LocalVariableTable</code> or
+    <code>LocalVariableTypeTable</code> attributes, ProGuard's optimizing step
+    is sometimes unable to update them consistently. You should then let the
+    obfuscation step remove these attributes or disable the optimization
+    step.</dd>
+<dt><a name="nosuchmethoderror"><b>NoSuchMethodError</b> or <b>AbstractMethodError</b></a></dt>
+<dd>You should make sure you're not writing your output class files to a
+    directory on a platform with a case-insensitive file system, such as
+    Windows. Please refer to the section about <a
+    href="#disappearingclasses">disappearing classes</a> for details.
+    <p>
+    Furthermore, you should check whether you have specified your program jars
+    and library jars properly. Program classes can refer to library classes,
+    but not the other way around.
+    <p>
+    If all of this seems ok, perhaps there's a bug in ProGuard (gasp!). If so,
+    please report it, preferably with the simplest example on which you can
+    find ProGuard to fail.</dd>
+<dt><a name="verifyerror"><b>VerifyError</b></a></dt>
+<dd>Verification errors when executing a program are almost certainly the
+    result of a bug in the optimization step of ProGuard. Make sure you are
+    using the latest version. You should be able to work around the problem by
+    using the <a href="usage.html#dontoptimize"><code>-dontoptimize</code></a>
+    option. You can check the bug database to see if it is a known problem
+    (often with a fix). Otherwise, please report it, preferably with the
+    simplest example on which ProGuard fails.</dd>
+</dl>
+<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>