RubyGems - sometsome - Versions diffs - 3.10.50 → 3.10.50.33 - Mend

sometsome 3.10.50 → 3.10.50.33

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 (733) hide show

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

@@ -1,1243 +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 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>
-To run ProGuard, just type:
-<p class="code">
-<code><b>java -jar proguard.jar </b></code><i>options</i> ...
-</p>
-You can find the ProGuard jar in the <code>lib</code> directory of the
-ProGuard distribution. Alternatively, the <code>bin</code> directory contains
-some short Linux and Windows scripts containing this command. Typically, you'll
-put most options in a configuration file (say, <code>myconfig.pro</code>), and
-just call:
-<p class="code">
-<code><b>java -jar proguard.jar @myconfig.pro</b></code>
-</p>
-You can combine command line options and options from configuration files. For
-instance:
-<p class="code">
-<code><b>java -jar proguard.jar @myconfig.pro -verbose</b></code>
-</p>
-<p>
-You can add comments in a configuration file, starting with a
-<code><b>#</b></code> character and continuing until the end of the line.
-<p>
-Extra whitespace between words and delimiters is ignored. File names with
-spaces or special characters should be quoted with single or double quotes.
-<p>
-Options can be grouped arbitrarily in arguments on the command line and in
-lines in configuration files. This means that you can quote arbitrary sections
-of command line options, to avoid shell expansion of special characters, for
-instance.
-<p>
-The order of the options is generally irrelevant. For quick experiments, you
-can abbreviate them to their first unique characters.
-<p>
-The sections below provide more details:
-<ul>
-<li><a href="#iooptions">Input/Output Options</a></li>
-<li><a href="#keepoptions">Keep Options</a></li>
-<li><a href="#shrinkingoptions">Shrinking Options</a></li>
-<li><a href="#optimizationoptions">Optimization Options</a></li>
-<li><a href="#obfuscationoptions">Obfuscation Options</a></li>
-<li><a href="#preverificationoptions">Preverification Options</a></li>
-<li><a href="#generaloptions">General Options</a></li>
-<li><a href="#classpath">Class Paths</a></li>
-<li><a href="#filename">File Names</a></li>
-<li><a href="#filefilters">File Filters</a></li>
-<li><a href="#filters">Filters</a></li>
-<li><a href="#keepoverview">Overview of <code>Keep</code> Options</a></li>
-<li><a href="#keepoptionmodifiers">Keep Option Modifiers</a></li>
-<li><a href="#classspecification">Class Specifications</a></li>
-</ul>
-<h2><a name="iooptions">Input/Output Options</a></h2>
-<dl>
-<dt><a name="at"><code><b>@</b></code></a><a href="#filename"><i>filename</i></a></dt>
-<dd>Short for '<a href="#include"><code>-include</code></a>
-     <a href="#filename"><i>filename</i></a>'.</dd>
-<dt><a name="include"><code><b>-include</b></code></a>
-    <a href="#filename"><i>filename</i></a></dt>
-<dd>Recursively reads configuration options from the given file
-    <i>filename</i>.</dd>
-<dt><a name="basedirectory"><code><b>-basedirectory</b></code></a>
-    <a href="#filename"><i>directoryname</i></a></dt>
-<dd>Specifies the base directory for all subsequent relative file names in
-    these configuration arguments or this configuration file.</dd>
-<dt><a name="injars"><code><b>-injars</b></code></a>
-    <a href="#classpath"><i>class_path</i></a></dt>
-<dd>Specifies the input jars (or wars, ears, zips, or directories) of the
-    application to be processed. The class files in these jars will be
-    processed and written to the output jars. By default, any non-class files
-    will be copied without changes. Please be aware of any temporary files
-    (e.g. created by IDEs), especially if you are reading your input files
-    straight from directories. The entries in the class path can be filtered,
-    as explained in the <a href="#filefilters">filters</a> section. For better
-    readability, class path entries can be specified using multiple
-    <code>-injars</code> options.</dd>
-<dt><a name="outjars"><code><b>-outjars</b></code></a>
-    <a href="#classpath"><i>class_path</i></a></dt>
-<dd>Specifies the names of the output jars (or wars, ears, zips, or
-    directories). The processed input of the preceding <code>-injars</code>
-    options will be written to the named jars. This allows you to collect the
-    contents of groups of input jars into corresponding groups of output jars.
-    In addition, the output entries can be filtered, as explained in
-    the <a href="#filefilters">filters</a> section. Each processed class file
-    or resource file is then written to the first output entry with a matching
-    filter, within the group of output jars.
-    <p>
-    You must avoid letting the output files overwrite any input files. For
-    better readability, class path entries can be specified using multiple
-    <code>-outjars</code> options. Without any <code>-outjars</code> options,
-    no jars will be written.</dd>
-<dt><a name="libraryjars"><code><b>-libraryjars</b></code></a>
-    <a href="#classpath"><i>class_path</i></a></dt>
-<dd>Specifies the library jars (or wars, ears, zips, or directories) of the
-    application to be processed. The files in these jars will not be included
-    in the output jars. The specified library jars should at least contain the
-    class files that are <i>extended</i> by application class files. Library
-    class files that are only <i>called</i> needn't be present, although their
-    presence can improve the results of the optimization step. The entries in
-    the class path can be filtered, as explained in the <a
-    href="#filefilters">filters</a> section. For better readability, class path
-    entries can be specified using multiple <code>-libraryjars</code> options.
-    <p>
-    Please note that the boot path and the class path set for running ProGuard
-    are not considered when looking for library classes. This means that you
-    explicitly have to specify the run-time jar that your code will use.
-    Although this may seem cumbersome, it allows you to process applications
-    targeted at different run-time environments. For example, you can process
-    <a href="examples.html#application">J2SE applications</a> as well as <a
-    href="examples.html#midlet">JME midlets</a>, just by specifying the
-    appropriate run-time jar.</dd>
-<dt><a name="skipnonpubliclibraryclasses"><code><b>-skipnonpubliclibraryclasses</b></code></a></dt>
-<dd>Specifies to skip non-public classes while reading library jars, to speed
-    up processing and reduce memory usage of ProGuard. By default, ProGuard
-    reads non-public and public library classes alike. However, non-public
-    classes are often not relevant, if they don't affect the actual program
-    code in the input jars. Ignoring them then speeds up ProGuard, without
-    affecting the output. Unfortunately, some libraries, including recent JSE
-    run-time libraries, contain non-public library classes that are extended
-    by public library classes. You then can't use this option. ProGuard will
-    print out warnings if it can't find classes due to this option being
-    set.</dd>
-<dt><a name="dontskipnonpubliclibraryclasses"><code><b>-dontskipnonpubliclibraryclasses</b></code></a></dt>
-<dd>Specifies not to ignore non-public library classes. As of version 4.5, this
-    is the default setting.</dd>
-<dt><a name="dontskipnonpubliclibraryclassmembers"><code><b>-dontskipnonpubliclibraryclassmembers</b></code></a></dt>
-<dd>Specifies not to ignore package visible library class members (fields and
-    methods). By default, ProGuard skips these class members while parsing
-    library classes, as program classes will generally not refer to them.
-    Sometimes however, program classes reside in the same packages as library
-    classes, and they do refer to their package visible class members. In
-    those cases, it can be useful to actually read the class members, in order
-    to make sure the processed code remains consistent.</dd>
-<dt><a name="keepdirectories"><code><b>-keepdirectories</b></code></a>
-    [<i><a href="#filefilters">directory_filter</a></i>]</dt>
-<dd>Specifies the directories to be kept in the output jars (or wars, ears, or
-    directories). By default, directory entries are removed. This reduces the
-    jar size, but it may be undesirable if the program code tries to find them
-    with constructs like "<code>MyClass.class.getResource("")</code>". If the
-    option is specified without a filter, all directories are kept. With a
-    filter, only matching directories are kept.</dd>
-<dt><a name="target"><code><b>-target</b></code></a> <i>version</i></dt>
-<dd>Specifies the version number to be set in the processed class files. The
-    version number can be one of <code>1.0</code>, <code>1.1</code>,
-    <code>1.2</code>, <code>1.3</code>, <code>1.4</code>, <code>1.5</code> (or
-    just <code>5</code>), <code>1.6</code> (or just <code>6</code>), or
-     <code>1.7</code> (or just <code>7</code>). By default, the version numbers
-    of the class files are left unchanged. For example, you may want to
-    <a href="examples.html#upgrade">upgrade class files to Java 6</a>, by
-    changing their version numbers and having them preverified.</dd>
-<dt><a name="forceprocessing"><code><b>-forceprocessing</b></code></a></dt>
-<dd>Specifies to process the input, even if the output seems up to date. The
-    up-to-dateness test is based on a comparison of the date stamps of the
-    specified input, output, and configuration files or directories.</dd>
-</dl>
-<p>
-<h2><a name="keepoptions">Keep Options</a></h2>
-<dl>
-<dt><a name="keep"><code><b>-keep</b></code></a>
-    [<a href="#keepoptionmodifiers">,<i>modifier</i></a>,...]
-    <a href="#classspecification"><i>class_specification</i></a></dt>
-<dd>Specifies classes and class members (fields and methods) to be preserved
-    as entry points to your code. For example, in order to <a
-    href="examples.html#application">keep an application</a>, you can specify
-    the main class along with its main method. In order to <a
-    href="examples.html#library">process a library</a>, you should specify all
-    publicly accessible elements.</dd>
-<dt><a name="keepclassmembers"><code><b>-keepclassmembers</b></code></a>
-    [<a href="#keepoptionmodifiers">,<i>modifier</i></a>,...]
-    <a href="#classspecification"><i>class_specification</i></a></dt>
-<dd>Specifies class members to be preserved, if their classes are preserved as
-    well. For example, you may want to <a
-    href="examples.html#serializable">keep all serialization fields and
-    methods</a> of classes that implement the <code>Serializable</code>
-    interface.</dd>
-<dt><a name="keepclasseswithmembers"><code><b>-keepclasseswithmembers</b></code></a>
-    [<a href="#keepoptionmodifiers">,<i>modifier</i></a>,...]
-    <a href="#classspecification"><i>class_specification</i></a></dt>
-<dd>Specifies classes and class members to be preserved, on the condition that
-    all of the specified class members are present. For example, you may want
-    to <a href="examples.html#applications">keep all applications</a> that
-    have a main method, without having to list them explicitly.</dd>
-<dt><a name="keepnames"><code><b>-keepnames</b></code></a>
-    <a href="#classspecification"><i>class_specification</i></a></dt>
-<dd>Short for <a href="#keep"><code>-keep</code></a>,<a href="#allowshrinking"><code>allowshrinking</code></a>
-    <a href="#classspecification"><i>class_specification</i></a>
-    <p>
-    Specifies classes and class members whose names are to be preserved, if
-    they aren't removed in the shrinking phase. For example, you may want to
-    <a href="examples.html#serializable">keep all class names</a> of classes
-    that implement the <code>Serializable</code> interface, so that the
-    processed code remains compatible with any originally serialized classes.
-    Classes that aren't used at all can still be removed. Only applicable when
-    obfuscating.</dd>
-<dt><a name="keepclassmembernames"><code><b>-keepclassmembernames</b></code></a>
-    <a href="#classspecification"><i>class_specification</i></a></dt>
-<dd>Short for <a href="#keepclassmembers"><code>-keepclassmembers</code></a>,<a href="#allowshrinking"><code>allowshrinking</code></a>
-    <a href="#classspecification"><i>class_specification</i></a>
-    <p>
-    Specifies class members whose names are to be preserved, if they aren't
-    removed in the shrinking phase. For example, you may want to preserve the
-    name of the synthetic <code>class$</code> methods
-    when <a href="examples.html#library">processing a library</a> compiled by
-    JDK 1.2 or older, so obfuscators can detect it again when processing an
-    application that uses the processed library (although ProGuard itself
-    doesn't need this). Only applicable when obfuscating.</dd>
-<dt><a name="keepclasseswithmembernames"><code><b>-keepclasseswithmembernames</b></code></a>
-    <a href="#classspecification"><i>class_specification</i></a></dt>
-<dd>Short for <a href="#keepclasseswithmembers"><code>-keepclasseswithmembers</code></a>,<a href="#allowshrinking"><code>allowshrinking</code></a>
-    <a href="#classspecification"><i>class_specification</i></a>
-    <p>
-    Specifies classes and class members whose names are to be preserved, on
-    the condition that all of the specified class members are present after
-    the shrinking phase. For example, you may want to <a
-    href="examples.html#native">keep all native method names</a> and the names
-    of their classes, so that the processed code can still link with the
-    native library code. Native methods that aren't used at all can still be
-    removed. If a class file is used, but none of its native methods are, its
-    name will still be obfuscated. Only applicable when obfuscating.</dd>
-<dt><a name="printseeds"><code><b>-printseeds</b></code></a>
-    [<a href="#filename"><i>filename</i></a>]</dt>
-<dd>Specifies to exhaustively list classes and class members matched by the
-    various <code>-keep</code> options. The list is printed to the standard
-    output or to the given file. The list can be useful to verify if the
-    intended class members are really found, especially if you're using
-    wildcards. For example, you may want to list all the <a
-    href="examples.html#applications">applications</a> or all the <a
-    href="examples.html#applets">applets</a> that you are keeping.</dd>
-</dl>
-<p>
-<h2><a name="shrinkingoptions">Shrinking Options</a></h2>
-<dl>
-<dt><a name="dontshrink"><code><b>-dontshrink</b></code></a></dt>
-<dd>Specifies not to shrink the input class files. By default, shrinking is
-    applied; all classes and class members are removed, except for the ones
-    listed by the various <code>-keep</code> options, and the ones on which
-    they depend, directly or indirectly. A shrinking step is also applied
-    after each optimization step, since some optimizations may open the
-    possibility to remove more classes and class members.</dd>
-<dt><a name="printusage"><code><b>-printusage</b></code></a>
-    [<a href="#filename"><i>filename</i></a>]</dt>
-<dd>Specifies to list dead code of the input class files. The list is printed
-    to the standard output or to the given file. For example, you can <a
-    href="examples.html#deadcode">list the unused code of an application</a>.
-    Only applicable when shrinking.</dd>
-<dt><a name="whyareyoukeeping"><code><b>-whyareyoukeeping</b></code></a>
-    <a href="#classspecification"><i>class_specification</i></a></dt>
-<dd>Specifies to print details on why the given classes and class members are
-    being kept in the shrinking step. This can be useful if you are wondering
-    why some given element is present in the output. In general, there can be
-    many different reasons. This option prints the shortest chain of methods
-    to a specified seed or entry point, for each specified class and class
-    member. <i>In the current implementation, the shortest chain that is
-    printed out may sometimes contain circular deductions -- these do not
-    reflect the actual shrinking process.</i> If the <a
-    href="#verbose"><code>-verbose</code></a> option if specified, the traces
-    include full field and method signatures. Only applicable when
-    shrinking.</dd>
-</dl>
-<p>
-<h2><a name="optimizationoptions">Optimization Options</a></h2>
-<dl>
-<dt><a name="dontoptimize"><code><b>-dontoptimize</b></code></a></dt>
-<dd>Specifies not to optimize the input class files. By default, optimization
-    is enabled; all methods are optimized at a bytecode level.</dd>
-<dt><a name="optimizations"><code><b>-optimizations</b></code></a>
-    <a href="optimizations.html"><i>optimization_filter</i></a></dt>
-<dd>Specifies the optimizations to be enabled and disabled, at a more
-    fine-grained level. Only applicable when optimizing. <i>This is an expert
-    option.</i></dd>
-<dt><a name="optimizationpasses"><code><b>-optimizationpasses</b></code></a> <i>n</i></dt>
-<dd>Specifies the number of optimization passes to be performed. By default, a
-    single pass is performed. Multiple passes may result in further
-    improvements. If no improvements are found after an optimization pass, the
-    optimization is ended. Only applicable when optimizing.</dd>
-<dt><a name="assumenosideeffects"><code><b>-assumenosideeffects</b></code></a>
-    <a href="#classspecification"><i>class_specification</i></a></dt>
-<dd>Specifies methods that don't have any side effects (other than maybe
-    returning a value). In the optimization step, ProGuard will then remove
-    calls to such methods, if it can determine that the return values aren't
-    used. Note that ProGuard will analyze your program code to find such
-    methods automatically. It will not analyze library code, for which this
-    option can thus be useful. For example, you could specify the method
-    <code>System.currentTimeMillis()</code>, so that any idle calls to it will
-    be removed. Note that ProGuard applies the option to the entire hierarchy
-    of the specified methods. Only applicable when optimizing. In general,
-    making assumptions can be dangerous; you can easily break the processed
-    code. <i>Only use this option if you know what you're doing!</i></dd>
-<dt><a name="allowaccessmodification"><code><b>-allowaccessmodification</b></code></a></dt>
-<dd>Specifies that the access modifiers of classes and class members may be
-    broadened during processing. This can improve the results of the
-    optimization step. For instance, when inlining a public getter, it may be
-    necessary to make the accessed field public too. Although Java's binary
-    compatibility specifications formally do not require this (cfr. <a href=
-    "http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html"
-    >The Java Language Specification, Second Edition</a>, <a href=
-    "http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#47259"
-    >Section 13.4.6</a>), some virtual machines would have problems with the
-    processed code otherwise. Only applicable when optimizing (and when
-    obfuscating with the <a
-    href="#repackageclasses"><code>-repackageclasses</code></a> option).
-    <p>
-    <i>Counter-indication:</i> you probably shouldn't use this option when
-    processing code that is to be used as a library, since classes and class
-    members that weren't designed to be public in the API may become
-    public.</dd>
-<dt><a name="mergeinterfacesaggressively"><code><b>-mergeinterfacesaggressively</b></code></a></dt>
-<dd>Specifies that interfaces may be merged, even if their implementing
-    classes don't implement all interface methods. This can reduce the size of
-    the output by reducing the total number of classes. Note that Java's
-    binary compatibility specifications allow such constructs (cfr. <a href=
-    "http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html"
-    >The Java Language Specification, Second Edition</a>, <a href=
-    "http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45347"
-    >Section 13.5.3</a>), even if they are not allowed in the Java language
-    (cfr. <a href=
-    "http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html"
-    >The Java Language Specification, Second Edition</a>, <a href=
-    "http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#34031"
-    >Section 8.1.4</a>). Only applicable when optimizing.
-    <p>
-    <i>Counter-indication:</i> setting this option can reduce the performance
-    of the processed code on some JVMs, since advanced just-in-time
-    compilation tends to favor more interfaces with fewer implementing
-    classes. Worse, some JVMs may not be able to handle the resulting code.
-    Notably:
-    <ul>
-    <li>Sun's JRE 1.3 may throw an <code>InternalError</code> when
-        encountering more than 256 <i>Miranda</i> methods (interface methods
-        without implementations) in a class.</li>
-    </ul></dd>
-</dl>
-<p>
-<h2><a name="obfuscationoptions">Obfuscation Options</a></h2>
-<dl>
-<dt><a name="dontobfuscate"><code><b>-dontobfuscate</b></code></a></dt>
-<dd>Specifies not to obfuscate the input class files. By default, obfuscation
-    is applied; classes and class members receive new short random names,
-    except for the ones listed by the various <code>-keep</code> options.
-    Internal attributes that are useful for debugging, such as source files
-    names, variable names, and line numbers are removed.</dd>
-<dt><a name="printmapping"><code><b>-printmapping</b></code></a>
-    [<a href="#filename"><i>filename</i></a>]</dt>
-<dd>Specifies to print the mapping from old names to new names for classes and
-    class members that have been renamed. The mapping is printed to the
-    standard output or to the given file. For example, it is required for
-    subsequent <a href="examples.html#incremental">incremental
-    obfuscation</a>, or if you ever want to make sense again of <a
-    href="examples.html#stacktrace">obfuscated stack traces</a>. Only
-    applicable when obfuscating.</dd>
-<dt><a name="applymapping"><code><b>-applymapping</b></code></a>
-    <a href="#filename"><i>filename</i></a></dt>
-<dd>Specifies to reuse the given name mapping that was printed out in a
-    previous obfuscation run of ProGuard. Classes and class members that are
-    listed in the mapping file receive the names specified along with them.
-    Classes and class members that are not mentioned receive new names. The
-    mapping may refer to input classes as well as library classes. This option
-    can be useful for <a href="examples.html#incremental">incremental
-    obfuscation</a>, i.e. processing add-ons or small patches to an existing
-    piece of code. In such cases, you should consider whether you also need
-    the option <a
-    href="#useuniqueclassmembernames"><code>-useuniqueclassmembernames</code></a>.
-    Only a single mapping file is allowed. Only applicable when
-    obfuscating.</dd>
-<dt><a name="obfuscationdictionary"><code><b>-obfuscationdictionary</b></code></a>
-    <a href="#filename"><i>filename</i></a></dt>
-<dd>Specifies a text file from which all valid words are used as obfuscated
-    field and method names. By default, short names like 'a', 'b', etc. are
-    used as obfuscated names. With an obfuscation dictionary, you can specify
-    a list of reserved key words, or identifiers with foreign characters, for
-    instance. White space, punctuation characters, duplicate words, and
-    comments after a <code><b>#</b></code> sign are ignored. Note that an
-    obfuscation dictionary hardly improves the obfuscation. Decent compilers
-    can automatically replace them, and the effect can fairly simply be undone
-    by obfuscating again with simpler names. The most useful application is
-    specifying strings that are typically already present in class files (such
-    as 'Code'), thus reducing the class file sizes just a little bit more.
-    Only applicable when obfuscating.</dd>
-<dt><a name="classobfuscationdictionary"><code><b>-classobfuscationdictionary</b></code></a>
-    <a href="#filename"><i>filename</i></a></dt>
-<dd>Specifies a text file from which all valid words are used as obfuscated
-    class names. The obfuscation dictionary is similar to the one of the
-    option <a
-    href="#obfuscationdictionary"><code>-obfuscationdictionary</code></a>.
-    Only applicable when obfuscating.</dd>
-<dt><a name="packageobfuscationdictionary"><code><b>-packageobfuscationdictionary</b></code></a>
-    <a href="#filename"><i>filename</i></a></dt>
-<dd>Specifies a text file from which all valid words are used as obfuscated
-    package names. The obfuscation dictionary is similar to the one of the
-    option <a
-    href="#obfuscationdictionary"><code>-obfuscationdictionary</code></a>.
-    Only applicable when obfuscating.</dd>
-<dt><a name="overloadaggressively"><code><b>-overloadaggressively</b></code></a></dt>
-<dd>Specifies to apply aggressive overloading while obfuscating. Multiple
-    fields and methods can then get the same names, as long as their arguments
-    and return types are different (not just their arguments). This option can
-    make the processed code even smaller (and less comprehensible). Only
-    applicable when obfuscating.
-    <p>
-    <i>Counter-indication:</i> the resulting class files fall within the Java
-    bytecode specification (cfr. <a href=
-    "http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html"
-    >The Java Virtual Machine Specification, Second Edition</a>, first
-    paragraphs of <a href=
-    "http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#2877"
-    >Section 4.5</a> and <a href=
-    "http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#1513"
-    >Section 4.6</a>), even though this kind of overloading is not allowed in
-    the Java language (cfr. <a href=
-    "http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html"
-    >The Java Language Specification, Second Edition</a>, <a href=
-    "http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#40898"
-    >Section 8.3</a> and <a href=
-    "http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#227768"
-    >Section 8.4.7</a>). Still, some tools have problems with it. Notably:
-    <ul>
-    <li>Sun's JDK 1.2.2 <code>javac</code> compiler produces an exception when
-        compiling with such a library (cfr. <a href=
-        "http://bugs.sun.com/view_bug.do?bug_id=4216736">Bug #4216736</a>).
-        You probably shouldn't use this option for processing libraries.</li>
-    <li>Sun's JRE 1.4 and later fail to serialize objects with overloaded
-        primitive fields.</li>
-    <li>Sun's JRE 1.5 <code>pack200</code> tool reportedly has problems with
-        overloaded class members.</li>
-    <li>Google's Dalvik VM can't handle overloaded static fields.</li>
-    </ul></dd>
-<dt><a name="useuniqueclassmembernames"><code><b>-useuniqueclassmembernames</b></code></a></dt>
-<dd>Specifies to assign the same obfuscated names to class members that have
-    the same names, and different obfuscated names to class members that have
-    different names (for each given class member signature). Without the
-    option, more class members can be mapped to the same short names like 'a',
-    'b', etc. The option therefore increases the size of the resulting code
-    slightly, but it ensures that the saved obfuscation name mapping can
-    always be respected in subsequent incremental obfuscation steps.
-    <p>
-    For instance, consider two distinct interfaces containing methods with the
-    same name and signature. Without this option, these methods may get
-    different obfuscated names in a first obfuscation step. If a patch is then
-    added containing a class that implements both interfaces, ProGuard will
-    have to enforce the same method name for both methods in an incremental
-    obfuscation step. The original obfuscated code is changed, in order to
-    keep the resulting code consistent. With this option <i>in the initial
-    obfuscation step</i>, such renaming will never be necessary.
-    <p>
-    This option is only applicable when obfuscating. In fact, if you are
-    planning on performing incremental obfuscation, you probably want to avoid
-    shrinking and optimization altogether, since these steps could remove or
-    modify parts of your code that are essential for later additions.</dd>
-<dt><a name="dontusemixedcaseclassnames"><code><b>-dontusemixedcaseclassnames</b></code></a></dt>
-<dd>Specifies not to generate mixed-case class names while obfuscating. By
-    default, obfuscated class names can contain a mix of upper-case characters
-    and lower-case characters. This creates perfectly acceptable and usable
-    jars. Only if a jar is unpacked on a platform with a case-insensitive
-    filing system (say, Windows), the unpacking tool may let similarly named
-    class files overwrite each other. Code that self-destructs when it's
-    unpacked! Developers who really want to unpack their jars on Windows can
-    use this option to switch off this behavior. Note that the obfuscated jars
-    will become larger as a result. Only applicable when obfuscating.</dd>
-<dt><a name="keeppackagenames"><code><b>-keeppackagenames</b></code></a>
-    [<i><a href="#filters">package_filter</a></i>]</dt>
-<dd>Specifies not obfuscate the given package names. The optional filter is a
-    comma-separated list of package names. Package names can contain <b>?</b>,
-    <b>*</b>, and <b>**</b> wildcards, and they can be preceded by the
-    <b>!</b> negator. Only applicable when obfuscating.</dd>
-<dt><a name="flattenpackagehierarchy"><code><b>-flattenpackagehierarchy</b></code></a>
-    [<i>package_name</i>]</dt>
-<dd>Specifies to repackage all packages that are renamed, by moving them into
-    the single given parent package. Without argument or with an empty string
-    (''), the packages are moved into the root package. This option is one
-    example of further <a href="examples.html#repackaging">obfuscating package
-    names</a>. It can make the processed code smaller and less comprehensible.
-    Only applicable when obfuscating.</dd>
-<dt><a name="repackageclasses"><code><b>-repackageclasses</b></code></a>
-    [<i>package_name</i>]</dt>
-<dd>Specifies to repackage all class files that are renamed, by moving them
-    into the single given package. Without argument or with an empty string
-    (''), the package is removed completely. This option option overrides the
-    <a
-    href="#flattenpackagehierarchy"><code>-flattenpackagehierarchy</code></a>
-    option. It is another example of further <a
-    href="examples.html#repackaging">obfuscating package names</a>. It can
-    make the processed code even smaller and less comprehensible. Its
-    deprecated name is <code>-defaultpackage</code>. Only applicable when
-    obfuscating.
-    <p>
-    <i>Counter-indication:</i> classes that look for resource files in their
-    package directories will no longer work properly if they are moved
-    elsewhere. When in doubt, just leave the packaging untouched by not using
-    this option.</dd>
-<dt><a name="keepattributes"><code><b>-keepattributes</b></code></a>
-    [<i><a href="#filters">attribute_filter</a></i>]</dt>
-<dd>Specifies any optional attributes to be preserved. The attributes can be
-    specified with one or more <code>-keepattributes</code> directives. The
-    optional filter is a comma-separated list of attribute names. Attribute
-    names can contain <b>?</b>, <b>*</b>, and <b>**</b> wildcards, and they
-    can be preceded by the <b>!</b> negator. Typical optional attributes are
-    <code>Exceptions</code>, <code>Signature</code>, <code>Deprecated</code>,
-    <code>SourceFile</code>, <code>SourceDir</code>,
-    <code>LineNumberTable</code>, <code>LocalVariableTable</code>,
-    <code>LocalVariableTypeTable</code>, <code>Synthetic</code>,
-    <code>EnclosingMethod</code>, <code>RuntimeVisibleAnnotations</code>,
-    <code>RuntimeInvisibleAnnotations</code>,
-    <code>RuntimeVisibleParameterAnnotations</code>,
-    <code>RuntimeInvisibleParameterAnnotations</code>, and
-    <code>AnnotationDefault</code>. The <code>InnerClasses</code> attribute
-    name can be specified as well, referring to the source name part of this
-    attribute. For example, you should at least keep the
-    <code>Exceptions</code>, <code>InnerClasses</code>, and
-    <code>Signature</code> attributes
-    when <a href="examples.html#library">processing a library</a>. You should
-    also keep the <code>SourceFile</code> and
-    <code>LineNumberTable</code> attributes
-    for <a href="examples.html#stacktrace">producing useful obfuscated stack
-    traces</a>. Finally, you may want
-    to <a href="examples.html#annotations">keep annotations</a> if your code
-    depends on them. Only applicable when obfuscating.</dd>
-<dt><a name="keepparameternames"><code><b>-keepparameternames</b></code></a></dt>
-<dd>Specifies to keep the parameter names and types of methods that are kept.
-    This option actually keeps trimmed versions of the debugging attributes
-    <code>LocalVariableTable</code> and
-    <code>LocalVariableTypeTable</code>. It can be useful when
-    <a href="examples.html#library">processing a library</a>. Some IDEs can
-    use the information to assist developers who use the library, for example
-    with tool tips or autocompletion. Only applicable when obfuscating.</dd>
-<dt><a name="renamesourcefileattribute"><code><b>-renamesourcefileattribute</b></code></a>
-    [<i>string</i>]</dt>
-<dd>Specifies a constant string to be put in the <code>SourceFile</code>
-    attributes (and <code>SourceDir</code> attributes) of the class files.
-    Note that the attribute has to be present to start with, so it also has to
-    be preserved explicitly using the <code>-keepattributes</code> directive.
-    For example, you may want to have your processed libraries and
-    applications produce <a href="examples.html#stacktrace">useful obfuscated
-    stack traces</a>. Only applicable when obfuscating.</dd>
-<dt><a name="adaptclassstrings"><code><b>-adaptclassstrings</b></code></a>
-    [<i><a href="#filters">class_filter</a></i>]</dt>
-<dd>Specifies that string constants that correspond to class names should be
-    obfuscated as well. Without a filter, all string constants that correspond
-    to class names are adapted. With a filter, only string constants in
-    classes that match the filter are adapted. For example, if your code
-    contains a large number of hard-coded strings that refer to classes, and
-    you prefer not to keep their names, you may want to use this option.
-    Primarily applicable when obfuscating, although corresponding classes are
-    automatically kept in the shrinking step too.</dd>
-<dt><a name="adaptresourcefilenames"><code><b>-adaptresourcefilenames</b></code></a>
-    [<i><a href="#filefilters">file_filter</a></i>]</dt>
-<dd>Specifies the resource files to be renamed, based on the obfuscated names
-    of the corresponding class files (if any). Without a filter, all resource
-    files that correspond to class files are renamed. With a filter, only
-    matching files are renamed. For example, see <a
-    href="examples.html#resourcefiles">processing resource files</a>. Only
-    applicable when obfuscating.</dd>
-<dt><a name="adaptresourcefilecontents"><code><b>-adaptresourcefilecontents</b></code></a>
-    [<i><a href="#filefilters">file_filter</a></i>]</dt>
-<dd>Specifies the resource files whose contents are to be updated. Any class
-    names mentioned in the resource files are renamed, based on the obfuscated
-    names of the corresponding classes (if any). Without a filter, the
-    contents of all resource files updated. With a filter, only matching files
-    are updated. The resource files are parsed and written using the
-    platform's default character set. You can change this default character set
-    by setting the environment variable <code>LANG</code> or the Java system
-    property <code>file.encoding</code>. For an example,
-    see <a href="examples.html#resourcefiles">processing resource files</a>.
-    Only applicable when obfuscating.</dd>
-</dl>
-<p>
-<h2><a name="preverificationoptions">Preverification Options</a></h2>
-<dl>
-<dt><a name="dontpreverify"><code><b>-dontpreverify</b></code></a></dt>
-<dd>Specifies not to preverify the processed class files. By default, class
-    files are preverified if they are targeted at Java Micro Edition or at
-    Java 6 or higher. For Java Micro Edition, preverification is required, so
-    you will need to run an external preverifier on the processed code if you
-    specify this option. For Java 6, preverification is not required (yet),
-    but it improves the efficiency of the class loading in the Java Virtual
-    Machine.</dd>
-<dt><a name="microedition"><code><b>-microedition</b></code></a></dt>
-<dd>Specifies that the processed class files are targeted at Java Micro
-    Edition. The preverifier will then add the appropriate StackMap
-    attributes, which are different from the default StackMapTable attributes
-    for Java Standard Edition. For example, you will need this option if you
-    are <a href="examples.html#midlets">processing midlets</a>.</dd>
-</dl>
-<p>
-<h2><a name="generaloptions">General Options</a></h2>
-<dl>
-<dt><a name="verbose"><code><b>-verbose</b></code></a></dt>
-<dd>Specifies to write out some more information during processing. If the
-    program terminates with an exception, this option will print out the entire
-    stack trace, instead of just the exception message.</dd>
-<dt><a name="dontnote"><code><b>-dontnote</b></code></a>
-    [<i><a href="#filters">class_filter</a></i>]</dt>
-<dd>Specifies not to print notes about potential mistakes or omissions in the
-    configuration, like typos in class names, or like missing options that
-    might be useful. The optional filter is a regular expression; ProGuard
-    doesn't print notes about classes with matching names.</dd>
-<dt><a name="dontwarn"><code><b>-dontwarn</b></code></a>
-    [<i><a href="#filters">class_filter</a></i>]</dt>
-<dd>Specifies not to warn about unresolved references and other important
-    problems at all. The optional filter is a regular expression; ProGuard
-    doesn't print warnings about classes with matching names. Ignoring
-    warnings can be dangerous. For instance, if the unresolved classes or
-    class members are indeed required for processing, the processed code will
-    not function properly. <i>Only use this option if you know what you're
-    doing!</i></dd>
-<dt><a name="ignorewarnings"><code><b>-ignorewarnings</b></code></a></dt>
-<dd>Specifies to print any warnings about unresolved references and other
-    important problems, but to continue processing in any case. Ignoring
-    warnings can be dangerous. For instance, if the unresolved classes or
-    class members are indeed required for processing, the processed code will
-    not function properly. <i>Only use this option if you know what you're
-    doing!</i></dd>
-<dt><a name="printconfiguration"><code><b>-printconfiguration</b></code></a>
-    [<a href="#filename"><i>filename</i></a>]</dt>
-<dd>Specifies to write out the entire configuration that has been parsed, with
-    included files and replaced variables. The structure is printed to the
-    standard output or to the given file. This can sometimes be useful for
-    debugging configurations, or for converting XML configurations into a more
-    readable format.</dd>
-<dt><a name="dump"><code><b>-dump</b></code></a>
-    [<a href="#filename"><i>filename</i></a>]</dt>
-<dd>Specifies to write out the internal structure of the class files, after
-    any processing. The structure is printed to the standard output or to the
-    given file. For example, you may want to <a
-    href="examples.html#structure">write out the contents of a given jar
-    file</a>, without processing it at all.</dd>
-</dl>
-<p>
-<h2><a name="classpath">Class Paths</a></h2>
-ProGuard accepts a generalization of class paths to specify input files and
-output files. A class path consists of entries, separated by the traditional
-path separator (e.g. '<b>:</b>' on Unix, or '<b>;</b>' on Windows platforms).
-The order of the entries determines their priorities, in case of duplicates.
-<p>
-Each input entry can be:
-<ul>
-<li>A class file or resource file,</li>
-<li>A jar file, containing any of the above,</li>
-<li>A war file, containing any of the above,</li>
-<li>An ear file, containing any of the above,</li>
-<li>A zip file, containing any of the above,</li>
-<li>A directory (structure), containing any of the above.</li>
-</ul>
-<p>
-The paths of directly specified class files and resource files is ignored, so
-class files should generally be part of a jar file, a war file, an ear file, a
-zip file, or a directory. In addition, the paths of class files should not have
-any additional directory prefixes inside the archives or directories.
-<p>
-Each output entry can be:
-<ul>
-<li>A jar file, in which all processed class files and resource files will be
-    collected.</li>
-<li>A war file, in which any and all of the above will be collected,</li>
-<li>An ear file, in which any and all of the above will be collected,</li>
-<li>A zip file, in which any and all of the above will be collected,</li>
-<li>A directory, in which any and all of the above will be collected.</li>
-</ul>
-<p>
-When writing output entries, ProGuard will generally package the results in a
-sensible way, reconstructing the input entries as much as required. Writing
-everything to an output directory is the most straightforward option: the
-output directory will contain a complete reconstruction of the input entries.
-The packaging can be almost arbitrarily complex though: you could process an
-entire application, packaged in a zip file along with its documentation,
-writing it out as a zip file again. The Examples section shows a few ways
-to <a href="examples.html#restructuring">restructure output archives</a>.
-<p>
-Files and directories can be specified as discussed in the section on <a
-href="#filename">file names</a> below.
-<p>
-In addition, ProGuard provides the possibility to filter the class path
-entries and their contents, based on their full relative file names. Each
-class path entry can be followed by up to 5 types of <a
-href="#filefilters">file filters</a> between parentheses, separated by
-semi-colons:
-<ul>
-<li>A filter for all zip names that are encountered,</li>
-<li>A filter for all ear names that are encountered,</li>
-<li>A filter for all war names that are encountered,</li>
-<li>A filter for all jar names that are encountered,</li>
-<li>A filter for all class file names and resource file names that are
-    encountered.</li>
-</ul>
-<p>
-If fewer than 5 filters are specified, they are assumed to be the latter
-filters. Any empty filters are ignored. More formally, a filtered class path
-entry looks like this:
-<pre>
-<i>classpathentry</i><b>(</b>[[[[<i>zipfilter</i><b>;</b>]<i>earfilter</i><b>;</b>]<i>warfilter</i><b>;</b>]<i>jarfilter</i><b>;</b>]<i>filefilter</i><b>)</b>
-</pre>
-<p>
-Square brackets "[]" mean that their contents are optional.
-<p>
-For example, "<code>rt.jar(java/**.class,javax/**.class)</code>" matches all
-class files in the <code>java</code> and <code>javax</code> directories inside
-the <code>rt</code> jar.
-<p>
-For example, "<code>input.jar(!**.gif,images/**)</code>" matches all files in
-the <code>images</code> directory inside the <code>input</code> jar, except
-gif files.
-<p>
-Note that the different filters are applied to all corresponding file types,
-irrespective of their nesting levels in the input; they are orthogonal.
-<p>
-For example,
-"<code>input.war(lib/**.jar,support/**.jar;**.class,**.gif)</code>" only
-considers jar files in the <code>lib</code> and <code>support</code>
-directories in the <code>input</code> war, not any other jar files. It then
-matches all class files and gif files that are encountered.
-<p>
-The filters allow for an almost infinite number of packaging and repackaging
-possibilities. The Examples section provides a few more examples
-for <a href="examples.html#filtering">filtering input and output</a>.
-<p>
-<h2><a name="filename">File Names</a></h2>
-ProGuard accepts absolute paths and relative paths for the various file names
-and directory names. A relative path is interpreted as follows:
-<ul>
-<li>relative to the base directory, if set, or otherwise</li>
-<li>relative to the configuration file in which it is specified, if any, or
-    otherwise</li>
-<li>relative to the working directory.</li>
-</ul>
-<p>
-The names can contain Java system properties delimited by '<b>&lt;</b>' and
-'<b>&gt;</b>'. The system properties
-are automatically replaced by their respective values.
-<p>
-For example, <code>&lt;java.home&gt;/lib/rt.jar</code> will automatically be
-expanded to something like <code>/usr/local/java/jdk/jre/lib/rt.jar</code>.
-Similarly, <code>&lt;user.home&gt;</code> will be expanded to the user's home
-directory, and <code>&lt;user.dir&gt;</code> will be expanded to the current
-working directory.
-<p>
-Names with special characters like spaces and parentheses must be quoted with
-single or double quotes. Note that each file name in a list of names has to be
-quoted individually. Also note that the quotes themselves may need to be
-escaped when used on the command line, to avoid them being gobbled by the
-shell.
-<p>
-For example, on the command line, you could use an option like <code>'-injars
-"my program.jar":"/your directory/your program.jar"'</code>.
-<p>
-<h2><a name="filefilters">File Filters</a></h2>
-Like general <a href="#filters">filters</a>, a file filter is a
-comma-separated list of file names that can contain wildcards. Only files with
-matching file names are read (in the case of input jars), or written (in the
-case of output jars). The following wildcards are supported:
-<table cellspacing="10">
-<tr><td valign="top"><code><b>?</b></code></td>
-    <td>matches any single character in a file name.</td></tr>
-<tr><td valign="top"><code><b>*</b></code></td>
-    <td>matches any part of a filename not containing the directory
-        separator.</td></tr>
-<tr><td valign="top"><code><b>**</b></code></td>
-    <td>matches any part of a filename, possibly containing any number of
-        directory separators.</td></tr>
-</table>
-For example, "<code>java/**.class,javax/**.class</code>" matches all
-class files in the <code>java</code> and <code>javax</code>.
-<p>
-Furthermore, a file name can be preceded by an exclamation mark '<b>!</b>' to
-<i>exclude</i> the file name from further attempts to match with
-<i>subsequent</i> file names.
-<p>
-For example, "<code>!**.gif,images/**</code>" matches all files in the
-<code>images</code> directory, except gif files.
-<p>
-The Examples section provides a few more examples for <a
-href="examples.html#filtering">filtering input and output</a>.
-<h2><a name="filters">Filters</a></h2>
-ProGuard offers options with filters for many different aspects of the
-configuration: names of files, directories, classes, packages, attributes,
-optimizations, etc.
-<p>
-A filter is a list of comma-separated names that can contain wildcards. Only
-names that match an item on the list pass the filter. The supported wildcards
-depend on the type of names for which the filter is being used, but the
-following wildcards are typical:
-<table cellspacing="10">
-<tr><td valign="top"><code><b>?</b></code></td>
-    <td>matches any single character in a name.</td></tr>
-<tr><td valign="top"><code><b>*</b></code></td>
-    <td>matches any part of a name not containing the package separator or
-        directory separator.</td></tr>
-<tr><td valign="top"><code><b>**</b></code></td>
-    <td>matches any part of a name, possibly containing any number of
-        package separators or directory separators.</td></tr>
-</table>
-For example, "<code>foo,*bar</code>" matches the name <code>foo</code> and
-all names ending with <code>bar</code>.
-<p>
-Furthermore, a name can be preceded by a negating exclamation mark '<b>!</b>'
-to <i>exclude</i> the name from further attempts to match
-with <i>subsequent</i> names. So, if a name matches an item in the filter, it
-is accepted or rejected right away, depending on whether the item has a
-negator. If the name doesn't match the item, it is tested against the next
-item, and so on. It if doesn't match any items, it is accepted or rejected,
-depending on the whether the last item has a negator or not.
-<p>
-For example, "<code>!foobar,*bar</code>" matches all names ending with
-<code>bar</code>, except <code>foobar</code>.
-<p>
-<h2><a name="keepoverview">Overview of <code>Keep</code> Options</a></h2>
-The various <code>-keep</code> options for shrinking and obfuscation may seem
-a bit confusing at first, but there's actually a pattern behind them. The
-following table summarizes how they are related:
-<p>
-<table cellpadding="5">
-<tr>
-<th>Keep</th>
-<td>From being removed or renamed</td>
-<td>From being renamed</td>
-</tr>
-<tr>
-<td>Classes and class members</td>
-<td bgcolor="#E0E0E0"><a href="#keep"><code>-keep</code></a></td>
-<td bgcolor="#E0E0E0"><a href="#keepnames"><code>-keepnames</code></a></td>
-</tr>
-<tr>
-<td>Class members only</td>
-<td bgcolor="#E0E0E0"><a href="#keepclassmembers"><code>-keepclassmembers</code></a></td>
-<td bgcolor="#E0E0E0"><a href="#keepclassmembernames"><code>-keepclassmembernames</code></a></td>
-</tr>
-<tr>
-<td>Classes and class members, if class members present</td>
-<td bgcolor="#E0E0E0"><a href="#keepclasseswithmembers"><code>-keepclasseswithmembers</code></a></td>
-<td bgcolor="#E0E0E0"><a href="#keepclasseswithmembernames"><code>-keepclasseswithmembernames</code></a></td>
-</tr>
-</table>
-<p>
-Each of these <code>-keep</code> options is of course followed by a
-<a href="#classspecification">specification</a> of the classes and class
-members (fields and methods) to which it should be applied.
-<p>
-If you're not sure which option you need, you should probably simply use
-<code>-keep</code>. It will make sure the specified classes and class members
-are not removed in the shrinking step, and not renamed in the obfuscation step.
-<p>
-<table>
-<tr><td valign="top">
-<img src="attention.gif" width="64" height="64"alt="attention" />
-</td><td>
-Always remember:
-<ul>
-<li>Specifying a class without class members only preserves the class as an
-    entry point &mdash; any class members may then still be removed, optimized,
-    or obfuscated.</li>
-<li>Specifying a class member only preserves the class member as an entry
-    point &mdash; any associated code may still be optimized and adapted.</li>
-</ul>
-</td></tr>
-</table>
-<p>
-<h2><a name="keepoptionmodifiers">Keep Option Modifiers</a></h2>
-<dl>
-<dt><a name="allowshrinking"><code><b>allowshrinking</b></code></a></dt>
-<dd>Specifies that the entry points specified in the <a href="#keep">-keep</a>
-    option may be shrunk, even if they have to be preserved otherwise. That
-    is, the entry points may be removed in the shrinking step, but if they are
-    necessary after all, they may not be optimized or obfuscated.</dd>
-<dt><a name="allowoptimization"><code><b>allowoptimization</b></code></a></dt>
-<dd>Specifies that the entry points specified in the <a href="#keep">-keep</a>
-    option may be optimized, even if they have to be preserved otherwise. That
-    is, the entry points may be altered in the optimization step, but they may
-    not be removed or obfuscated. This modifier is only useful for achieving
-    unusual requirements.</dd>
-<dt><a name="allowobfuscation"><code><b>allowobfuscation</b></code></a></dt>
-<dd>Specifies that the entry points specified in the <a href="#keep">-keep</a>
-    option may be obfuscated, even if they have to be preserved otherwise. That
-    is, the entry points may be renamed in the obfuscation step, but they may
-    not be removed or optimized. This modifier is only useful for achieving
-    unusual requirements.</dd>
-</dl>
-<p>
-<h2><a name="classspecification">Class Specifications</a></h2>
-A class specification is a template of classes and class members (fields and
-methods). It is used in the various <code>-keep</code> options and in the
-<code>-assumenosideeffects</code> option. The corresponding option is only
-applied to classes and class members that match the template.
-<p>
-The template was designed to look very Java-like, with some extensions for
-wildcards. To get a feel for the syntax, you should probably look at the <a
-href="examples.html">examples</a>, but this is an attempt at a complete formal
-definition:
-<p>
-<pre>
-[<b>@</b><i>annotationtype</i>] [[<b>!</b>]<b>public</b>|<b>final</b>|<b>abstract</b>|<b>@</b> ...] [<b>!</b>]<b>interface</b>|<b>class</b>|<b>enum</b> <i>classname</i>
-    [<b>extends</b>|<b>implements</b> [<b>@</b><i>annotationtype</i>] <i>classname</i>]
-[<b>{</b>
-    [<b>@</b><i>annotationtype</i>] [[<b>!</b>]<b>public</b>|<b>private</b>|<b>protected</b>|<b>static</b>|<b>volatile</b>|<b>transient</b> ...] <b>&lt;fields&gt;</b> |
-                                                                      (<i>fieldtype fieldname</i>)<b>;</b>
-    [<b>@</b><i>annotationtype</i>] [[<b>!</b>]<b>public</b>|<b>private</b>|<b>protected</b>|<b>static</b>|<b>synchronized</b>|<b>native</b>|<b>abstract</b>|<b>strictfp</b> ...] <b>&lt;methods&gt;</b> |
-                                                                                           <b>&lt;init&gt;(</b><i>argumenttype,...</i><b>)</b> |
-                                                                                           <i>classname</i><b>(</b><i>argumenttype,...</i><b>)</b> |
-                                                                                           (<i>returntype methodname</i><b>(</b><i>argumenttype,...</i><b>)</b>)<b>;</b>
-    [<b>@</b><i>annotationtype</i>] [[<b>!</b>]<b>public</b>|<b>private</b>|<b>protected</b>|<b>static</b> ... ] <b>*;</b>
-    ...
-<b>}</b>]
-</pre>
-<p>
-Square brackets "[]" mean that their contents are optional. Ellipsis dots
-"..." mean that any number of the preceding items may be specified. A vertical
-bar "|" delimits two alternatives. Non-bold parentheses "()" just group parts
-of the specification that belong together. The indentation tries to clarify
-the intended meaning, but white-space is irrelevant in actual configuration
-files.
-<p>
-<ul class="spacious">
-<li>The <code><b>class</b></code> keyword refers to any interface or class.
-    The <code><b>interface</b></code> keyword restricts matches to interface
-    classes. The <code><b>enum</b></code> keyword restricts matches to
-    enumeration classes. Preceding the <code><b>interface</b></code> or
-    <code><b>enum</b></code> keywords by a <code><b>!</b></code> restricts
-    matches to classes that are not interfaces or enumerations,
-    respectively.</li>
-<li>Every <i>classname</i> must be fully qualified, e.g.
-    <code>java.lang.String</code>. Class names may be specified as regular
-    expressions containing the following wildcards:
-<table cellspacing="10">
-<tr><td valign="top"><code><b>?</b></code></td>
-<td>matches any single character in a class name, but not the package
-    separator. For example, "<code>mypackage.Test?</code>" matches
-    "<code>mypackage.Test1</code>" and "<code>mypackage.Test2</code>", but not
-    "<code>mypackage.Test12</code>".</td></tr>
-<tr><td valign="top"><code><b>*</b></code></td>
-<td>matches any part of a class name not containing the package separator. For
-    example, "<code>mypackage.*Test*</code>" matches
-    "<code>mypackage.Test</code>" and
-    "<code>mypackage.YourTestApplication</code>", but not
-    "<code>mypackage.mysubpackage.MyTest</code>". Or, more generally,
-    "<code>mypackage.*</code>" matches all classes in
-    "<code>mypackage</code>", but not in its subpackages.</td></tr>
-<tr><td valign="top"><code><b>**</b></code></td>
-<td>matches any part of a class name, possibly containing any number of
-    package separators. For example, "<code>**.Test</code>" matches all
-    <code>Test</code> classes in all packages except the root package. Or,
-    "<code>mypackage.**</code>" matches all classes in
-    "<code>mypackage</code>" and in its subpackages.</td></tr>
-</table>
-    For additional flexibility, class names can actually be comma-separated
-    lists of class names, with optional <code><b>!</b></code> negators, just
-    like file name filters. This notation doesn't look very Java-like, so it
-    should be used with moderation.
-    <p>
-    For convenience and for backward compatibility, the class name
-    <code><b>*</b></code> refers to any class, irrespective of its package.</li>
-<li>The <code><b>extends</b></code> and <code><b>implements</b></code>
-    specifications are typically used to restrict classes with wildcards. They
-    are currently equivalent, specifying that only classes extending or
-    implementing the given class qualify. Note that the given class itself is
-    not included in this set. If required, it should be specified in a
-    separate option.</li>
-<li>The <code><b>@</b></code> specifications can be used to restrict classes
-    and class members to the ones that are annotated with the specified
-    annotation types. An <i>annotationtype</i> is specified just like a
-    <i>classname</i>.</li>
-<li>Fields and methods are specified much like in Java, except that method
-    argument lists don't contain argument names (just like in other tools
-    like <code>javadoc</code> and <code>javap</code>). The specifications can
-    also contain the following catch-all wildcards:
-<table cellspacing="10">
-<tr><td valign="top"><code><b>&lt;init&gt;</b></code></td>
-<td>matches any constructor.</td></tr>
-<tr><td valign="top"><code><b>&lt;fields&gt;</b></code></td>
-<td>matches any field.</td></tr>
-<tr><td valign="top"><code><b>&lt;methods&gt;</b></code></td>
-<td>matches any method.</td></tr>
-<tr><td valign="top"><code><b>*</b></code></td>
-<td>matches any field or method.</td></tr>
-</table>
-    Note that the above wildcards don't have return types. Only the
-    <code><b>&lt;init&gt;</b></code> wildcard has an argument list.
-    <p>
-    Fields and methods may also be specified using regular expressions. Names
-    can contain the following wildcards:
-<table cellspacing="10">
-<tr><td valign="top"><code><b>?</b></code></td>
-    <td>matches any single character in a method name.</td></tr>
-<tr><td valign="top"><code><b>*</b></code></td>
-    <td>matches any part of a method name.</td></tr>
-</table>
-    Types in descriptors can contain the following wildcards:
-<table cellspacing="10">
-<tr><td valign="top"><code><b>%</b></code></td>
-    <td>matches any primitive type ("<code>boolean</code>", "<code>int</code>",
-        etc, but not "<code>void</code>").</td></tr>
-<tr><td valign="top"><code><b>?</b></code></td>
-    <td>matches any single character in a class name.</td></tr>
-<tr><td valign="top"><code><b>*</b></code></td>
-    <td>matches any part of a class name not containing the package                     separator.</td></tr>
-<tr><td valign="top"><code><b>**</b></code></td>
-    <td>matches any part of a class name, possibly containing any number of
-        package separators.</td></tr>
-<tr><td valign="top"><code><b>***</b></code></td>
-    <td>matches any type (primitive or non-primitive, array or
-        non-array).</td></tr>
-<tr><td valign="top"><code><b>...</b></code></td>
-    <td>matches any number of arguments of any type.</td></tr>
-</table>
-    Note that the <code>?</code>, <code>*</code>, and <code>**</code>
-    wildcards will never match primitive types. Furthermore, only the
-    <code>***</code> wildcards will match array types of any dimension. For
-    example, "<code>** get*()</code>" matches "<code>java.lang.Object
-    getObject()</code>", but not "<code>float getFloat()</code>", nor
-    "<code>java.lang.Object[] getObjects()</code>".</li>
-<li>Constructors can also be specified using their short class names (without
-    package) or using their full class names. As in the Java language, the
-    constructor specification has an argument list, but no return type.</li>
-<li>The class access modifiers and class member access modifiers are typically
-    used to restrict wildcarded classes and class members. They specify that
-    the corresponding access flags have to be set for the member to match. A
-    preceding <code><b>!</b></code> specifies that the corresponding access
-    flag should be unset.
-    <p>
-    Combining multiple flags is allowed (e.g. <code>public static</code>). It
-    means that both access flags have to be set (e.g. <code>public</code>
-    <i>and</i> <code>static</code>), except when they are conflicting, in
-    which case at least one of them has to be set (e.g. at least
-    <code>public</code>
-    <i>or</i> <code>protected</code>).
-    <p>
-    ProGuard supports the additional modifiers <code><b>synthetic</b></code>,
-    <code><b>bridge</b></code>, and <code><b>varargs</b></code>, which may be
-    set by compilers.</li>
-</ul>
-<hr />
-<noscript><div><a target="_top" href="../index.html" class="button">Show menu</a></div></noscript>
-<address>
-Copyright &copy; 2002-2011
-<a target="other" href="http://www.lafortune.eu/">Eric Lafortune</a>.
-</address>
-</body>
-</html>