RubyGems - sometsome - Versions diffs - 3.10.47 → 3.10.50.34 - Mend

sometsome 3.10.47 → 3.10.50.34

Files changed (733) hide show

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

@@ -1,127 +0,0 @@
-<!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 DELETED

@@ -1,60 +0,0 @@
-<!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 DELETED

@@ -1,105 +0,0 @@
-@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 DELETED

@@ -1,729 +0,0 @@
-<!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>