diff --git a/.idea/encodings.xml b/.idea/encodings.xml
index 74c7fa4..1708a0a 100644
--- a/.idea/encodings.xml
+++ b/.idea/encodings.xml
@@ -2,5 +2,6 @@
+
\ No newline at end of file
diff --git a/at/fos/ermodel/gui/B3.java b/at/fos/ermodel/gui/B3.java
index 2c21a9f..0a0e035 100644
--- a/at/fos/ermodel/gui/B3.java
+++ b/at/fos/ermodel/gui/B3.java
@@ -80,6 +80,7 @@ public class B3
public final RadioButton msSqlStyle;
public final CheckBox generateRelationalModelCB;
public final Button saveSQLScriptBTN;
+ public final Button saveCSScriptBTN;
public final CheckBox generateInsertsCB;
public final CheckBox singleInsertStatementCB;
public final CheckBox addCurrentDateToDatabaseNameCB;
@@ -743,6 +744,22 @@ public class B3
}
});
+ this.saveCSScriptBTN = new Button("Generate/Save C# script");
+ this.saveCSScriptBTN.setTooltip(new Tooltip("The ddl-script will be generated and saved into a file"));
+ this.saveCSScriptBTN.setMaxWidth(Double.MAX_VALUE);
+ setMouseHandler(this.saveCSScriptBTN);
+ GridPane.setFillWidth(this.saveCSScriptBTN, Boolean.TRUE);
+ this.saveCSScriptBTN.setBackground(new Background(new BackgroundFill(C2.ButtonBackgroundColor, CornerRadii.EMPTY, Insets.EMPTY)));
+
+ this.saveCSScriptBTN.setOnAction(arg0 -> {
+ if (B3.this.generateRelationalModelCB.isSelected()) {
+ try {
+ B3.this.saveSQLScript();
+ } catch (ZZ20 ignored) {
+ }
+ }
+ });
+
this.generateInsertsCB = new CheckBox("Generate insert statement");
this.generateInsertsCB.setTooltip(new Tooltip("If selected, insert statements are generated in the ddl-script"));
@@ -878,7 +895,14 @@ public class B3
box.getChildren().addAll(this.addCurrentDateToDatabaseNameCB, this.generateInsertsCB, this.singleInsertStatementCB, this.saveSQLScriptBTN);
TitledPane createddl = new TitledPane("Create DDL", box);
createddl.setExpanded(false);
- this.buttonPane.add(createddl, 0, ri, 2, 1);
+ this.buttonPane.add(createddl, 0, ri++, 2, 1);
+
+ VBox csbox = new VBox(10.0D);
+ csbox.getChildren().addAll(saveCSScriptBTN);
+
+ TitledPane createcsharp = new TitledPane("Create C# Code", csbox);
+ createcsharp.setExpanded(false);
+ this.buttonPane.add(createcsharp, 0, ri, 2, 1);
this.statusInformation = new TextField("Creation Mode: entity-set -> press left mouse button on working area -> enter name of entity-set -> press enter key");
this.statusInformation.setEditable(false);
diff --git a/noEasyDB.iml b/noEasyDB.iml
index 5f20ef2..1418e4d 100644
--- a/noEasyDB.iml
+++ b/noEasyDB.iml
@@ -7,6 +7,10 @@
+
+
+
+
diff --git a/noEasyDB_optimized.jar b/noEasyDB_optimized.jar
new file mode 100644
index 0000000..aaed2c4
Binary files /dev/null and b/noEasyDB_optimized.jar differ
diff --git a/noEasyDB_optimized_old.jar b/noEasyDB_optimized_old.jar
new file mode 100644
index 0000000..d3e842c
Binary files /dev/null and b/noEasyDB_optimized_old.jar differ
diff --git a/optimize.bat b/optimize.bat
new file mode 100644
index 0000000..8df7688
--- /dev/null
+++ b/optimize.bat
@@ -0,0 +1 @@
+proguard\bin\proguard.bat -verbose -injar out/artifacts/noEasyDB/noEasyDB.jar -outjars noEasyDB_optimized.jar -keep class at.fos.ermodel.gui.A1 { *; } -libraryjars "/jmods/java.desktop.jmod;/jmods/java.base.jmod;/jmods/javafx.base.jmod;/jmods/javafx.graphics.jmod;/jmods/javafx.controls.jmod;/jmods/javafx.swing.jmod"
\ No newline at end of file
diff --git a/proguard/LICENSE b/proguard/LICENSE
new file mode 100644
index 0000000..d159169
--- /dev/null
+++ b/proguard/LICENSE
@@ -0,0 +1,339 @@
+ GNU GENERAL PUBLIC LICENSE
+ Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+ Preamble
+
+ The licenses for most software are designed to take away your
+freedom to share and change it. By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users. This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it. (Some other Free Software Foundation software is covered by
+the GNU Lesser General Public License instead.) You can apply it to
+your programs, too.
+
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+ To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+ For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have. You must make sure that they, too, receive or can get the
+source code. And you must show them these terms so they know their
+rights.
+
+ We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+ Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software. If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+ Finally, any free program is threatened constantly by software
+patents. We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary. To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+ The precise terms and conditions for copying, distribution and
+modification follow.
+
+ GNU GENERAL PUBLIC LICENSE
+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+ 0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License. The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language. (Hereinafter, translation is included without limitation in
+the term "modification".) Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope. The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+ 1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+ 2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+ a) You must cause the modified files to carry prominent notices
+ stating that you changed the files and the date of any change.
+
+ b) You must cause any work that you distribute or publish, that in
+ whole or in part contains or is derived from the Program or any
+ part thereof, to be licensed as a whole at no charge to all third
+ parties under the terms of this License.
+
+ c) If the modified program normally reads commands interactively
+ when run, you must cause it, when started running for such
+ interactive use in the most ordinary way, to print or display an
+ announcement including an appropriate copyright notice and a
+ notice that there is no warranty (or else, saying that you provide
+ a warranty) and that users may redistribute the program under
+ these conditions, and telling the user how to view a copy of this
+ License. (Exception: if the Program itself is interactive but
+ does not normally print such an announcement, your work based on
+ the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole. If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works. But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+ 3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+ a) Accompany it with the complete corresponding machine-readable
+ source code, which must be distributed under the terms of Sections
+ 1 and 2 above on a medium customarily used for software interchange; or,
+
+ b) Accompany it with a written offer, valid for at least three
+ years, to give any third party, for a charge no more than your
+ cost of physically performing source distribution, a complete
+ machine-readable copy of the corresponding source code, to be
+ distributed under the terms of Sections 1 and 2 above on a medium
+ customarily used for software interchange; or,
+
+ c) Accompany it with the information you received as to the offer
+ to distribute corresponding source code. (This alternative is
+ allowed only for noncommercial distribution and only if you
+ received the program in object code or executable form with such
+ an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it. For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable. However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+ 4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License. Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+ 5. You are not required to accept this License, since you have not
+signed it. However, nothing else grants you permission to modify or
+distribute the Program or its derivative works. These actions are
+prohibited by law if you do not accept this License. Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+ 6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions. You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+ 7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License. If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all. For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices. Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+ 8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded. In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+ 9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time. Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation. If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+ 10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission. For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this. Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+ NO WARRANTY
+
+ 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+ 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+ END OF TERMS AND CONDITIONS
+
+ How to Apply These Terms to Your New Programs
+
+ If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+ To do so, attach the following notices to the program. It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+
+ Copyright (C)
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License along
+ with this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+ Gnomovision version 69, Copyright (C) year name of author
+ Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+ This is free software, and you are welcome to redistribute it
+ under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License. Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary. Here is a sample; alter the names:
+
+ Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+ `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+ , 1 April 1989
+ Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs. If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library. If this is what you want to do, use the GNU Lesser General
+Public License instead of this License.
diff --git a/proguard/bin/proguard.bat b/proguard/bin/proguard.bat
new file mode 100644
index 0000000..daf2c1a
--- /dev/null
+++ b/proguard/bin/proguard.bat
@@ -0,0 +1,14 @@
+@ECHO OFF
+
+REM Start-up script for ProGuard -- free class file shrinker, optimizer,
+REM obfuscator, and preverifier for Java bytecode.
+REM
+REM Note: when passing file names containing spaces to this script,
+REM you'll have to add escaped quotes around them, e.g.
+REM "\"C:/My Directory/My File.txt\""
+
+IF EXIST "%PROGUARD_HOME%" GOTO home
+SET PROGUARD_HOME=%~dp0\..
+:home
+
+java -jar "%PROGUARD_HOME%\lib\proguard.jar" %*
diff --git a/proguard/bin/proguard.sh b/proguard/bin/proguard.sh
new file mode 100644
index 0000000..3ee60ed
--- /dev/null
+++ b/proguard/bin/proguard.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+#
+# Start-up script for ProGuard -- free class file shrinker, optimizer,
+# obfuscator, and preverifier for Java bytecode.
+#
+# Note: when passing file names containing spaces to this script,
+# you'll have to add escaped quotes around them, e.g.
+# "\"/My Directory/My File.txt\""
+
+# Account for possibly missing/basic readlink.
+# POSIX conformant (dash/ksh/zsh/bash).
+PROGUARD=`readlink -f "$0" 2>/dev/null`
+if test "$PROGUARD" = ''
+then
+ PROGUARD=`readlink "$0" 2>/dev/null`
+ if test "$PROGUARD" = ''
+ then
+ PROGUARD="$0"
+ fi
+fi
+
+PROGUARD_HOME=`dirname "$PROGUARD"`/..
+
+java -jar "$PROGUARD_HOME/lib/proguard.jar" "$@"
diff --git a/proguard/bin/proguardgui.bat b/proguard/bin/proguardgui.bat
new file mode 100644
index 0000000..c328f5b
--- /dev/null
+++ b/proguard/bin/proguardgui.bat
@@ -0,0 +1,14 @@
+@ECHO OFF
+
+REM Start-up script for the GUI of ProGuard -- free class file shrinker,
+REM optimizer, obfuscator, and preverifier for Java bytecode.
+REM
+REM Note: when passing file names containing spaces to this script,
+REM you'll have to add escaped quotes around them, e.g.
+REM "\"C:/My Directory/My File.txt\""
+
+IF EXIST "%PROGUARD_HOME%" GOTO home
+SET PROGUARD_HOME=%~dp0\..
+:home
+
+java -jar "%PROGUARD_HOME%\lib\proguardgui.jar" %*
diff --git a/proguard/bin/proguardgui.sh b/proguard/bin/proguardgui.sh
new file mode 100644
index 0000000..aba7f62
--- /dev/null
+++ b/proguard/bin/proguardgui.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# Start-up script for the GUI of ProGuard -- free class file shrinker,
+# optimizer, obfuscator, and preverifier for Java bytecode.
+#
+# Note: when passing file names containing spaces to this script,
+# you'll have to add escaped quotes around them, e.g.
+# "\"/My Directory/My File.txt\""
+
+# Account for possibly missing/basic readlink.
+# POSIX conformant (dash/ksh/zsh/bash).
+PROGUARD=`readlink -f "$0" 2>/dev/null`
+if test "$PROGUARD" = ''
+then
+ PROGUARD=`readlink "$0" 2>/dev/null`
+ if test "$PROGUARD" = ''
+ then
+ PROGUARD="$0"
+ fi
+fi
+
+PROGUARD_HOME=`dirname "$PROGUARD"`/..
+
+# On Linux, Java 1.6.0_24 and higher hang when starting the GUI:
+# http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7027598
+# We're using the -D option as a workaround.
+java -DsuppressSwingDropSupport=true -jar "$PROGUARD_HOME/lib/proguardgui.jar" "$@"
diff --git a/proguard/bin/retrace.bat b/proguard/bin/retrace.bat
new file mode 100644
index 0000000..ae16dde
--- /dev/null
+++ b/proguard/bin/retrace.bat
@@ -0,0 +1,14 @@
+@ECHO OFF
+
+REM Start-up script for Retrace -- companion tool for ProGuard, free class file
+REM shrinker, optimizer, obfuscator, and preverifier for Java bytecode.
+REM
+REM Note: when passing file names containing spaces to this script,
+REM you'll have to add escaped quotes around them, e.g.
+REM "\"C:/My Directory/My File.txt\""
+
+IF EXIST "%PROGUARD_HOME%" GOTO home
+SET PROGUARD_HOME=%~dp0\..
+:home
+
+java -jar "%PROGUARD_HOME%\lib\retrace.jar" %*
diff --git a/proguard/bin/retrace.sh b/proguard/bin/retrace.sh
new file mode 100644
index 0000000..2f274de
--- /dev/null
+++ b/proguard/bin/retrace.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+#
+# Start-up script for Retrace -- companion tool for ProGuard, free class file
+# shrinker, optimizer, obfuscator, and preverifier for Java bytecode.
+#
+# Note: when passing file names containing spaces to this script,
+# you'll have to add escaped quotes around them, e.g.
+# "\"/My Directory/My File.txt\""
+
+# Account for possibly missing/basic readlink.
+# POSIX conformant (dash/ksh/zsh/bash).
+PROGUARD=`readlink -f "$0" 2>/dev/null`
+if test "$PROGUARD" = ''
+then
+ PROGUARD=`readlink "$0" 2>/dev/null`
+ if test "$PROGUARD" = ''
+ then
+ PROGUARD="$0"
+ fi
+fi
+
+PROGUARD_HOME=`dirname "$PROGUARD"`/..
+
+java -jar "$PROGUARD_HOME/lib/retrace.jar" "$@"
diff --git a/proguard/docs/downloads.md b/proguard/docs/downloads.md
new file mode 100644
index 0000000..01725f0
--- /dev/null
+++ b/proguard/docs/downloads.md
@@ -0,0 +1,19 @@
+**ProGuard** is distributed under the terms of the GNU General Public License.
+Please consult the [license page](license.md) for more details.
+
+ProGuard is written in Java, so it requires a Java Runtime Environment
+(JRE 1.8 or higher).
+
+You can download ProGuard in various forms:
+
+- [Pre-built artifacts](https://search.maven.org/search?q=g:com.guardsquare) at Maven Central
+- A [Git repository of the source code](https://github.com/Guardsquare/proguard) at Github
+- The [complete ProGuard manual](https://www.guardsquare.com/proguard) at Guardsquare
+
+You can find major releases, minor releases with important bug fixes, and
+beta releases with the latest new features and any less urgent bug fixes.
+
+If you're still working with an older version of ProGuard, check out the
+[release notes](releasenotes.md), to see if you're missing something essential.
+Unless noted otherwise, ProGuard remains compatible across versions, so
+don't be afraid to update.
diff --git a/proguard/docs/index.md b/proguard/docs/index.md
new file mode 100644
index 0000000..483c63e
--- /dev/null
+++ b/proguard/docs/index.md
@@ -0,0 +1,36 @@
+**ProGuard** is a free Java class file shrinker, optimizer, obfuscator, and
+preverifier. It detects and removes unused classes, fields, methods, and
+attributes. It optimizes bytecode and removes unused instructions. It renames
+the remaining classes, fields, and methods using short meaningless names. The
+resulting applications and libraries are smaller, faster, and a bit better
+hardened against reverse engineering.
+
+Typical applications:
+
+- Reducing the size of apps for faster downloads, shorter startup
+ times, and smaller memory footprints.
+- Optimizing code for better performance on mobile devices.
+
+**ProGuard**'s main advantage compared to other Java obfuscators is probably
+its compact template-based configuration. A few intuitive command line options
+or a simple configuration file are usually sufficient. The user manual
+explains all available options and shows examples of this powerful
+configuration style.
+
+**ProGuard** is fast. It only takes seconds to process programs and libraries
+of several megabytes. The results section presents actual figures for a number
+of applications.
+
+**ProGuard** is a command-line tool with an optional graphical user interface.
+It also comes with plugins for Ant, for Gradle, and for the JME Wireless
+Toolkit. It is already part of Google's Android SDK, where it can be enabled
+with a simple flag.
+
+**ProGuard** provides basic protection against reverse engineering and
+tampering, with basic name obfuscation.
+[**DexGuard**](http://www.guardsquare.com/dexguard), its specialized
+commercial extension for Android, focuses further on the protection of apps,
+additionally optimizing, obfuscating and encrypting strings, classes,
+resources, resource files, asset files, and native libraries. Professional
+developers should definitely consider it for security-sensitive apps.
+
diff --git a/proguard/docs/manual/FAQ.md b/proguard/docs/manual/FAQ.md
new file mode 100644
index 0000000..9248b2c
--- /dev/null
+++ b/proguard/docs/manual/FAQ.md
@@ -0,0 +1,212 @@
+## What is shrinking? {: #shrinking}
+
+Java source code (.java files) is typically compiled to bytecode (.class
+files). Bytecode is more compact than Java source code, but it may still
+contain a lot of unused code, especially if it includes program libraries.
+Shrinking programs such as **ProGuard** can analyze bytecode and remove unused
+classes, fields, and methods. The program remains functionally equivalent,
+including the information given in exception stack traces.
+
+## What is name obfuscation? {: #obfuscation}
+
+By default, compiled bytecode still contains a lot of debugging information:
+source file names, line numbers, field names, method names, argument names,
+variable names, etc. This information makes it straightforward to decompile
+the bytecode and reverse-engineer entire programs. Sometimes, this is not
+desirable. Shrinkers such as **ProGuard** can remove the debugging
+information and replace all names by meaningless character sequences, making
+apps smaller. The program remains functionally equivalent, except for the class
+names, method names, and line numbers given in exception stack traces.
+
+## What is preverification? {: #preverification}
+
+When loading class files, the class loader performs some sophisticated
+verification of the byte code. This analysis makes sure the code can't
+accidentally or intentionally break out of the sandbox of the virtual machine.
+Java Micro Edition and Java 6 introduced split verification. This means that
+the JME preverifier and the Java 6 compiler add preverification information to
+the class files (StackMap and StackMapTable attributes, respectively), in
+order to simplify the actual verification step for the class loader. Class
+files can then be loaded faster and in a more memory-efficient way.
+**ProGuard** automatically preverifies the code that it processes.
+
+## What kind of optimizations does ProGuard support? {: #optimization}
+
+Apart from removing unused classes, fields, and methods in the shrinking step,
+**ProGuard** can also perform optimizations at the bytecode level, inside and
+across methods. Thanks to techniques like control flow analysis, data flow
+analysis, partial evaluation, static single assignment, global value
+numbering, and liveness analysis, **ProGuard** can:
+
+- Evaluate constant expressions.
+- Remove unnecessary field accesses and method calls.
+- Remove unnecessary branches.
+- Remove unnecessary comparisons and instanceof tests.
+- Remove unused code blocks.
+- Merge identical code blocks.
+- Reduce variable allocation.
+- Remove write-only fields and unused method parameters.
+- Inline constant fields, method parameters, and return values.
+- Inline methods that are short or only called once.
+- Simplify tail recursion calls.
+- Merge classes and interfaces.
+- Make methods private, static, and final when possible.
+- Make classes static and final when possible.
+- Replace interfaces that have single implementations.
+- Perform over 200 peephole optimizations, like replacing `"The answer is
+ "+42` by `"The answer is 42"`.
+- Optionally remove logging code.
+
+The positive effects of these optimizations will depend on your code and on
+the virtual machine on which the code is executed. Simple virtual machines may
+benefit more than advanced virtual machines with sophisticated JIT compilers.
+At the very least, your bytecode may become a bit smaller.
+
+## Can I use ProGuard to process my commercial application? {: #commercial}
+
+Yes, you can. **ProGuard** itself is distributed under the GPL, but this
+doesn't affect the programs that you process. Your code remains yours, and its
+license can remain the same.
+
+## Does ProGuard work with Java 2, 5,..., 19? {: #jdk1.4}
+
+Yes, **ProGuard** supports all JDKs from 1.1 up to and including 19. Java 2
+introduced some small differences in the class file format. Java 5 added
+attributes for generics and for annotations. Java 6 introduced optional
+preverification attributes. Java 7 made preverification obligatory and
+introduced support for dynamic languages. Java 8 added more attributes and
+default methods. Java 9 added support for modules. Java 11 added dynamic
+constants and nest-based access control. Java 14 added records. Java 15
+added sealed classes.
+**ProGuard** handles all versions correctly.
+
+## Does ProGuard work with Java Micro Edition? {: #jme}
+
+Yes. **ProGuard** itself runs in Java Standard Edition, but you can freely
+specify the run-time environment at which your programs are targeted,
+including Java Micro Edition. **ProGuard** then also performs the required
+preverification, producing more compact results than the traditional external
+preverifier.
+
+## Does ProGuard Support Android Apps?
+
+The **ProGuard Gradle Plugin** is compatible with Android Gradle Plugin (AGP) versions 4.x - 7.x.
+
+The **ProGuard** [keep rules configuration format](configuration/usage.md) is also supported by R8 (the default Android shrinker),
+so you can use your R8, ProGuard and DexGuard keep rules interchangeably.
+
+See [Gradle Plugin setup](setup/gradleplugin.md) page for more information.
+
+## Does ProGuard have support for Ant? {: #ant}
+
+Yes. **ProGuard** provides an Ant task, so that it integrates seamlessly into
+your Ant build process. You can still use configurations in **ProGuard**'s own
+readable format. Alternatively, if you prefer XML, you can specify the
+equivalent XML configuration.
+
+See [Ant setup](setup/ant.md) page for more information.
+
+## Does ProGuard have support for Java/Kotlin Gradle projects? {: #gradle}
+
+Yes. **ProGuard** also provides a Gradle task, so that it integrates into your
+Gradle build process. You can specify configurations in **ProGuard**'s own
+format or embedded in the Groovy configuration.
+
+See [Gradle setup](setup/gradle.md) page for more information.
+
+## Does ProGuard have support for Maven? {: #maven}
+
+While we don't officially provide a Maven integration and
+we cannot provide support there are solutions available,
+their offered functionality is not guaranteed by Guardsquare.
+
+Some open-source implementations:
+
+- [https://github.com/wvengen/proguard-maven-plugin](https://github.com/wvengen/proguard-maven-plugin)
+- [https://github.com/dingxin/proguard-maven-plugin](https://github.com/dingxin/proguard-maven-plugin)
+
+## Does ProGuard come with a GUI? {: #gui}
+
+Yes. First of all, **ProGuard** is perfectly usable as a command-line tool
+that can easily be integrated into any automatic build process. For casual
+users, there's also a graphical user interface that simplifies creating,
+loading, editing, executing, and saving ProGuard configurations.
+
+## Does ProGuard handle `Class.forName` calls? {: #forname}
+
+Yes. **ProGuard** automatically handles constructs like
+`Class.forName("SomeClass")` and `SomeClass.class`. The referenced classes are
+preserved in the shrinking phase, and the string arguments are properly
+replaced in the obfuscation phase.
+
+With variable string arguments, it's generally not possible to determine their
+possible values. They might be read from a configuration file, for instance.
+However, **ProGuard** will note a number of constructs like
+"`(SomeClass)Class.forName(variable).newInstance()`". These might be an
+indication that the class or interface `SomeClass` and/or its implementations
+may need to be preserved. The developer can adapt his configuration
+accordingly.
+
+## Does ProGuard handle resource files? {: #resource}
+
+Yes. **ProGuard** copies all non-class resource files, optionally adapting
+their names and their contents to the obfuscation that has been applied.
+
+## Does ProGuard encrypt string constants? {: #encrypt}
+
+No. String encryption in program code has to be perfectly reversible by
+definition, so it only improves the obfuscation level. It increases the
+footprint of the code. However, by popular demand, **ProGuard**'s
+closed-source sibling for Android,
+[**DexGuard**](http://www.guardsquare.com/dexguard), does provide string
+encryption, along with more protection techniques against static and dynamic
+analysis.
+
+## Does ProGuard perform control flow obfuscation?
+
+No. Control flow obfuscation injects additional branches into the bytecode, in
+an attempt to fool decompilers. **ProGuard** does not do this, except to some
+extent in its optimization techniques. **ProGuard**'s closed-source sibling
+for Android, [**DexGuard**](http://www.guardsquare.com/dexguard), does offer
+control flow obfuscation, as one of the many additional techniques to harden
+Android apps.
+
+## Does ProGuard support incremental obfuscation? {: #incremental}
+
+Yes. This feature allows you to specify a previous obfuscation mapping file in
+a new obfuscation step, in order to produce add-ons or patches for obfuscated
+code.
+
+## Can ProGuard obfuscate using reserved keywords? {: #keywords}
+
+Yes. You can specify your own obfuscation dictionary, such as a list of
+reserved key words, identifiers with foreign characters, random source files,
+or a text by Shakespeare. Note that this hardly improves the obfuscation.
+Decent decompilers can automatically replace reserved keywords, and the effect
+can be undone fairly easily, by obfuscating again with simpler names.
+
+## Can ProGuard reconstruct obfuscated stack traces? {: #stacktrace}
+
+Yes. **ProGuard** comes with a companion tool, **ReTrace**, that can
+'de-obfuscate' stack traces produced by obfuscated applications. The
+reconstruction is based on the mapping file that **ProGuard** can write out.
+If line numbers have been obfuscated away, a list of alternative method names
+is presented for each obfuscated method name that has an ambiguous reverse
+mapping. Please refer to the [ProGuard User Manual](manual/index.md) for more
+details.
+
+## How is DexGuard different from ProGuard?
+
+[**DexGuard**](http://www.guardsquare.com/dexguard) is a commercial extension
+of **ProGuard**:
+
+- **DexGuard** is specialized for Android applications and libraries: it
+ optimizes and obfuscates not just the bytecode, but also the manifest file,
+ resources, resource files, asset files, and native libraries.
+- **DexGuard** focuses on making apps self-defending against reverse
+ engineering and tampering. **DexGuard**'s techniques for obfuscation,
+ encryption, and detection are a lot stronger than **ProGuard**'s basic name
+ obfuscation.
+- **DexGuard** is backward compatible with **ProGuard**: it reads the same
+ configuration. It already comes with tuned configuration for the Android
+ runtime and for common Android libraries.
diff --git a/proguard/docs/manual/building.md b/proguard/docs/manual/building.md
new file mode 100644
index 0000000..b582727
--- /dev/null
+++ b/proguard/docs/manual/building.md
@@ -0,0 +1,71 @@
+# Building ProGuard
+
+!!! info
+
+ **ProGuard** is distributed under the terms of the GNU General Public License. Please consult the [license page](license/license.md) for more details.
+
+Building ProGuard is easy - you'll need:
+
+* a Java 8 JDK installed
+* a clone of the [ProGuard](https://github.com/Guardsquare/proguard.git) repository
+
+You can then execute a composite build with the following Gradle command:
+
+=== "Linux/macOS"
+ ```bash
+ ./gradlew assemble
+ ```
+
+=== "Windows"
+ ```bash
+ gradlew assemble
+ ```
+
+
+The artifacts will be generated in the `lib` directory. You can then execute ProGuard using the
+scripts in `bin`, for example:
+
+=== "Linux/macOS"
+
+ ```bash
+ bin/proguard.sh
+ ```
+
+=== "Windows"
+
+ ```bash
+ bin\proguard.bat
+ ```
+
+## Publish to Maven local
+
+
+You can publish the artifacts to your local Maven cache (something like `~/.m2/`):
+
+=== "Linux/macOS"
+ ```bash
+ ./gradlew publishToMavenLocal
+ ```
+
+=== "Windows"
+ ```bash
+ gradlew publishToMavenLocal
+ ```
+
+## Building a release distribution
+
+You can build tar and zip archives with the binaries and documentation:
+
+
+=== "Linux/macOS"
+
+ ```bash
+ ./gradlew distTar distZip
+ ```
+
+=== "Windows"
+
+ ```bash
+ gradlew distTar distZip
+ ```
+
diff --git a/proguard/docs/manual/configuration/attributes.md b/proguard/docs/manual/configuration/attributes.md
new file mode 100644
index 0000000..554dd66
--- /dev/null
+++ b/proguard/docs/manual/configuration/attributes.md
@@ -0,0 +1,176 @@
+Class files essentially define classes, their fields, and their methods. A lot
+of essential and non-essential data are attached to these classes, fields, and
+methods as *attributes*. For instance, attributes can contain bytecode, source
+file names, line number tables, etc.
+
+ProGuard's obfuscation step removes attributes that are generally not
+necessary for executing the code. With the
+[`-keepattributes`](usage.md#keepattributes) option, you can specify a filter
+for attributes that you do want to keep, for instance if your code accesses
+them through reflection, or if you want to preserve some compilation or
+debugging information. The filter works like any [filter](usage.md#filters) in
+ProGuard.
+
+The following wildcards are supported:
+
+| Wildcard | Meaning
+|-----|----------------------------------------------------
+| `?` | matches any single character in an attribute name.
+| `*` | matches any part of an attribute name.
+
+An attribute name that is preceded by an exclamation mark '**!**' is
+*excluded* from further attempts to match with *subsequent* attribute names in
+the filter. Make sure to specify filters correctly, since they are not checked
+for potential typos.
+
+For example, the following setting preserves the optional attributes that are
+typically necessary when processing code that is intended to be used as a
+library:
+```proguard
+-keepattributes Exceptions,InnerClasses,Signature,Deprecated,
+ SourceFile,LineNumberTable,*Annotation*,EnclosingMethod
+```
+
+The Java bytecode specifications currently specify the following list of
+attributes.
+
+## Optional attributes
+
+ProGuard's obfuscation step by default discards the following optional
+attributes. You can keep them with the
+[`-keepattributes`](usage.md#keepattributes) option.
+
+`SourceFile`
+: Specifies the name of the source file from which the class file was
+ compiled. If present, this name is reported in stack traces.
+
+`SourceDir`
(J++ extension)
+: Specifies the name of the source directory from which the class file was
+ compiled.
+
+`Record`
(Java 14 or higher)
+: Specifies the components of a record class. Code may access this information
+ by reflection.
+
+`InnerClasses`
+: Specifies the relationship between a class and its inner classes and outer
+ classes. Other than this and the naming convention with a '\$' separator
+ between the names of inner classes and outer classes, inner classes are just
+ like ordinary classes. Compilers may need this information to find classes
+ referenced in a compiled library. Code may access this information by
+ reflection, for instance to derive the simple name of the class.
+
+`PermittedSubclasses`
(Java 15 or higher)
+: Specifies the allowed extensions or implementations of sealed classes or
+ interfaces.
+
+`EnclosingMethod`
(Java 5 or higher)
+: Specifies the method in which the class was defined. Compilers may need this
+ information to find classes referenced in a compiled library. Code may
+ access this information by reflection, for instance to derive the simple
+ name of the class.
+
+`Deprecated`
+: Indicates that the class, field, or method is deprecated.
+
+`Synthetic`
+: Indicates that the class, field, or method was generated by the compiler.
+
+`Signature`
(Java 5 or higher)
+: Specifies the generic signature of the class, field, or method. Compilers
+ may need this information to properly compile classes that use generic types
+ from compiled libraries. Code may access this signature by reflection.
+
+`MethodParameters`
(Java 8 or higher)
+: Specifies the names and access flags of the parameters of the method. Code
+ may access this information by reflection.
+
+`Exceptions`
+: Specifies the exceptions that a method may throw. Compilers may use this
+ information to enforce catching them.
+
+`LineNumberTable`
+: Specifies the line numbers of the method. If present, these line numbers are
+ reported in stack traces.
+
+`LocalVariableTable`
+: Specifies the names and types of local variables of the method. If present,
+ some IDEs may use this information for helping with auto-completion.
+
+`LocalVariableTypeTable`
(Java 5 or higher)
+: Specifies the names and generic types of local variables of the method. If
+ present, some IDEs may use this information for helping with
+ auto-completion.
+
+`RuntimeVisibleAnnotations`
(Java 5 or higher)
+: Specifies the annotations that are visible at run-time, for classes, fields,
+ and methods. Compilers and annotation processors may use these annotations.
+ Code may access them by reflection.
+
+`RuntimeInvisibleAnnotations`
(Java 5 or higher)
+
+: Specifies the annotations that are visible at compile-time, for classes,
+ fields, and methods. Compilers and annotation processors may use these
+ annotations.
+
+`RuntimeVisibleParameterAnnotations`
(Java 5 or higher)
+
+: Specifies the annotations that are visible at run-time, for method
+ parameters. Compilers and annotation processors may use these annotations.
+ Code may access them by reflection.
+
+`RuntimeInvisibleParameterAnnotations`
(Java 5 or higher)
+
+: Specifies the annotations that are visible at compile-time, for method
+ parameters. Compilers and annotation processors may use these annotations.
+
+`RuntimeVisibleTypeAnnotations`
(Java 8 or higher)
+: Specifies the annotations that are visible at run-time, for generic types,
+ instructions, etc. Compilers and annotation processors may use these
+ annotations. Code may access them by reflection.
+
+`RuntimeInvisibleTypeAnnotations`
(Java 8 or higher)
+
+: Specifies the annotations that are visible at compile-time, for generic
+ types, instructions, etc. Compilers and annotation processors may use these
+ annotations.
+
+`AnnotationDefault`
(Java 5 or higher)
+: Specifies a default value for an annotation.
+
+## Essential attributes
+
+ProGuard automatically keeps the following essential attributes, processing
+them as necessary. We're listing them for the sake of completeness:
+
+`ConstantValue`
+: Specifies a constant integer, float, class, string, etc.
+
+`Code`
+: Specifies the actual bytecode of a method.
+
+`StackMap`
(Java Micro Edition)
+: Provides preverification information. The Java Virtual Machine can use this
+ information to speed up the verification step when loading a class.
+
+`StackMapTable`
(Java 6 or higher)
+: Provides preverification information. The Java Virtual Machine can use this
+ information to speed up the verification step when loading a class.
+
+`BootstrapMethods`
(Java 7 or higher)
+: Specifies the methods to bootstrap dynamic method invocations.
+
+`Module`
(Java 9 or higher)
+: Specifies the dependencies of a _module_.
+
+`ModuleMainClass`
(Java 9 or higher)
+: Specifies the main class of a _module_.
+
+`ModulePackages`
(Java 9 or higher)
+: Specifies the packages of a _module_.
+
+`NestHost`
(Java 11 or higher)
+: Specifies the host class of a _nest_, for example an outer class.
+
+`NestMembers`
(Java 11 or higher)
+: Specifies the members of a _nest_, for example the inner classes.
diff --git a/proguard/docs/manual/configuration/examples.md b/proguard/docs/manual/configuration/examples.md
new file mode 100644
index 0000000..240f773
--- /dev/null
+++ b/proguard/docs/manual/configuration/examples.md
@@ -0,0 +1,1409 @@
+You can find some sample configuration files in the `examples` directory
+of the ProGuard distribution.
+
+## Processing different types of applications {: #applicationtypes}
+
+### A typical application {: #application}
+
+To shrink, optimize, and obfuscate a simple Java application, you
+typically create a configuration file like `myconfig.pro`, which you can
+then use with
+```sh
+bin/proguard @myconfig.pro
+```
+
+The configuration file specifies the input, the output, and the entry
+points of the application:
+```proguard
+-injars myapplication.jar
+-outjars myapplication_out.jar
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+-printmapping myapplication.map
+
+-keep public class com.example.MyMain {
+ public static void main(java.lang.String[]);
+}
+```
+
+Note the use of the `` system property. ProGuard automatically
+replaces it when parsing the file. In this example, the library jar is the
+base Java runtime module, minus some unwanted files. For Java 8 or older, the
+Java runtime jar would be `/lib/rt.jar` instead. You may need
+additional modules or jars if your application depends on them.
+
+The [`-keep`](usage.md#keep) option specifies the entry point of the
+application that has to be preserved. The access modifiers `public` and
+`static` are not really required in this case, since we know a priori that the
+specified class and method have the proper access flags. It just looks more
+familiar this way.
+
+Note that all type names are fully specified: `com.example.MyMain` and
+`java.lang.String[]`.
+
+You can refine your keep rules using the ProGuard Playground which visualizes
+how your keep rules match the entities in your app.
+
+
+
+We're writing out an obfuscation mapping file with
+[`-printmapping`](usage.md#printmapping), for de-obfuscating any stack traces
+later on, or for incremental obfuscation of extensions.
+
+We can further improve the results with a few additional options:
+```proguard
+-optimizationpasses 3
+-overloadaggressively
+-repackageclasses ''
+-allowaccessmodification
+```
+
+These options are not required; they just shave off some extra bytes from the
+output jar, by performing up to 3 optimization passes, and by aggressively
+obfuscating class members and [package names](#repackaging).
+
+In general, you might need a few additional options for processing [native
+methods](#native), [callback methods](#callback),
+[enumerations](#enumerations), [serializable classes](#serializable), [bean
+classes](#beans), [annotations](#annotations), and [resource
+files](#resourcefiles).
+
+### A typical applet {: #applet}
+
+These options shrink, optimize, and obfuscate the applet
+`com.example.MyApplet`:
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+
+-keep public class com.example.MyApplet
+```
+
+The typical applet methods will be preserved automatically, since
+`com.example.MyApplet` is an extension of the `Applet` class in the library
+`rt.jar`.
+
+If applicable, you should add options for processing [native
+methods](#native), [callback methods](#callback),
+[enumerations](#enumerations), [serializable classes](#serializable), [bean
+classes](#beans), [annotations](#annotations), and [resource
+files](#resourcefiles).
+
+### A typical midlet {: #midlet}
+
+These options shrink, optimize, obfuscate, and preverify the midlet
+`com.example.MyMIDlet`:
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /usr/local/java/wtk2.5.2/lib/midpapi20.jar
+-libraryjars /usr/local/java/wtk2.5.2/lib/cldcapi11.jar
+-overloadaggressively
+-repackageclasses ''
+-allowaccessmodification
+-microedition
+
+-keep public class com.example.MyMIDlet
+```
+
+Note how we're now targeting the Java Micro Edition run-time environment of
+`midpapi20.jar` and `cldcapi11.jar`, instead of the Java Standard Edition
+run-time environment `rt.jar`. You can target other JME environments by
+picking the appropriate jars.
+
+The typical midlet methods will be preserved automatically, since
+`com.example.MyMIDlet` is an extension of the `MIDlet` class in the library
+`midpapi20.jar`.
+
+The [`-microedition`](usage.md#microedition) option makes sure the class files
+are preverified for Java Micro Edition, producing compact `StackMap`
+attributes. It is no longer necessary to run an external preverifier.
+
+Be careful if you do use the external `preverify` tool on a platform with a
+case-insensitive filing system, such as Windows. Because this tool unpacks
+your processed jars, you should then use ProGuard's
+[`-dontusemixedcaseclassnames`](usage.md#dontusemixedcaseclassnames) option.
+
+If applicable, you should add options for processing [native methods](#native)
+and [resource files](#resourcefiles).
+
+Note that you will still have to adapt the midlet jar size in the
+corresponding jad file; ProGuard doesn't do that for you.
+
+### A typical Java Card applet {: #jcapplet}
+
+These options shrink, optimize, and obfuscate the Java Card applet
+`com.example.MyApplet`:
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /usr/local/java/javacard2.2.2/lib/api.jar
+-dontwarn java.lang.Class
+-overloadaggressively
+-repackageclasses ''
+-allowaccessmodification
+
+-keep public class com.example.MyApplet
+```
+
+The configuration is very similar to the configuration for midlets, except
+that it now targets the Java Card run-time environment. This environment
+doesn't have java.lang.Class, so we're telling ProGuard not to worry about it.
+
+### A typical xlet {: #xlet}
+
+These options shrink, optimize, and obfuscate the xlet `com.example.MyXlet`:
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /usr/local/java/jtv1.1/javatv.jar
+-libraryjars /usr/local/java/cdc1.1/lib/cdc.jar
+-libraryjars /usr/local/java/cdc1.1/lib/btclasses.zip
+-overloadaggressively
+-repackageclasses ''
+-allowaccessmodification
+
+-keep public class com.example.MyXlet
+```
+
+The configuration is very similar to the configuration for midlets, except
+that it now targets the CDC run-time environment with the Java TV API.
+
+### A typical library {: #library}
+
+These options shrink, optimize, and obfuscate an entire library, keeping
+all public and protected classes and class members, native method names,
+and serialization code. The processed version of the library can then
+still be used as such, for developing code based on its public API.
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+-printmapping out.map
+
+-keep public class * {
+ public protected *;
+}
+
+-keepparameternames
+-renamesourcefileattribute SourceFile
+-keepattributes Signature,Exceptions,*Annotation*,
+ InnerClasses,PermittedSubclasses,EnclosingMethod,
+ Deprecated,SourceFile,LineNumberTable
+
+-keepclasseswithmembernames,includedescriptorclasses class * {
+ native ;
+}
+
+-keepclassmembers,allowoptimization enum * {
+ public static **[] values();
+ public static ** valueOf(java.lang.String);
+}
+
+-keepclassmembers class * implements java.io.Serializable {
+ static final long serialVersionUID;
+ private static final java.io.ObjectStreamField[] serialPersistentFields;
+ private void writeObject(java.io.ObjectOutputStream);
+ private void readObject(java.io.ObjectInputStream);
+ java.lang.Object writeReplace();
+ java.lang.Object readResolve();
+}
+```
+
+This configuration should preserve everything a developers ever wants to
+access in the library. Only if there are any other non-public classes or
+methods that are invoked dynamically, they should be specified using
+additional [`-keep`](usage.md#keep) options.
+
+The "Signature" attribute is required to be able to access generic types.
+
+The "Exceptions" attribute has to be preserved, so the compiler knows
+which exceptions methods may throw.
+
+The various "\*Annotations\*" attributes contain any annotations, which
+developers might need to access through reflection.
+
+The "InnerClasses" attribute (or more precisely, its source name part) has to
+be preserved too, for any inner classes that can be referenced from outside
+the library. The `javac` compiler would be unable to find the inner classes
+otherwise.
+
+The "PermittedSubclasses" attribute defines sealed classes, which developers
+can't extend further.
+
+The "EnclosingMethod" attribute marks classes that are defined inside methods.
+
+The "Deprecated" attribute marks any deprecated classes, fields, or
+methods, which may be useful for developers to know.
+
+The [`-keepparameternames`](usage.md#keepparameternames) option keeps the
+parameter names in the "LocalVariableTable" and "LocalVariableTypeTable"
+attributes of public library methods. Some IDEs can present these names to the
+developers who use the library.
+
+Finally, we're keeping the "Deprecated" attribute and the attributes for
+producing [useful stack traces](#stacktrace).
+
+We've also added some options for for processing [native methods](#native),
+[enumerations](#enumerations), [serializable classes](#serializable), and
+[annotations](#annotations), which are all discussed in their respective
+examples.
+
+### All possible applications in the input jars {: #applications}
+
+These options shrink, optimize, and obfuscate all public applications in
+`in.jar`:
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+-printseeds
+
+-keepclasseswithmembers public class * {
+ public static void main(java.lang.String[]);
+}
+```
+
+Note the use of [`-keepclasseswithmembers`](usage.md#keepclasseswithmembers).
+We don't want to preserve all classes, just all classes that have main
+methods, _and_ those methods.
+
+The [`-printseeds`](usage.md#printseeds) option prints out which classes
+exactly will be preserved, so we know for sure we're getting what we want.
+
+If applicable, you should add options for processing [native
+methods](#native), [callback methods](#callback),
+[enumerations](#enumerations), [serializable classes](#serializable), [bean
+classes](#beans), [annotations](#annotations), and [resource
+files](#resourcefiles).
+
+### All possible applets in the input jars {: #applets}
+
+These options shrink, optimize, and obfuscate all public applets in `in.jar`:
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+-libraryjars /jmods/java.desktop.jmod(!**.jar;!module-info.class)
+-printseeds
+
+-keep public class * extends java.applet.Applet
+```
+
+We're simply keeping all classes that extend the `Applet` class.
+
+Again, the [`-printseeds`](usage.md#printseeds) option prints out which
+applets exactly will be preserved.
+
+If applicable, you should add options for processing [native
+methods](#native), [callback methods](#callback),
+[enumerations](#enumerations), [serializable classes](#serializable), [bean
+classes](#beans), [annotations](#annotations), and [resource
+files](#resourcefiles).
+
+### All possible midlets in the input jars {: #midlets}
+
+These options shrink, optimize, obfuscate, and preverify all public midlets in
+`in.jar`:
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /usr/local/java/wtk2.5.2/lib/midpapi20.jar
+-libraryjars /usr/local/java/wtk2.5.2/lib/cldcapi11.jar
+-overloadaggressively
+-repackageclasses ''
+-allowaccessmodification
+-microedition
+-printseeds
+
+-keep public class * extends javax.microedition.midlet.MIDlet
+```
+
+We're simply keeping all classes that extend the `MIDlet` class.
+
+The [`-microedition`](usage.md#microedition) option makes sure the class files
+are preverified for Java Micro Edition, producing compact `StackMap`
+attributes. It is no longer necessary to run an external preverifier.
+
+Be careful if you do use the external `preverify` tool on a platform with a
+case-insensitive filing system, such as Windows. Because this tool unpacks
+your processed jars, you should then use ProGuard's
+[`-dontusemixedcaseclassnames`](usage.md#dontusemixedcaseclassnames) option.
+
+The [`-printseeds`](usage.md#printseeds) option prints out which midlets
+exactly will be preserved.
+
+If applicable, you should add options for processing [native methods](#native)
+and [resource files](#resourcefiles).
+
+Note that you will still have to adapt the midlet jar size in the
+corresponding jad file; ProGuard doesn't do that for you.
+
+### All possible Java Card applets in the input jars {: #jcapplets}
+
+These options shrink, optimize, and obfuscate all public Java Card
+applets in `in.jar`:
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /usr/local/java/javacard2.2.2/lib/api.jar
+-dontwarn java.lang.Class
+-overloadaggressively
+-repackageclasses ''
+-allowaccessmodification
+-printseeds
+
+-keep public class * implements javacard.framework.Applet
+```
+
+We're simply keeping all classes that implement the `Applet` interface.
+
+The [`-printseeds`](usage.md#printseeds) option prints out which applets
+exactly will be preserved.
+
+### All possible xlets in the input jars {: #xlets}
+
+These options shrink, optimize, and obfuscate all public xlets in `in.jar`:
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /usr/local/java/jtv1.1/javatv.jar
+-libraryjars /usr/local/java/cdc1.1/lib/cdc.jar
+-libraryjars /usr/local/java/cdc1.1/lib/btclasses.zip
+-overloadaggressively
+-repackageclasses ''
+-allowaccessmodification
+-printseeds
+
+-keep public class * implements javax.tv.xlet.Xlet
+```
+
+We're simply keeping all classes that implement the `Xlet` interface.
+
+The [`-printseeds`](usage.md#printseeds) option prints out which xlets exactly
+will be preserved.
+
+### All possible servlets in the input jars {: #servlets}
+
+These options shrink, optimize, and obfuscate all public servlets in `in.jar`:
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /lib/rt.jar
+-libraryjars /usr/local/java/servlet/servlet.jar
+-printseeds
+
+-keep public class * implements javax.servlet.Servlet
+```
+
+Keeping all servlets is very similar to keeping all applets. The servlet API
+is not part of the standard run-time jar, so we're specifying it as a library.
+Don't forget to use the right path name.
+
+We're then keeping all classes that implement the `Servlet` interface. We're
+using the `implements` keyword because it looks more familiar in this context,
+but it is equivalent to `extends`, as far as ProGuard is concerned.
+
+The [`-printseeds`](usage.md#printseeds) option prints out which
+servlets exactly will be preserved.
+
+If applicable, you should add options for processing [native
+methods](#native), [callback methods](#callback),
+[enumerations](#enumerations), [serializable classes](#serializable), [bean
+classes](#beans), [annotations](#annotations), and [resource
+files](#resourcefiles).
+
+### Scala applications with the Scala runtime {: #scala}
+
+These options shrink, optimize, and obfuscate all public Scala applications in
+`in.jar`:
+```proguard
+-injars in.jar
+-injars /usr/local/java/scala-2.9.1/lib/scala-library.jar
+-outjars out.jar
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+
+-dontwarn scala.**
+
+-keepclasseswithmembers public class * {
+ public static void main(java.lang.String[]);
+}
+
+-keep class * implements org.xml.sax.EntityResolver
+
+-keepclassmembers class * {
+ ** MODULE$;
+}
+
+-keepclassmembernames class scala.concurrent.forkjoin.ForkJoinPool {
+ long eventCount;
+ int workerCounts;
+ int runControl;
+ scala.concurrent.forkjoin.ForkJoinPool$WaitQueueNode syncStack;
+ scala.concurrent.forkjoin.ForkJoinPool$WaitQueueNode spareStack;
+}
+
+-keepclassmembernames class scala.concurrent.forkjoin.ForkJoinWorkerThread {
+ int base;
+ int sp;
+ int runState;
+}
+
+-keepclassmembernames class scala.concurrent.forkjoin.ForkJoinTask {
+ int status;
+}
+
+-keepclassmembernames class scala.concurrent.forkjoin.LinkedTransferQueue {
+ scala.concurrent.forkjoin.LinkedTransferQueue$PaddedAtomicReference head;
+ scala.concurrent.forkjoin.LinkedTransferQueue$PaddedAtomicReference tail;
+ scala.concurrent.forkjoin.LinkedTransferQueue$PaddedAtomicReference cleanMe;
+}
+```
+
+The configuration is essentially the same as for [processing
+applications](#applications), because Scala is compiled to ordinary Java
+bytecode. However, the example processes the Scala runtime library as well.
+The processed jar can be an order of magnitude smaller and a few times faster
+than the original code (for the Scala code examples, for instance).
+
+The [`-dontwarn`](usage.md#dontwarn) option tells ProGuard not to complain
+about some artefacts in the Scala runtime, the way it is compiled by the
+`scalac` compiler (at least in Scala 2.9.1 and older). Note that this option
+should always be used with care.
+
+The additional [`-keep`](usage.md#keepoverview) options make sure that some
+classes and some fields that are accessed by means of introspection are not
+removed or renamed.
+
+If applicable, you should add options for processing [native
+methods](#native), [callback methods](#callback),
+[enumerations](#enumerations), [serializable classes](#serializable), [bean
+classes](#beans), [annotations](#annotations), and [resource
+files](#resourcefiles).
+
+## Processing common code constructs {: #commonconstructs}
+
+### Processing native methods {: #native}
+
+If your application, applet, servlet, library, etc., contains native methods,
+you'll want to preserve their names and their classes' names, so they can
+still be linked to the native library. The following additional option will
+ensure that:
+```proguard
+-keepclasseswithmembernames,includedescriptorclasses class * {
+ native ;
+}
+```
+
+Note the use of
+[`-keepclasseswithmembernames`](usage.md#keepclasseswithmembernames). We don't
+want to preserve all classes or all native methods; we just want to keep the
+relevant names from being obfuscated. The modifier
+[includedescriptorclasses](usage.md#includedescriptorclasses) additionally
+makes sure that the return types and parameter types aren't renamed either, so
+the entire signatures remain compatible with the native libraries.
+
+ProGuard doesn't look at your native code, so it won't automatically preserve
+the classes or class members that are invoked by the native code. These are
+entry points, which you'll have to specify explicitly. [Callback
+methods](#callback) are discussed below as a typical example.
+
+### Processing callback methods {: #callback}
+
+If your application, applet, servlet, library, etc., contains callback
+methods, which are called from external code (native code, scripts,...),
+you'll want to preserve them, and probably their classes too. They are just
+entry points to your code, much like, say, the main method of an application.
+If they aren't preserved by other [`-keep`](usage.md#keep) options, something
+like the following option will keep the callback class and method:
+```proguard
+-keep class com.example.MyCallbackClass {
+ void myCallbackMethod(java.lang.String);
+}
+```
+
+This will preserve the given class and method from being removed or renamed.
+
+### Processing enumeration classes {: #enumerations}
+
+If your application, applet, servlet, library, etc., contains enumeration
+classes, you'll have to preserve some special methods. Enumerations were
+introduced in Java 5. The java compiler translates enumerations into classes
+with a special structure. Notably, the classes contain implementations of some
+static methods that the run-time environment accesses by introspection (Isn't
+that just grand? Introspection is the self-modifying code of a new
+generation). You have to specify these explicitly, to make sure they aren't
+removed or obfuscated:
+```proguard
+-keepclassmembers,allowoptimization enum * {
+ public static **[] values();
+ public static ** valueOf(java.lang.String);
+}
+```
+
+### Processing serializable classes {: #serializable}
+
+More complex applications, applets, servlets, libraries, etc., may
+contain classes that are serialized. Depending on the way in which they
+are used, they may require special attention:
+
+- Often, serialization is simply a means of transporting data, without
+ long-term storage. Classes that are shrunk and obfuscated should then
+ continue to function fine with the following additional options:
+```proguard
+ -keepclassmembers class * implements java.io.Serializable {
+ private static final java.io.ObjectStreamField[] serialPersistentFields;
+ private void writeObject(java.io.ObjectOutputStream);
+ private void readObject(java.io.ObjectInputStream);
+ java.lang.Object writeReplace();
+ java.lang.Object readResolve();
+ }
+```
+
+ The [`-keepclassmembers`](usage.md#keepclassmembers) option makes sure
+ that any serialization methods are kept. By using this option instead of
+ the basic `-keep` option, we're not forcing preservation of *all*
+ serializable classes, just preservation of the listed members of classes
+ that are actually used.
+
+- Sometimes, the serialized data are stored, and read back later into newer
+ versions of the serializable classes. One then has to take care the classes
+ remain compatible with their unprocessed versions and with future processed
+ versions. In such cases, the relevant classes will most likely have
+ `serialVersionUID` fields. The following options should then be sufficient
+ to ensure compatibility over time:
+```proguard
+ -keepnames class * implements java.io.Serializable
+
+ -keepclassmembers class * implements java.io.Serializable {
+ static final long serialVersionUID;
+ private static final java.io.ObjectStreamField[] serialPersistentFields;
+ !static !transient ;
+ private void writeObject(java.io.ObjectOutputStream);
+ private void readObject(java.io.ObjectInputStream);
+ java.lang.Object writeReplace();
+ java.lang.Object readResolve();
+ }
+```
+
+ The `serialVersionUID` and `serialPersistentFields` lines makes sure those
+ fields are preserved, if they are present. The `` line preserves
+ all non-static, non-transient fields, with their original names. The
+ introspection of the serialization process and the de-serialization
+ process will then find consistent names.
+
+- Occasionally, the serialized data have to remain compatible, but the classes
+ involved lack `serialVersionUID` fields. I imagine the original code will
+ then be hard to maintain, since the serial version UID is then computed from
+ a list of features the serializable class. Changing the class ever so
+ slightly may change the computed serial version UID. The list of features is
+ specified in the section on [Stream Unique
+ Identifiers](http://docs.oracle.com/javase/8/docs/platform/serialization/spec/class.html#a4100)
+ of Sun's [Java Object Serialization
+ Specification](http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html).
+ The following directives should at least partially ensure compatibility with
+ the original classes:
+```proguard
+ -keepnames class * implements java.io.Serializable
+
+ -keepclassmembers class * implements java.io.Serializable {
+ static final long serialVersionUID;
+ private static final java.io.ObjectStreamField[] serialPersistentFields;
+ !static !transient ;
+ !private ;
+ !private ;
+ private void writeObject(java.io.ObjectOutputStream);
+ private void readObject(java.io.ObjectInputStream);
+ java.lang.Object writeReplace();
+ java.lang.Object readResolve();
+ }
+```
+
+ The new options force preservation of the elements involved in the UID
+ computation. In addition, the user will have to manually specify all
+ interfaces of the serializable classes (using something like "`-keep
+ interface MyInterface`"), since these names are also used when computing
+ the UID. A fast but sub-optimal alternative would be simply keeping all
+ interfaces with "`-keep interface *`".
+
+- In the rare event that you are serializing lambda expressions in Java 8 or
+ higher, you need to preserve some methods and adapt the hard-coded names of
+ the classes in which they occur:
+```proguard
+ -keepclassmembers class * {
+ private static synthetic java.lang.Object $deserializeLambda$(java.lang.invoke.SerializedLambda);
+ }
+
+ -keepclassmembernames class * {
+ private static synthetic *** lambda$*(...);
+ }
+
+ -adaptclassstrings com.example.Test
+```
+
+ This should satisfy the reflection in the deserialization code of the Java
+ run-time.
+
+Note that the above options may preserve more classes and class members than
+strictly necessary. For instance, a large number of classes may implement the
+`Serialization` interface, yet only a small number may actually ever be
+serialized. Knowing your application and tuning the configuration often
+produces more compact results.
+
+### Processing bean classes {: #beans}
+
+If your application, applet, servlet, library, etc., makes extensive use of
+introspection on bean classes to find bean editor classes, or getter and
+setter methods, then configuration may become painful. There's not much else
+you can do than making sure the bean class names, or the getter and setter
+names don't change. For instance:
+```proguard
+-keep public class com.example.MyBean {
+ public void setMyProperty(int);
+ public int getMyProperty();
+}
+
+-keep public class com.example.MyBeanEditor
+```
+
+If there are too many elements to list explicitly, wildcards in class
+names and method signatures might be helpful. This example preserves all
+possible setters and getters in classes in the package `mybeans`:
+```proguard
+-keep class mybeans.** {
+ void set*(***);
+ void set*(int, ***);
+
+ boolean is*();
+ boolean is*(int);
+
+ *** get*();
+ *** get*(int);
+}
+```
+
+The '`***`' wildcard matches any type (primitive or non-primitive, array
+or non-array). The methods with the '`int`' arguments matches properties
+that are lists.
+
+### Processing annotations {: #annotations}
+
+If your application, applet, servlet, library, etc., uses annotations, you may
+want to preserve them in the processed output. Annotations are represented by
+attributes that have no direct effect on the execution of the code. However,
+their values can be retrieved through introspection, allowing developers to
+adapt the execution behavior accordingly. By default, ProGuard treats
+annotation attributes as optional, and removes them in the obfuscation step.
+If they are required, you'll have to specify this explicitly:
+```proguard
+-keepattributes *Annotation*
+```
+
+For brevity, we're specifying a wildcarded attribute name, which will match
+`RuntimeVisibleAnnotations`, `RuntimeInvisibleAnnotations`,
+`RuntimeVisibleParameterAnnotations`, `RuntimeInvisibleParameterAnnotations`,
+and `AnnotationDefault`. Depending on the purpose of the processed code, you
+could refine this selection, for instance not keeping the run-time invisible
+annotations (which are only used at compile-time).
+
+Some code may make further use of introspection to figure out the enclosing
+methods of anonymous inner classes. In that case, the corresponding attribute
+has to be preserved as well:
+```proguard
+-keepattributes EnclosingMethod
+```
+
+### Processing database drivers {: #database}
+
+Database drivers are implementations of the `Driver` interface. Since they are
+often created dynamically, you may want to preserve any implementations that
+you are processing as entry points:
+```proguard
+-keep class * implements java.sql.Driver
+```
+
+This option also gets rid of the note that ProGuard prints out about
+`(java.sql.Driver)Class.forName` constructs, if you are instantiating a driver
+in your code (without necessarily implementing any drivers yourself).
+
+### Processing ComponentUI classes {: #componentui}
+
+Swing UI look and feels are implemented as extensions of the `ComponentUI`
+class. For some reason, these have to contain a static method `createUI`,
+which the Swing API invokes using introspection. You should therefore always
+preserve the method as an entry point, for instance like this:
+```proguard
+-keep class * extends javax.swing.plaf.ComponentUI {
+ public static javax.swing.plaf.ComponentUI createUI(javax.swing.JComponent);
+}
+```
+
+This option also keeps the classes themselves.
+
+## Processing common libraries {: #commonlibraries}
+
+### Processing RMI code {: #rmi}
+
+Reportedly, the easiest way to handle RMI code is to process the code with
+ProGuard first and then invoke the `rmic` tool. If that is not possible, you
+may want to try something like this:
+```proguard
+-keepattributes Exceptions
+
+-keep interface * extends java.rmi.Remote {
+ ;
+}
+
+-keep class * implements java.rmi.Remote {
+ (java.rmi.activation.ActivationID, java.rmi.MarshalledObject); {: #activation}
+}
+```
+
+The first [`-keep`](usage.md#keep) option keeps all your Remote interfaces and
+their methods. The second one keeps all the implementations, along with their
+particular RMI constructors, if any.
+
+The `Exceptions` attribute has to be kept too, because the RMI handling code
+performs introspection to check whether the method signatures are compatible.
+
+### Optimizing Gson code {: #gson}
+
+ProGuard [optimizes Gson code](optimizations.md#gson), by detecting which
+domain classes are serialized using the Gson library, and then replacing the
+reflection-based implementation by more efficient hard-coded serialization.
+
+The GSON optimization is enabled by default and doesn't require any additional
+configuration. If you've disabled optimization, the GSON library still relies
+on reflection on the fields of the classes that it serializes. You then need
+to preserve the parameterless constructor and the serialized fields from being
+removed, optimized, or obfuscated. For example:
+```proguard
+-keepclassmembers class com.example.SerializedClass {
+ ;
+ ();
+}
+```
+
+While creating the configuration, you can specify the option
+[`-addconfigurationdebugging`](usage.md#addconfigurationdebugging), to get
+feedback on the necessary settings at run-time.
+
+Alternatively, you can make sure the fields are explicitly annotated with
+`@SerializedName`, so the names of the fields can be obfuscated. You can
+then keep all of them at the same time with:
+```proguard
+-keepclasseswithmembers,allowobfuscation,includedescriptorclasses class * {
+ @com.google.gson.annotations.SerializedName ;
+}
+
+-keepclassmembers enum * {
+ @com.google.gson.annotations.SerializedName ;
+}
+```
+
+### Processing dependency injection {: #injection}
+
+If your application is using JEE-style dependency injection, the application
+container will automatically assign instances of resource classes to fields
+and methods that are annotated with `@Resource`. The container applies
+introspection, even accessing private class members directly. It typically
+constructs a resource name based on the type name and the class member name.
+We then have to avoid that such class members are removed or renamed:
+```proguard
+-keepclassmembers class * {
+ @javax.annotation.Resource *;
+}
+```
+
+The Spring framework has another similar annotation `@Autowired`:
+```proguard
+-keepclassmembers class * {
+ @org.springframework.beans.factory.annotation.Autowired *;
+}
+```
+
+## Further processing possibilities {: #furtherpossibilities}
+
+### Processing resource files {: #resourcefiles}
+
+If your application, applet, servlet, library, etc., contains resource files,
+it may be necessary to adapt their names and/or their contents when the
+application is obfuscated. The following two options can achieve this
+automatically:
+```proguard
+-adaptresourcefilenames **.properties,**.gif,**.jpg
+-adaptresourcefilecontents **.properties,META-INF/MANIFEST.MF
+```
+
+The [`-adaptresourcefilenames`](usage.md#adaptresourcefilenames) option in
+this case renames properties files and image files in the processed output,
+based on the obfuscated names of their corresponding class files (if any). The
+[`-adaptresourcefilecontents`](usage.md#adaptresourcefilecontents) option
+looks for class names in properties files and in the manifest file, and
+replaces these names by the obfuscated names (if any). You'll probably want to
+adapt the filters to suit your application.
+
+### Processing manifest files {: #manifestfiles}
+
+As illustrated in the previous section, manifest files can be treated like
+ordinary resource files. ProGuard can adapt obfuscated class names in the
+files, but it won't make any other changes. If you want anything else, you
+should apply an external tool. For instance, if a manifest file contains
+signing information, you should sign the jar again after it has been
+processed.
+
+If you're merging several input jars into a single output jar, you'll have to
+pick one, typically by specifying [filters](usage.md#filters):
+```proguard
+-injars in1.jar
+-injars in2.jar(!META-INF/MANIFEST.MF)
+-injars in3.jar(!META-INF/MANIFEST.MF)
+-outjars out.jar
+```
+
+The filters will let ProGuard copy the manifest file from the first jar and
+ignore any manifest files in the second and third input jars. Note that
+ProGuard will leave the order of the files in the jars unchanged; manifest
+files are not necessarily put first.
+
+### Producing useful obfuscated stack traces {: #stacktrace}
+
+These options let obfuscated applications or libraries produce stack traces
+that can still be deciphered later on:
+```proguard
+-printmapping out.map
+
+-renamesourcefileattribute SourceFile
+-keepattributes SourceFile,LineNumberTable
+```
+
+We're keeping all source file attributes, but we're replacing their values by
+the string "SourceFile". We could use any string. This string is already
+present in all class files, so it doesn't take up any extra space. If you're
+working with J++, you'll want to keep the "SourceDir" attribute as well.
+
+We're also keeping the line number tables of all methods.
+
+Whenever both of these attributes are present, the Java run-time environment
+will include line number information when printing out exception stack traces.
+
+The information will only be useful if we can map the obfuscated names back to
+their original names, so we're saving the mapping to a file `out.map`. The
+information can then be used by the [ReTrace](../tools/retrace.md) tool to
+restore the original stack trace.
+
+### Obfuscating package names {: #repackaging}
+
+Package names can be obfuscated in various ways, with increasing levels of
+obfuscation and compactness. For example, consider the following classes:
+```proguard
+mycompany.myapplication.MyMain
+mycompany.myapplication.Foo
+mycompany.myapplication.Bar
+mycompany.myapplication.extra.FirstExtra
+mycompany.myapplication.extra.SecondExtra
+mycompany.util.FirstUtil
+mycompany.util.SecondUtil
+```
+
+Let's assume the class name `mycompany.myapplication.MyMain` is the main
+application class that is kept by the configuration. All other class names can
+be obfuscated.
+
+By default, packages that contain classes that can't be renamed aren't renamed
+either, and the package hierarchy is preserved. This results in obfuscated
+class names like these:
+```proguard
+mycompany.myapplication.MyMain
+mycompany.myapplication.a
+mycompany.myapplication.b
+mycompany.myapplication.a.a
+mycompany.myapplication.a.b
+mycompany.a.a
+mycompany.a.b
+```
+
+The [`-flattenpackagehierarchy`](usage.md#flattenpackagehierarchy) option
+obfuscates the package names further, by flattening the package hierarchy of
+obfuscated packages:
+```proguard
+-flattenpackagehierarchy 'myobfuscated'
+```
+
+The obfuscated class names then look as follows:
+```proguard
+mycompany.myapplication.MyMain
+mycompany.myapplication.a
+mycompany.myapplication.b
+myobfuscated.a.a
+myobfuscated.a.b
+myobfuscated.b.a
+myobfuscated.b.b
+```
+
+Alternatively, the [`-repackageclasses`](usage.md#repackageclasses) option
+obfuscates the entire packaging, by combining obfuscated classes into a single
+package:
+```proguard
+-repackageclasses 'myobfuscated'
+```
+
+The obfuscated class names then look as follows:
+```proguard
+mycompany.myapplication.MyMain
+mycompany.myapplication.a
+mycompany.myapplication.b
+myobfuscated.a
+myobfuscated.b
+myobfuscated.c
+myobfuscated.d
+```
+
+Additionally specifying the
+[`-allowaccessmodification`](usage.md#allowaccessmodification) option allows
+access permissions of classes and class members to be broadened, opening up
+the opportunity to repackage all obfuscated classes:
+```proguard
+-repackageclasses 'myobfuscated'
+-allowaccessmodification
+```
+
+The obfuscated class names then look as follows:
+```proguard
+mycompany.myapplication.MyMain
+myobfuscated.a
+myobfuscated.b
+myobfuscated.c
+myobfuscated.d
+myobfuscated.e
+myobfuscated.f
+```
+
+The specified target package can always be the root package. For
+instance:
+```proguard
+-repackageclasses ''
+-allowaccessmodification
+```
+
+The obfuscated class names are then the shortest possible names:
+```proguard
+mycompany.myapplication.MyMain
+a
+b
+c
+d
+e
+f
+```
+
+Note that not all levels of obfuscation of package names may be acceptable for
+all code. Notably, you may have to take into account that your application may
+contain [resource files](#resourcefiles) that have to be adapted.
+
+### Removing logging code {: #logging}
+
+You can let ProGuard remove logging code. The trick is to specify that the
+logging methods don't have side-effects — even though they actually do, since
+they write to the console or to a log file. ProGuard will take your word for
+it and remove the invocations (in the optimization step) and if possible the
+logging classes and methods themselves (in the shrinking step).
+
+For example, this configuration removes invocations of some
+logging methods:
+```proguard
+-assumenosideeffects class com.example.MyLogger {
+ public static boolean isLoggable(java.lang.String, int);
+ public static int v(...);
+ public static int i(...);
+ public static int w(...);
+ public static int d(...);
+ public static int e(...);
+}
+```
+
+The wildcards are a shortcut to match all versions of the methods. Be careful
+not to use a `*` wildcard to match all methods, because it would also match
+methods like `wait()`, higher up the hierarchy. Removing those invocations
+will generally break your code.
+
+Note that you generally can't remove logging code that uses
+`System.out.println`, since you would be removing all invocations of
+`java.io.PrintStream#println`, which could break your application. You can
+work around it by creating your own logging methods and let ProGuard remove
+those.
+
+Logging statements often contain implicit calls that perform string
+concatenation. They no longer serve a purpose after the logging calls have
+been removed. You can let ProGuard clean up such constructs as well by
+providing additional hints:
+```proguard
+-assumenoexternalsideeffects class java.lang.StringBuilder {
+ public java.lang.StringBuilder();
+ public java.lang.StringBuilder(int);
+ public java.lang.StringBuilder(java.lang.String);
+ public java.lang.StringBuilder append(java.lang.Object);
+ public java.lang.StringBuilder append(java.lang.String);
+ public java.lang.StringBuilder append(java.lang.StringBuffer);
+ public java.lang.StringBuilder append(char[]);
+ public java.lang.StringBuilder append(char[], int, int);
+ public java.lang.StringBuilder append(boolean);
+ public java.lang.StringBuilder append(char);
+ public java.lang.StringBuilder append(int);
+ public java.lang.StringBuilder append(long);
+ public java.lang.StringBuilder append(float);
+ public java.lang.StringBuilder append(double);
+ public java.lang.String toString();
+}
+
+-assumenoexternalreturnvalues public final class java.lang.StringBuilder {
+ public java.lang.StringBuilder append(java.lang.Object);
+ public java.lang.StringBuilder append(java.lang.String);
+ public java.lang.StringBuilder append(java.lang.StringBuffer);
+ public java.lang.StringBuilder append(char[]);
+ public java.lang.StringBuilder append(char[], int, int);
+ public java.lang.StringBuilder append(boolean);
+ public java.lang.StringBuilder append(char);
+ public java.lang.StringBuilder append(int);
+ public java.lang.StringBuilder append(long);
+ public java.lang.StringBuilder append(float);
+ public java.lang.StringBuilder append(double);
+}
+```
+
+Be careful specifying your own assumptions, since they can easily break
+your code.
+
+### Restructuring the output archives {: #restructuring}
+
+In simple applications, all output classes and resources files are merged into
+a single jar. For example:
+```proguard
+-injars classes
+-injars in1.jar
+-injars in2.jar
+-injars in3.jar
+-outjars out.jar
+```
+
+This configuration merges the processed versions of the files in the `classes`
+directory and the three jars into a single output jar `out.jar`.
+
+If you want to preserve the structure of your input jars (and/or apks, aars,
+wars, ears, jmods, zips, or directories), you can specify an output directory
+(or an apk, an aar, a war, an ear, a jmod, or a zip). For example:
+```proguard
+-injars in1.jar
+-injars in2.jar
+-injars in3.jar
+-outjars out
+```
+
+The input jars will then be reconstructed in the directory `out`, with their
+original names.
+
+You can also combine archives into higher level archives. For example:
+```proguard
+-injars in1.jar
+-injars in2.jar
+-injars in3.jar
+-outjars out.war
+```
+
+The other way around, you can flatten the archives inside higher level
+archives into simple archives:
+```proguard
+-injars in.war
+-outjars out.jar
+```
+
+This configuration puts the processed contents of all jars inside `in.war`
+(plus any other contents of `in.war`) into `out.jar`.
+
+If you want to combine input jars (and/or apks, aars, wars, ears, jmods, zips,
+or directories) into output jars (and/or apks, aars, wars, ears, jmods, zips,
+or directories), you can group the [`-injars`](usage.md#injars) and
+[`-outjars`](usage.md#outjars) options. For example:
+```proguard
+-injars base_in1.jar
+-injars base_in2.jar
+-injars base_in3.jar
+-outjars base_out.jar
+
+-injars extra_in.jar
+-outjars extra_out.jar
+```
+
+This configuration puts the processed results of all `base_in*.jar` jars into
+`base_out.jar`, and the processed results of the `extra_in.jar` into
+`extra_out.jar`. Note that only the order of the options matters; the
+additional whitespace is just for clarity.
+
+This grouping, archiving, and flattening can be arbitrarily complex. ProGuard
+always tries to package output archives in a sensible way, reconstructing the
+input entries as much as required.
+
+### Filtering the input and the output {: #filtering}
+
+If you want even greater control, you can add [filters](usage.md#filters) to
+the input and the output, filtering out apks, jars, aars, wars, ears, jmods,
+zips, and/or ordinary files. For example, if you want to disregard certain
+files from an input jar:
+```proguard
+-injars in.jar(!images/**)
+-outjars out.jar
+```
+
+This configuration removes any files in the `images` directory and its
+subdirectories.
+
+Such filters can be convenient for avoiding warnings about duplicate files in
+the output. For example, only keeping the manifest file from a first input
+jar:
+```proguard
+-injars in1.jar
+-injars in2.jar(!META-INF/MANIFEST.MF)
+-injars in3.jar(!META-INF/MANIFEST.MF)
+-outjars out.jar
+```
+
+Another useful application is ignoring unwanted files from the runtime library
+module:
+```proguard
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+```
+
+The filter makes ProGuard disregard redundant jars inside the module, and
+module info classes that would only cause conflicts with duplicate names.
+
+It is also possible to filter the jars (and/or apks, aabs, aars, wars, ears,
+jmods, zips) themselves, based on their names. For example:
+```proguard
+-injars in(**/acme_*.jar;)
+-outjars out.jar
+```
+
+Note the semi-colon in the filter; the filter in front of it applies to jar
+names. In this case, only `acme_*.jar` jars are read from the directory `in`
+and its subdirectories. Filters for war names, ear names, and zip names can be
+prefixed with additional semi-colons. All types of filters can be combined.
+They are orthogonal.
+
+On the other hand, you can also filter the output, in order to control what
+content goes where. For example:
+```proguard
+-injars in.jar
+-outjars code_out.jar(**.class)
+-outjars resources_out.jar
+```
+
+This configuration splits the processed output, sending `**.class` files to
+`code_out.jar`, and all remaining files to `resources_out.jar`.
+
+Again, the filtering can be arbitrarily complex, especially when combined with
+grouping input and output.
+
+### Processing multiple applications at once {: #multiple}
+
+You can process several dependent or independent applications (or applets,
+midlets,...) in one go, in order to save time and effort. ProGuard's input and
+output handling offers various ways to keep the output nicely structured.
+
+The easiest way is to specify your input jars (and/or wars, ears, zips, and
+directories) and a single output directory. ProGuard will then reconstruct the
+input in this directory, using the original jar names. For example, showing
+just the input and output options:
+```proguard
+-injars application1.jar
+-injars application2.jar
+-injars application3.jar
+-outjars processed_applications
+```
+
+After processing, the directory `processed_applications` will contain
+processed versions of application jars, with their original names.
+
+### Incremental obfuscation {: #incremental}
+
+After having [processed an application](#application), e.g. ProGuard itself,
+you can still incrementally add other pieces of code that depend on it, e.g.
+the ProGuard GUI:
+```proguard
+-injars proguardgui.jar
+-outjars proguardgui_out.jar
+-injars proguard.jar
+-outjars proguard_out.jar
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+-applymapping proguard.map
+
+-keep public class proguard.gui.ProGuardGUI {
+ public static void main(java.lang.String[]);
+}
+```
+
+We're reading both unprocessed jars as input. Their processed contents will go
+to the respective output jars. The [`-applymapping`](usage.md#applymapping)
+option then makes sure the ProGuard part of the code gets the previously
+produced obfuscation mapping. The final application will consist of the
+obfuscated ProGuard jar and the additional obfuscated GUI jar.
+
+The added code in this example is straightforward; it doesn't affect the
+original code. The `proguard_out.jar` will be identical to the one produced in
+the initial processing step. If you foresee adding more complex extensions to
+your code, you should specify the options
+[`-useuniqueclassmembernames`](usage.md#useuniqueclassmembernames),
+[`-dontshrink`](usage.md#dontshrink), and
+[`-dontoptimize`](usage.md#dontoptimize) *in the original processing step*.
+These options ensure that the obfuscated base jar will always remain usable
+without changes. You can then specify the base jar as a library jar:
+```proguard
+-injars proguardgui.jar
+-outjars proguardgui_out.jar
+-libraryjars proguard.jar
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+-applymapping proguard.map
+
+-keep public class proguard.gui.ProGuardGUI {
+ public static void main(java.lang.String[]);
+}
+```
+
+## Other uses {: #otheruses}
+
+### Preverifying class files for Java Micro Edition {: #microedition}
+
+Even if you're not interested in shrinking, optimizing, and obfuscating your
+midlets, as shown in the [midlets example](#midlets), you can still use
+ProGuard to preverify the class files for Java Micro Edition. ProGuard
+produces slightly more compact results than the traditional external
+preverifier.
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /usr/local/java/wtk2.5.2/lib/midpapi20.jar
+-libraryjars /usr/local/java/wtk2.5.2/lib/cldcapi11.jar
+
+-dontshrink
+-dontoptimize
+-dontobfuscate
+
+-microedition
+```
+
+We're not processing the input, just making sure the class files are
+preverified by targeting them at Java Micro Edition with the
+[`-microedition`](usage.md#microedition) option. Note that we don't need any
+[`-keep`](usage.md#keep) options to specify entry points; all class files are
+simply preverified.
+
+### Upgrading old class files to Java 6 {: #upgrade}
+
+The following options upgrade class files to Java 6, by updating their
+internal version numbers and preverifying them. The class files can then be
+loaded more efficiently by the Java 6 Virtual Machine.
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+
+-dontshrink
+-dontoptimize
+-dontobfuscate
+
+-target 1.6
+```
+
+We're not processing the input, just retargeting the class files with the
+[`-target`](usage.md#target) option. They will automatically be preverified
+for Java 6 as a result. Note that we don't need any `-keep` options to specify
+entry points; all class files are simply updated and preverified.
+
+### Finding dead code {: #deadcode}
+
+These options list unused classes, fields, and methods in the application
+`com.example.MyApplication`:
+```proguard
+-injars in.jar
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+
+-dontoptimize
+-dontobfuscate
+-dontpreverify
+-printusage
+
+-keep public class com.example.MyApplication {
+ public static void main(java.lang.String[]);
+}
+```
+
+We're not specifying an output jar, just printing out some results. We're
+saving some processing time by skipping the other processing steps.
+
+The java compiler inlines primitive constants and String constants (`static
+final` fields). ProGuard would therefore list such fields as not being used in
+the class files that it analyzes, even if they *are* used in the source files.
+We can add a [`-keepclassmembers`](usage.md#keepclassmembers) option that
+keeps those fields a priori, in order to avoid having them listed:
+```proguard
+-keepclassmembers class * {
+ static final % *;
+ static final java.lang.String *;
+}
+```
+
+### Printing out the internal structure of class files {: #structure}
+
+These options print out the internal structure of all class files in the
+input jar:
+```proguard
+-injars in.jar
+
+-dontshrink
+-dontoptimize
+-dontobfuscate
+-dontpreverify
+
+-dump
+```
+
+Note how we don't need to specify the Java run-time jar, because we're not
+processing the input jar at all.
+
+### Using annotations to configure ProGuard {: #annotated}
+
+The traditional ProGuard configuration allows to keep a clean separation
+between the code and the configuration for shrinking, optimization, and
+obfuscation. However, it is also possible to define specific annotations, and
+then annotate the code to configure the processing.
+
+You can find a set of such predefined annotations in `lib/annotations.jar` in
+the ProGuard distribution. The corresponding ProGuard configuration (or
+meta-configuration, if you prefer) is specified in
+`annotations/annotations.pro`. With these files, you can start annotating your
+code. For instance, a java source file `Application.java` can be annotated as
+follows:
+```java
+@KeepApplication
+public class Application {
+ ....
+}
+```
+
+The ProGuard configuration file for the application can then be simplified by
+leveraging these annotations:
+```proguard
+-injars in.jar
+-outjars out.jar
+-libraryjars /jmods/java.base.jmod(!**.jar;!module-info.class)
+
+-include lib/annotations.pro
+```
+
+The annotations are effectively replacing the application-dependent `-keep`
+options. You may still wish to add traditional [`-keep`](usage.md#keep)
+options for processing [native methods](#native),
+[enumerations](#enumerations), [serializable classes](#serializable), and
+[annotations](#annotations).
+
+The directory `examples/annotations` contains more examples that illustrate
+some of the possibilities.
diff --git a/proguard/docs/manual/configuration/optimizations.md b/proguard/docs/manual/configuration/optimizations.md
new file mode 100644
index 0000000..a8a2e68
--- /dev/null
+++ b/proguard/docs/manual/configuration/optimizations.md
@@ -0,0 +1,221 @@
+The optimization step of ProGuard can be switched off with the
+[`-dontoptimize`](usage.md#dontoptimize) option. For more fine-grained
+control over individual optimizations, experts can use the
+[`-optimizations`](usage.md#optimizations) option, with a filter based
+on the optimization names listed below. The filter works like any
+[filter](usage.md#filters) in ProGuard.
+
+The following wildcards are supported:
+
+| Wildcard | Meaning
+|-----|-------------------------------------------------------
+| `?` | matches any single character in an optimization name.
+| `*` | matches any part of an optimization name.
+
+An optimization that is preceded by an exclamation mark '**!**' is
+*excluded* from further attempts to match with *subsequent* optimization
+names in the filter. Make sure to specify filters correctly, since they
+are not checked for potential typos.
+
+For example,
+"**`code/simplification/variable,code/simplification/arithmetic`**" only
+performs the two specified peephole optimizations.
+
+For example, "`!method/propagation/*`" performs all optimizations,
+except the ones that propagate values between methods.
+
+For example, "`!code/simplification/advanced,code/simplification/*`"
+only performs all peephole optimizations.
+
+Some optimizations necessarily imply other optimizations. These are then
+indicated. Note that the list is likely to change for newer versions, as
+optimizations are added and reorganized.
+
+`library/gson`
+: Optimizes usages of the Gson library, whenever possible. See [Gson
+ optimization](optimizations.md#gson) for more details.
+
+`class/marking/final`
+: Marks classes as final, whenever possible.
+
+`class/unboxing/enum`
+: Simplifies enum types to integer constants, whenever possible.
+
+`class/merging/vertical`
+: Merges classes vertically in the class hierarchy, whenever possible.
+
+`class/merging/horizontal`
+: Merges classes horizontally in the class hierarchy, whenever possible.
+
+`class/merging/wrapper`
+: Merges wrapper classes with their wrapped classes, whenever possible.
+
+`field/removal/writeonly`
(⇒ `code/removal/advanced`)
+: Removes write-only fields.
+
+`field/marking/private`
+: Marks fields as private, whenever possible.
+
+`field/generalization/class`
+: Generalizes the classes of field accesses, whenever possible.
+
+`field/specialization/type`
+: Specializes the types of fields, whenever possible
+
+`field/propagation/value`
(⇒ `code/simplification/advanced`)
+: Propagates the values of fields across methods.
+
+`method/marking/private`
+: Marks methods as private, whenever possible (*devirtualization*).
+
+`method/marking/static`
(⇒ `code/removal/advanced`)
+: Marks methods as static, whenever possible (*devirtualization*).
+
+`method/marking/final`
+: Marks methods as final, whenever possible.
+
+`method/marking/synchronized`
+: Unmarks methods as synchronized, whenever possible.
+
+`method/removal/parameter`
(⇒ `code/removal/advanced`)
+: Removes unused method parameters.
+
+`method/generalization/class`
+: Generalizes the classes of method invocations, whenever possible.
+
+`method/specialization/parametertype`
+: Specializes the types of method parameters, whenever possible.
+
+`method/specialization/returntype`
+: Specializes the types of method return values, whenever possible.
+
+`method/propagation/parameter`
(⇒ `code/simplification/advanced`)
+: Propagates the values of method parameters from method invocations to the
+ invoked methods.
+
+`method/propagation/returnvalue`
(⇒ `code/simplification/advanced`)
+: Propagates the values of method return values from methods to their
+ invocations.
+
+`method/inlining/short`
+: Inlines short methods.
+
+`method/inlining/unique`
+: Inlines methods that are only called once.
+
+`method/inlining/tailrecursion`
+: Simplifies tail recursion calls, whenever possible.
+
+`code/merging`
+: Merges identical blocks of code by modifying branch targets.
+
+`code/simplification/variable`
+: Performs peephole optimizations for variable loading and storing.
+
+`code/simplification/arithmetic`
+: Performs peephole optimizations for arithmetic instructions.
+
+`code/simplification/cast`
+: Performs peephole optimizations for casting operations.
+
+`code/simplification/field`
+: Performs peephole optimizations for field loading and storing.
+
+`code/simplification/branch`
(⇒ `code/removal/simple`)
+: Performs peephole optimizations for branch instructions.
+
+`code/simplification/object`
+: Performs peephole optimizations for object instantiation.
+
+`code/simplification/string`
+: Performs peephole optimizations for constant strings.
+
+`code/simplification/math`
+: Performs peephole optimizations for Math method calls.
+
+`code/simplification/advanced`
(*best used with* `code/removal/advanced`)
+: Simplifies code based on control flow analysis and data flow analysis.
+
+`code/removal/advanced`
(⇒ `code/removal/exception`)
+: Removes dead code based on control flow analysis and data flow analysis.
+
+`code/removal/simple`
(⇒ `code/removal/exception`)
+: Removes dead code based on a simple control flow analysis.
+
+`code/removal/variable`
+: Removes unused variables from the local variable frame.
+
+`code/removal/exception`
+: Removes exceptions with empty try blocks.
+
+`code/allocation/variable`
+: Optimizes variable allocation on the local variable frame.
+
+ProGuard also provides some unofficial settings to control
+optimizations, that may disappear in future versions. These are Java
+system properties, which can be set as JVM arguments (with `-D...`):
+
+`maximum.inlined.code.length` (default = 8 bytes)
+: Specifies the maximum code length (expressed in bytes) of short methods
+ that are eligible to be inlined. Inlining methods that are too long may
+ unnecessarily inflate the code size.
+
+`maximum.resulting.code.length` (default = 8000 bytes for JSE, 2000 bytes for JME)
+: Specifies the maximum resulting code length (expressed in bytes) allowed
+ when inlining methods. Many Java virtual machines do not apply just-in-time
+ compilation to methods that are too long, so it's important not to let them
+ grow too large.
+
+## Aggressive optimization
+
+ProGuard provides the `-optimizeaggressively` option. If set, this enables more
+aggressive assumptions during optimization. This might lead to
+improved performance and/or reduced code size, but might result in different behavior in rare cases.
+For example, reading from an array might cause an
+`ArrayIndexOutOfBoundsException` to be thrown. Strictly speaking, this means
+that such an instruction can have a side effect. If this instruction is removed
+during optimization, the code will thus behave differently under specific
+circumstances. By default, such instructions are always preserved. Setting this
+option will lead to these instructions being candidates for removal during
+optimization. Additionally, class merging is only enabled when this option is set.
+
+## Gson optimization {: #gson}
+
+ProGuard optimizes Gson code by detecting which domain classes are serialized
+using the Gson library. It replaces the reflection-based implementation of
+GSON for reading and writing fields with injected and optimized code that
+accesses the fields of the domain classes directly when reading and writing
+JSON. The benefits of this optimization are the following:
+
+- Domain classes used in conjunction with GSON can be freely obfuscated.
+- The injected serialization code gives better performance compared to the
+ GSON implementation, which relies on reflection.
+- Less configuration is needed as the optimization automatically keeps classes
+ and fields that are required for serialization.
+
+### Configuration
+
+The Gson optimization is enabled by default and doesn't require any additional
+configuration, as long as the application code doesn't use unsupported Gson
+features(see [Known limitations](optimizations.md#gsonlimitations)).
+
+### Known limitations {: #gsonlimitations}
+
+ProGuard can not optimize the following use cases of Gson:
+
+- Serializing classes containing one of the following Gson annotations:
+ - `@JsonAdapter`
+ - `@Since`
+ - `@Until`
+- Serializing classes that have generic type variables in their signature.
+- Serializing classes using a Gson instance that was built with one of the
+ following settings on the GsonBuilder:
+ - `excludeFieldsWithModifier`
+ - `setFieldNamingPolicy`
+
+When one of the above Gson features is used, ProGuard automatically preserves
+the original Gson implementation for all affected domain classes.
+
+This means that the serialized fields of these domain classes need to be
+explicitly kept again in the ProGuard configuration so that they can be
+safely accessed through reflection.
diff --git a/proguard/docs/manual/configuration/usage.md b/proguard/docs/manual/configuration/usage.md
new file mode 100644
index 0000000..38fc112
--- /dev/null
+++ b/proguard/docs/manual/configuration/usage.md
@@ -0,0 +1,1020 @@
+This page lists all available options for ProGuard, grouped logically.
+
+!!! android R8
+ R8, the default Android shrinker, is compatible with ProGuard keep rules.
+
+## Input/Output Options {: #iooptions}
+
+`@`{: #at} [*filename*](#filename)
+: Short for '[`-include`](#include) [*filename*](#filename)'.
+
+`-include`{: #include} [*filename*](#filename)
+: Recursively reads configuration options from the given file *filename*.
+
+`-basedirectory`{: #basedirectory} [*directoryname*](#filename)
+: Specifies the base directory for all subsequent relative file names in
+ these configuration arguments or this configuration file.
+
+`-injars`{: #injars} [*class\_path*](#classpath)
+: Specifies the input jars (or apks, aabs, aars, wars, ears, jmods, 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 [filters](#filefilters) section. For better
+ readability, class path entries can be specified using multiple `-injars`
+ options.
+
+`-outjars`{: #outjars} [*class\_path*](#classpath)
+: Specifies the names of the output jars (or apks, aabs, aars, wars, ears,
+ jmods, zips, or directories). The processed input of the preceding
+ [`-injars`](usage.md#injars) 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 [filters](#filefilters) 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. You must
+ avoid letting the output files overwrite any input files. For better
+ readability, class path entries can be specified using multiple
+ [`-outjars`](usage.md#outjars) options. Without any
+ [`-outjars`](usage.md#outjars) options, no jars will be written.
+
+`-libraryjars`{: #libraryjars} [*class\_path*](#classpath)
+: Specifies the library jars (or apks, aabs, aars, wars, ears, jmods, zips,
+ 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 *extended* by application class
+ files. Library class files that are only *called* 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
+ [filters](#filefilters) section. For better readability, class path entries
+ can be specified using multiple `-libraryjars` options. 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 [J2SE
+ applications](examples.md#application) as well as [JME
+ midlets](examples.md#midlet), just by specifying the appropriate
+ run-time jar.
+
+`-skipnonpubliclibraryclasses`{: #skipnonpubliclibraryclasses}
+: 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.
+
+`-dontskipnonpubliclibraryclasses`{: #dontskipnonpubliclibraryclasses}
+: Specifies not to ignore non-public library classes. As of version 4.5,
+ this is the default setting.
+
+`-dontskipnonpubliclibraryclassmembers`{: #dontskipnonpubliclibraryclassmembers}
+: 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.
+
+`-keepdirectories`{: #keepdirectories} \[*[directory\_filter](#filefilters)*\]
+: Specifies the directories to be kept in the output jars (or apks, aabs,
+ aars, wars, ears, jmods, zips, or directories). By default, directory
+ entries are removed. This reduces the jar size, but it may break your
+ program if the code tries to find them with constructs like
+ "`com.example.MyClass.class.getResource("")`". You'll then want to keep the
+ directory corresponding to the package, "`-keepdirectories com.example`". If
+ the option is specified without a filter, all directories are kept. With a
+ filter, only matching directories are kept. For instance, "`-keepdirectories
+ mydirectory`" matches the specified directory, "`-keepdirectories
+ mydirectory/*`" matches its immediate subdirectories, and "`-keepdirectories
+ mydirectory/**`" matches all of its subdirectories.
+
+`-target`{: #target} *version*
+: **Deprecated: this option is only applicable for Java class file versions <= 11.**
+ Specifies the version number to be set in the processed class files. The
+ version number can be one of `1.0`,..., `1.9`, or the more recent short
+ numbers `5`,..., `12`. By default, the version numbers of the class files
+ are left unchanged. For example, you may want to [upgrade class files to
+ Java 6](examples.md#upgrade). ProGuard changes their version numbers and
+ preverifies them. You can also downgrade class files to older versions than
+ Java 8. ProGuard changes their version numbers and backports Java 8
+ constructs. ProGuard generally doesn't backport changes in the Java runtime,
+ except for the Java 8 stream API and the Java 8 date API, if you add the
+ backported libraries `net.sourceforge.streamsupport` and `org.threeten` as
+ input, respectively.
+
+`-forceprocessing`{: #forceprocessing}
+: 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.
+
+## Keep Options {: #keepoptions}
+
+!!! tip "ProGuard Playground"
+ The [**ProGuard Playground**](https://playground.proguard.com) is a useful tool to help you further tweak the keep rules.
+
+
+
+
+`-keep`{: #keep} \[[,*modifier*](#keepoptionmodifiers),...\] [*class\_specification*](#classspecification)
+: Specifies classes and class members (fields and methods) to be preserved
+ as entry points to your code. For example, in order to [keep an
+ application](examples.md#application), you can specify the main class along
+ with its main method. In order to [process a library](examples.md#library),
+ you should specify all publicly accessible elements.
+
+`-keepclassmembers`{: #keepclassmembers} \[[,*modifier*](#keepoptionmodifiers),...\] [*class\_specification*](#classspecification)
+: Specifies class members to be preserved, if their classes are preserved as
+ well. For example, you may want to [keep all serialization fields and
+ methods](examples.md#serializable) of classes that implement the
+ `Serializable` interface.
+
+`-keepclasseswithmembers`{: #keepclasseswithmembers} \[[,*modifier*](#keepoptionmodifiers),...\] [*class\_specification*](#classspecification)
+: 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
+ [keep all applications](examples.md#applications) that have a main method,
+ without having to list them explicitly.
+
+`-keepnames`{: #keepnames} [*class\_specification*](#classspecification)
+: Short for [`-keep`](#keep),[`allowshrinking`](#allowshrinking)
+ [*class\_specification*](#classspecification) 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 [keep all class
+ names](examples.md#serializable) of classes that implement the
+ `Serializable` 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.
+
+`-keepclassmembernames`{: #keepclassmembernames} [*class\_specification*](#classspecification)
+: Short for
+ [`-keepclassmembers`](#keepclassmembers),[`allowshrinking`](#allowshrinking)
+ [*class\_specification*](#classspecification) 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 `class$`
+ methods when [processing a library](examples.md#library) 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.
+
+`-keepclasseswithmembernames`{: #keepclasseswithmembernames} [*class\_specification*](#classspecification)
+: Short for
+ [`-keepclasseswithmembers`](#keepclasseswithmembers),[`allowshrinking`](#allowshrinking)
+ [*class\_specification*](#classspecification) 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 [keep all native method names](examples.md#native) 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.
+
+`-if`{: #if} [*class\_specification*](#classspecification)
+: Specifies classes and class members that must be `present` to activate the
+ subsequent keep option ([`-keep`](usage.md#keep),
+ [`-keepclassmembers`](usage.md#keepclassmembers),...). The condition and
+ the subsequent keep option can share wildcards and references to wildcards.
+ For example, you can keep classes on the condition that classes with related
+ names exist in your project, with frameworks like
+ [Dagger](examples.md#dagger) and [Butterknife](examples.md#butterknife).
+
+`-printseeds`{: #printseeds} \[[*filename*](#filename)\]
+: Specifies to exhaustively list classes and class members matched by the
+ various `-keep` 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 [applications](examples.md#applications) or all
+ the [applets](examples.md#applets) that you are keeping.
+
+## Shrinking Options {: #shrinkingoptions}
+
+`-dontshrink`{: #dontshrink}
+: Specifies not to shrink the input. By default, ProGuard shrinks the code: it
+ removes all unused classes and class members. It only keeps the ones listed
+ by the various [`-keep`](usage.md#keep) options, and the ones on which they
+ depend, directly or indirectly. It also applies a shrinking step after each
+ optimization step, since some optimizations may open up the possibility to
+ remove more classes and class members.
+
+`-printusage`{: #printusage} \[[*filename*](#filename)\]
+: 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 [list the
+ unused code of an application](examples.md#deadcode). Only applicable when
+ shrinking.
+
+`-whyareyoukeeping`{: #whyareyoukeeping} [*class\_specification*](#classspecification)
+: 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.
+ *In the current implementation, the shortest chain that is printed out may
+ sometimes contain circular deductions -- these do not reflect the actual
+ shrinking process.* If the [`-verbose`](#verbose) option if specified, the
+ traces include full field and method signatures. Only applicable when
+ shrinking.
+
+## Optimization Options {: #optimizationoptions}
+
+`-dontoptimize`{: #dontoptimize}
+: Specifies not to optimize the input class files. By default, ProGuard
+ optimizes all code. It inlines and merges classes and class members, and
+ it optimizes all methods at a bytecode level.
+
+`-optimizations`{: #optimizations} [*optimization\_filter*](optimizations.md)
+: Specifies the optimizations to be enabled and disabled, at a more
+ fine-grained level. Only applicable when optimizing. *This is an expert
+ option.*
+
+`-optimizationpasses`{: #optimizationpasses} *n*
+: 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.
+
+`-assumenosideeffects`{: #assumenosideeffects} [*class\_specification*](#classspecification)
+: Specifies methods that don't have any side effects, other than possibly
+ returning a value. For example, the method `System.currentTimeMillis()`
+ returns a value, but it doesn't have any side effects. In the optimization
+ step, ProGuard can then remove calls to such methods, if it can determine
+ that the return values aren't used. ProGuard will analyze your program code
+ to find such methods automatically. It will not analyze library code, for
+ which this option can therefore be useful. For example, you could specify
+ the method `System.currentTimeMillis()`, so that any idle calls to it will
+ be removed. With some care, you can also use the option to [remove logging
+ code](examples.md#logging). 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. *Only use this option if you know what you're doing!*
+
+`-assumenoexternalsideeffects`{: #assumenoexternalsideeffects} [*class\_specification*](#classspecification)
+: Specifies methods that don't have any side effects, except possibly on the
+ instances on which they are called. This statement is weaker than
+ [`-assumenosideeffects`](#assumenosideeffects), because it allows side
+ effects on the parameters or the heap. For example, the
+ `StringBuffer#append` methods have side effects, but no external side
+ effects. This is useful when [removing logging code](examples.md#logging),
+ to also remove any related string concatenation code. Only applicable when
+ optimizing. Making assumptions can be dangerous; you can easily break the
+ processed code. *Only use this option if you know what you're doing!*
+
+`-assumenoescapingparameters`{: #assumenoescapingparameters} [*class\_specification*](#classspecification)
+: Specifies methods that don't let their reference parameters escape to the
+ heap. Such methods can use, modify, or return the parameters, but not store
+ them in any fields, either directly or indirectly. For example, the method
+ `System.arrayCopy` does not let its reference parameters escape, but method
+ `System.setSecurityManager` does. Only applicable when optimizing. Making
+ assumptions can be dangerous; you can easily break the processed code. *Only
+ use this option if you know what you're doing!*
+
+`-assumenoexternalreturnvalues`{: #assumenoexternalreturnvalues} [*class\_specification*](#classspecification)
+: Specifies methods that don't return reference values that were already on
+ the heap when they are called. For example, the `ProcessBuilder#start`
+ returns a `Process` reference value, but it is a new instance that wasn't on
+ the heap yet. Only applicable when optimizing. Making assumptions can be
+ dangerous; you can easily break the processed code. *Only use this option if
+ you know what you're doing!*
+
+`-assumevalues`{: #assumevalues} [*class\_specification*](#classspecification)
+: Specifies fixed values or ranges of values for primitive fields and
+ methods. Making assumptions can be dangerous; you can easily break the
+ processed code. *Only use this option if you know what you're doing!*
+
+`-allowaccessmodification`{: #allowaccessmodification}
+: 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. [The Java
+ Language Specification, Third
+ Edition](http://docs.oracle.com/javase/specs/jls/se12/html/index.html),
+ [Section
+ 13.4.6](http://docs.oracle.com/javase/specs/jls/se12/html/jls-13.html#jls-13.4.6)),
+ some virtual machines would have problems with the processed code otherwise.
+ Only applicable when optimizing (and when obfuscating with the
+ [`-repackageclasses`](#repackageclasses) option). *Counter-indication:* 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.
+
+`-mergeinterfacesaggressively`{: #mergeinterfacesaggressively}
+: 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. [The Java Language
+ Specification, Third
+ Edition](http://docs.oracle.com/javase/specs/jls/se12/html/index.html),
+ [Section
+ 13.5.3](http://docs.oracle.com/javase/specs/jls/se12/html/jls-13.html#jls-13.5.3)),
+ even if they are not allowed in the Java language (cfr. [The Java Language
+ Specification, Third
+ Edition](http://docs.oracle.com/javase/specs/jls/se12/html/index.html),
+ [Section
+ 8.1.4](http://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.1.4)).
+ Only applicable when optimizing.
+
+ *Counter-indication:* 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:
+
+ - Sun's JRE 1.3 may throw an `InternalError` when encountering
+ more than 256 *Miranda* methods (interface methods
+ without implementations) in a class.
+
+`-optimizeaggressively`{: #optimizeaggressively}
+: Enables more aggressive assumptions during optimization. This might lead to
+ improved performance and/or reduced code size, but might result in different behavior in rare cases.
+ For example, reading from an array might cause an
+ `ArrayIndexOutOfBoundsException` to be thrown. Strictly speaking, this means
+ that such an instruction can have a side effect. If this instruction is removed
+ during optimization, the code will thus behave differently under specific
+ circumstances. By default, such instructions are always preserved. Setting this
+ option will lead to these instructions being candidates for removal during
+ optimization. Additionally, class merging is only enabled when this option is set.
+
+## Obfuscation Options {: #obfuscationoptions}
+
+`-dontobfuscate`{: #dontobfuscate}
+: Specifies not to obfuscate the input class files. By default, ProGuard
+ obfuscates the code: it assigns new short random names to classes and
+ class members. It removes internal attributes that are only useful for
+ debugging, such as source files names, variable names, and line numbers.
+
+`-printmapping`{: #printmapping} \[[*filename*](#filename)\]
+: 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
+ [incremental obfuscation](examples.md#incremental), or if you ever want to
+ make sense again of [obfuscated stack traces](examples.md#stacktrace). Only
+ applicable when obfuscating.
+
+`-applymapping`{: #applymapping} [*filename*](#filename)
+: 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 [incremental obfuscation](examples.md#incremental), i.e.
+ processing add-ons or small patches to an existing piece of code. If the
+ structure of the code changes fundamentally, ProGuard may print out warnings
+ that applying a mapping is causing conflicts. You may be able to reduce this
+ risk by specifying the option
+ [`-useuniqueclassmembernames`](#useuniqueclassmembernames) in both
+ obfuscation runs. Only a single mapping file is allowed. Only applicable
+ when obfuscating.
+
+`-obfuscationdictionary`{: #obfuscationdictionary} [*filename*](#filename)
+: 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
+ `#` 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.
+
+`-classobfuscationdictionary`{: #classobfuscationdictionary} [*filename*](#filename)
+: 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
+ [`-obfuscationdictionary`](#obfuscationdictionary). Only applicable when
+ obfuscating.
+
+`-packageobfuscationdictionary`{: #packageobfuscationdictionary} [*filename*](#filename)
+: 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 [`-obfuscationdictionary`](#obfuscationdictionary). Only applicable
+ when obfuscating.
+
+`-overloadaggressively`{: #overloadaggressively}
+: 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, as required by Java bytecode (not just their
+ arguments, as required by the Java language). This option can make the
+ processed code even smaller (and less comprehensible). Only applicable when
+ obfuscating.
+
+ *Counter-indication:* the resulting class files fall within the Java
+ bytecode specification (cfr. [The Java Virtual Machine
+ Specification](http://docs.oracle.com/javase/specs/jvms/se12/html/index.html),
+ first paragraphs of [Section
+ 4.5](http://docs.oracle.com/javase/specs/jvms/se12/html/jvms-4.html#jvms-4.5)
+ and [Section
+ 4.6](http://docs.oracle.com/javase/specs/jvms/se12/html/jvms-4.html#jvms-4.6)),
+ even though this kind of overloading is not allowed in the Java language
+ (cfr. [The Java Language Specification, Third
+ Edition](http://docs.oracle.com/javase/specs/jls/se12/html/index.html),
+ [Section
+ 8.3](http://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.3)
+ and [Section
+ 8.4.5](http://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.5)).
+ Still, some tools have problems with it. Notably:
+
+ - Sun's JDK 1.2.2 `javac` compiler produces an exception when
+ compiling with such a library (cfr. [Bug
+ \#4216736](http://bugs.sun.com/view_bug.do?bug_id=4216736)). You
+ probably shouldn't use this option for processing libraries.
+ - Sun's JRE 1.4 and later fail to serialize objects with
+ overloaded primitive fields.
+ - Sun's JRE 1.5 `pack200` tool reportedly has problems with
+ overloaded class members.
+ - The class `java.lang.reflect.Proxy` can't handle
+ overloaded methods.
+ - Google's Dalvik VM can't handle overloaded static fields.
+
+`-useuniqueclassmembernames`{: #useuniqueclassmembernames}
+: 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.
+
+ 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 *in the initial
+ obfuscation step*, such renaming will never be necessary.
+
+ 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.
+
+`-dontusemixedcaseclassnames`{: #dontusemixedcaseclassnames}
+: 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. Obfuscated jars will become slightly
+ larger as a result. Only applicable when obfuscating.
+
+`-keeppackagenames`{: #keeppackagenames} \[*[package\_filter](#filters)*\]
+: Specifies not to obfuscate the given package names. The optional filter is
+ a comma-separated list of package names. Package names can contain **?**,
+ **\***, and **\*\*** wildcards, and they can be preceded by the **!**
+ negator. Only applicable when obfuscating.
+
+`-flattenpackagehierarchy`{: #flattenpackagehierarchy} \[*package\_name*\]
+: 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 [obfuscating package names](examples.md#repackaging). It
+ can make the processed code smaller and less comprehensible. Only applicable
+ when obfuscating.
+
+`-repackageclasses`{: #repackageclasses} \[*package\_name*\]
+: 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 overrides the
+ [`-flattenpackagehierarchy`](#flattenpackagehierarchy) option. It is another
+ example of further [obfuscating package names](examples.md#repackaging).
+ It can make the processed code even smaller and less comprehensible. Its
+ deprecated name is `-defaultpackage`. Only applicable when obfuscating.
+
+ *Counter-indication:* 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.
+
+`-keepattributes`{: #keepattributes} \[*[attribute\_filter](attributes.md)*\]
+: Specifies any optional attributes to be preserved. The attributes can be
+ specified with one or more [`-keepattributes`](usage.md#keepattributes)
+ directives. The optional filter is a comma-separated list of [attribute
+ names](attributes.md) that Java virtual machines and ProGuard support.
+ Attribute names can contain **?**, **\***, and **\*\*** wildcards, and they
+ can be preceded by the **!** negator. For example, you should at least keep
+ the `Exceptions`, `InnerClasses`, and `Signature` attributes when
+ [processing a library](examples.md#library). You should also keep the
+ `SourceFile` and `LineNumberTable` attributes for [producing useful
+ obfuscated stack traces](examples.md#stacktrace). Finally, you may want to
+ [keep annotations](examples.md#annotations) if your code depends on them.
+ Only applicable when obfuscating.
+
+`-keepparameternames`{: #keepparameternames}
+: Specifies to keep the parameter names and types of methods that are kept.
+ This option actually keeps trimmed versions of the debugging attributes
+ `LocalVariableTable` and `LocalVariableTypeTable`. It can be useful when
+ [processing a library](examples.md#library). Some IDEs can use the
+ information to assist developers who use the library, for example with tool
+ tips or autocompletion. Only applicable when obfuscating.
+
+ When processing Kotlin metadata the Kotlin function, constructor and property setter
+ parameter names are also kept.
+
+`-renamesourcefileattribute`{: #renamesourcefileattribute} \[*string*\]
+: Specifies a constant string to be put in the `SourceFile` attributes (and
+ `SourceDir` 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 [`-keepattributes`](usage.md#keepattributes) directive. For example, you
+ may want to have your processed libraries and applications produce [useful
+ obfuscated stack traces](examples.md#stacktrace). Only applicable when
+ obfuscating.
+
+`-keepkotlinmetadata`{: #keepkotlinmetadata} {: .deprecated}
+: ** Deprecated: use `-keep class kotlin.Metadata` instead. **
+ Specifies to process `kotlin.Metadata` annotations if present.
+ Currently only shrinking and obfuscation of its content is supported.
+ Classes containing such annotations should be excuded from optimization
+ if this option is enabled.
+
+`-adaptclassstrings`{: #adaptclassstrings} \[*[class\_filter](#filters)*\]
+: 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.
+
+`-adaptresourcefilenames`{: #adaptresourcefilenames} \[*[file\_filter](#filefilters)*\]
+: 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 [processing resource
+ files](examples.md#resourcefiles). Only applicable when obfuscating.
+
+`-adaptresourcefilecontents`{: #adaptresourcefilecontents} \[*[file\_filter](#filefilters)*\]
+: Specifies the resource files and native libraries 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). Any function
+ names in the native libraries are renamed, based on the obfuscated names of
+ the corresponding native methods (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 UTF-8 encoding. For an
+ example, see [processing resource files](examples.md#resourcefiles). Only
+ applicable when obfuscating. *Caveat:* You probably only want to apply this
+ option to text files and native libraries, since parsing and adapting
+ general binary files as text files can cause unexpected problems. Therefore,
+ make sure that you specify a sufficiently narrow filter.
+
+## Preverification Options {: #preverificationoptions}
+
+`-dontpreverify`{: #dontpreverify}
+: 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 optional, but as of Java
+ 7, it is required.
+
+`-microedition`{: #microedition}
+: 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
+ [processing midlets](examples.md#midlets).
+
+`-android`{: #android}
+: Specifies that the processed class files are targeted at the Android
+ platform. ProGuard then makes sure some features are compatible with
+ Android.
+
+## General Options {: #generaloptions}
+
+`-verbose`{: #verbose}
+: 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.
+
+`-dontnote`{: #dontnote} \[*[class\_filter](#filters)*\]
+: Specifies not to print notes about potential mistakes or omissions in the
+ configuration, such as typos in class names or missing options that might be
+ useful. The optional filter is a regular expression; ProGuard doesn't print
+ notes about classes with matching names.
+
+`-dontwarn`{: #dontwarn} \[*[class\_filter](#filters)*\]
+: 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. *Only use this option if you know what you're doing!*
+
+`-ignorewarnings`{: #ignorewarnings}
+: 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. *Only use this option if you know what you're doing!*
+
+`-printconfiguration`{: #printconfiguration} \[[*filename*](#filename)\]
+: 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 to
+ debug configurations, or to convert XML configurations into a more
+ readable format.
+
+`-dump`{: #dump} \[[*filename*](#filename)\]
+: 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 [write out the contents of a given
+ jar file](examples.md#structure), without processing it at all.
+
+`-addconfigurationdebugging`{: #addconfigurationdebugging}
+: Specifies to instrument the processed code with debugging statements that
+ print out suggestions for missing ProGuard configuration. This can be very
+ useful to get practical hints _at run-time_, if your processed code crashes
+ because it still lacks some configuration for reflection. For example, the
+ code may be [serializing classes with the GSON library](examples.md#gson)
+ and you may need some configuration for it. You can generally just
+ copy/paste the suggestions from the console into your configuration file.
+ *Counter-indication:* do not use this option in release versions, as it adds
+ obfuscation information to the processed code.
+
+## Class Paths {: #classpath}
+
+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. '**:**' on Unix, or '**;**' on Windows
+platforms). The order of the entries determines their priorities, in
+case of duplicates.
+
+Each input entry can be:
+
+- A class file or resource file,
+- An apk file, containing any of the above,
+- A jar file, containing any of the above,
+- An aar file, containing any of the above,
+- A war file, containing any of the above,
+- An ear file, containing any of the above,
+- A jmod file, containing any of the above,
+- A zip file, containing any of the above,
+- A directory (structure), containing any of the above.
+
+The paths of directly specified class files and resource files is
+ignored, so class files should generally be part of a jar file, an aar
+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.
+
+Each output entry can be:
+
+- An apk file, in which all class files and resource files will
+ be collected.
+- A jar file, in which any and all of the above will be collected,
+- An aar file, in which any and all of the above will be collected,
+- A war file, in which any and all of the above will be collected,
+- An ear file, in which any and all of the above will be collected,
+- A jmod file, in which any and all of the above will be collected,
+- A zip file, in which any and all of the above will be collected,
+- A directory, in which any and all of the above will be collected.
+
+When writing output entries, ProGuard generally packages 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 [restructure output
+archives](examples.md#restructuring).
+
+Files and directories can be specified as discussed in the section on
+[file names](#filename) below.
+
+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 8 types of [file
+filters](#filefilters) between parentheses, separated by semi-colons:
+
+- A filter for all jmod names that are encountered,
+- A filter for all aar names that are encountered,
+- A filter for all apk names that are encountered,
+- A filter for all zip names that are encountered,
+- A filter for all ear names that are encountered,
+- A filter for all war names that are encountered,
+- A filter for all jar names that are encountered,
+- A filter for all class file names and resource file names that
+ are encountered.
+
+If fewer than 8 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:
+
+ classpathentry([[[[[[[jmodfilter;]aarfilter;]apkfilter;]zipfilter;]earfilter;]warfilter;]jarfilter;]filefilter)
+
+Square brackets "\[\]" mean that their contents are optional.
+
+For example, "`rt.jar(java/**.class,javax/**.class)`" matches all class
+files in the `java` and `javax` directories inside the `rt` jar.
+
+For example, "`input.jar(!**.gif,images/**)`" matches all files in the
+`images` directory inside the `input` jar, except gif files.
+
+The different filters are applied to all corresponding file types,
+irrespective of their nesting levels in the input; they are orthogonal.
+
+For example, "`input.war(lib/**.jar,support/**.jar;**.class,**.gif)`"
+only considers jar files in the `lib` and `support` directories in the
+`input` war, not any other jar files. It then matches all class files
+and gif files that are encountered.
+
+The filters allow for an almost infinite number of packaging and
+repackaging possibilities. The Examples section provides a few more
+examples for [filtering input and output](examples.md#filtering).
+
+## File Names {: #filename}
+
+ProGuard accepts absolute paths and relative paths for the various file
+names and directory names. A relative path is interpreted as follows:
+
+- relative to the base directory, if set, or otherwise
+- relative to the configuration file in which it is specified, if any,
+ or otherwise
+- relative to the working directory.
+
+The names can contain Java system properties (or Ant properties, when
+using Ant), delimited by angular brackets, '**<**' and '**>**'.
+The properties are automatically replaced by their corresponding values.
+
+For example, `/lib/rt.jar` is automatically expanded to
+something like `/usr/local/java/jdk/jre/lib/rt.jar`. Similarly,
+`` is expanded to the user's home directory, and ``
+is expanded to the current working directory.
+
+Names with special characters like spaces and parentheses must be quoted
+with single or double quotes. Each file name in a list of names has to
+be quoted individually. Note that the quotes themselves may need to be
+escaped when used on the command line, to avoid them being gobbled by
+the shell.
+
+For example, on the command line, you could use an option like
+`'-injars "my program.jar":"/your directory/your program.jar"'`.
+
+## File Filters {: #filefilters}
+
+Like general [filters](#filters), 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:
+
+| Wildcard | Meaning
+|------|-----------------------------------------------------------------------------------------
+| `?` | matches any single character in a file name.
+| `*` | matches any part of a filename not containing the directory separator.
+| `**` | matches any part of a filename, possibly containing any number of directory separators.
+
+For example, "`java/**.class,javax/**.class`" matches all class files in
+the `java` and `javax`.
+
+Furthermore, a file name can be preceded by an exclamation mark '**!**'
+to *exclude* the file name from further attempts to match with
+*subsequent* file names.
+
+For example, "`!**.gif,images/**`" matches all files in the `images`
+directory, except gif files.
+
+The Examples section provides a few more examples for [filtering input
+and output](examples.md#filtering).
+
+## Filters {: #filters}
+
+ProGuard offers options with filters for many different aspects of the
+configuration: names of files, directories, classes, packages,
+attributes, optimizations, etc.
+
+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:
+
+| Wildcard | Meaning
+|------|-----------------------------------------------------------------------------------------------------------
+| `?` | matches any single character in a name.
+| `*` | matches any part of a name not containing the package separator or directory separator.
+| `**` | matches any part of a name, possibly containing any number of package separators or directory separators.
+
+For example, "`foo,*bar`" matches the name `foo` and all names ending
+with `bar`.
+
+Furthermore, a name can be preceded by a negating exclamation mark
+'**!**' to *exclude* the name from further attempts to match with
+*subsequent* 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.
+
+For example, "`!foobar,*bar`" matches all names ending with `bar`,
+except `foobar`.
+
+## Overview of `Keep` Options {: #keepoverview}
+
+The various [`-keep`](usage.md#keep) 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:
+
+| Keep | From being removed or renamed | From being renamed
+|-----------------------------------------------------|------------------------------------------------------|--------------------------------------------------------------
+| Classes and class members | [`-keep`](#keep) | [`-keepnames`](#keepnames)
+| Class members only | [`-keepclassmembers`](#keepclassmembers) | [`-keepclassmembernames`](#keepclassmembernames)
+| Classes and class members, if class members present | [`-keepclasseswithmembers`](#keepclasseswithmembers) | [`-keepclasseswithmembernames`](#keepclasseswithmembernames)
+
+Each of these [`-keep`](usage.md#keep) options is of course followed by a
+[specification](#classspecification) of the classes and class members
+(fields and methods) to which it should be applied.
+
+If you're not sure which option you need, you should probably simply use
+`-keep`. It will make sure the specified classes and class members are
+not removed in the shrinking step, and not renamed in the obfuscation
+step.
+
+!!! warning ""
+ - If you specify a class, without class members, ProGuard only
+ preserves the class and its parameterless constructor as
+ entry points. It may still remove, optimize, or obfuscate its other
+ class members.
+ - If you specify a method, ProGuard only preserves the method as an
+ entry point. Its code may still be optimized and adapted.
+
+## Keep Option Modifiers {: #keepoptionmodifiers}
+
+`includedescriptorclasses`
+: Specifies that any classes in the type descriptors of the methods and
+ fields that the [-keep](#keep) option keeps should be kept as well. This is
+ typically useful when [keeping native method names](examples.md#native), to
+ make sure that the parameter types of native methods aren't renamed either.
+ Their signatures then remain completely unchanged and compatible with the
+ native libraries.
+
+`includecode`
+: Specifies that code attributes of the methods that the [-keep](#keep)
+ option keeps should be kept as well, i.e. may not be optimized or obfuscated.
+ This is typically useful for already optimized or obfuscated classes,
+ to make sure that their code is not modified during optimization.
+
+`allowshrinking`
+: Specifies that the entry points specified in the [-keep](#keep) 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.
+
+`allowoptimization`
+: Specifies that the entry points specified in the [-keep](#keep) 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.
+
+`allowobfuscation`
+: Specifies that the entry points specified in the [-keep](#keep) 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.
+
+## Class Specifications {: #classspecification}
+
+A class specification is a template of classes and class members (fields
+and methods). It is used in the various [`-keep`](usage.md#keep) options and in the
+`-assumenosideeffects` option. The corresponding option is only applied
+to classes and class members that match the template.
+
+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 [examples](examples.md), but this is an attempt at a complete
+formal definition:
+
+ [@annotationtype] [[!]public|final|abstract|@ ...] [!]interface|class|enum classname
+ [extends|implements [@annotationtype] classname]
+ [{
+ [@annotationtype]
+ [[!]public|private|protected|static|volatile|transient ...]
+ | (fieldtype fieldname [= values]);
+
+ [@annotationtype]
+ [[!]public|private|protected|static|synchronized|native|abstract|strictfp ...]
+ | (argumenttype,...) | classname(argumenttype,...) | (returntype methodname(argumenttype,...) [return values]);
+ }]
+
+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.
+
+- The `class` keyword refers to any interface or class. The
+ `interface` keyword restricts matches to interface classes. The
+ `enum` keyword restricts matches to enumeration classes. Preceding
+ the `interface` or `enum` keywords by a `!` restricts matches to
+ classes that are not interfaces or enumerations, respectively.
+
+- Every *classname* must be fully qualified, e.g. `java.lang.String`.
+ Inner classes are separated by a dollar sign "`$`", e.g.
+ `java.lang.Thread$State`. Class names may be specified as regular
+ expressions containing the following wildcards:
+
+ | Wildcard | Meaning
+ |-------|-----------
+ | `?` | matches any single character in a class name, but not the package separator. For example, "`com.example.Test?`" matches "`com.example.Test1`" and "`com.example.Test2`", but not "`com.example.Test12`".
+ | `*` | matches any part of a class name not containing the package separator. For example, "`com.example.*Test*`" matches "`com.example.Test`" and "`com.example.YourTestApplication`", but not "`com.example.mysubpackage.MyTest`". Or, more generally, "`com.example.*`" matches all classes in "`com.example`", but not in its subpackages.
+ | `**` | matches any part of a class name, possibly containing any number of package separators. For example, "`**.Test`" matches all `Test` classes in all packages except the root package. Or, "`com.example.**`" matches all classes in "`com.example`" and in its subpackages.
+ | `` | matches the _n_'th matched wildcard in the same option. For example, "`com.example.*Foo<1>`" matches "`com.example.BarFooBar`".
+
+ For additional flexibility, class names can actually be
+ comma-separated lists of class names, with optional `!` negators,
+ just like file name filters. This notation doesn't look very
+ Java-like, so it should be used with moderation.
+ For convenience and for backward compatibility, the class name `*`
+ refers to any class, irrespective of its package, when used on its own (e.g. `-keep class *`).
+
+- The `extends` and `implements` specifications are typically used to
+ restrict classes with wildcards. They are currently equivalent,
+ specifying that only classes extending or implementing the given
+ class (directly or indirectly) qualify. The given class itself is not
+ included in this set. If required, it should be specified in a separate
+ option.
+
+- The `@` specifications can be used to restrict classes and class
+ members to the ones that are annotated with the specified
+ annotation types. An *annotationtype* is specified just like a
+ *classname*.
+
+- 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 `javadoc` and `javap`). The specifications can also
+ contain the following catch-all wildcards:
+
+ | Wildcard | Meaning
+ |-------------|------------------------------
+ | `` | matches any constructor.
+ | `` | matches any field.
+ | `` | matches any method.
+ | `*` | matches any field or method.
+
+ Note that the above wildcards don't have return types. Only the
+ `` wildcard has an argument list.
+
+ Fields and methods may also be specified using regular expressions.
+ Names can contain the following wildcards:
+
+ | Wildcard | Meaning
+ |-------|-----------------------------------------------------------------
+ | `?` | matches any single character in a method name.
+ | `*` | matches any part of a method name.
+ | `` | matches the _n_'th matched wildcard in the same option.
+
+ Types in descriptors can contain the following wildcards:
+
+ | Wildcard | Meaning
+ |-------|-----------------------------------------------------------------------------------------
+ | `%` | matches any primitive type ("`boolean`", "`int`", etc) or "`void`" type.
+ | `?` | matches any single character in a class name.
+ | `*` | matches any part of a class name not containing the package separator.
+ | `**` | matches any part of a class name, possibly containing any number of package separators.
+ | `***` | matches any type (primitive or non-primitive, array or non-array).
+ | `...` | matches any number of arguments of any type.
+ | `` | matches the _n_'th matched wildcard in the same option.
+
+ Note that the `?`, `*`, and `**` wildcards will never match
+ primitive types. Furthermore, only the `***` wildcards will match
+ array types of any dimension. For example, "`** get*()`" matches
+ "`java.lang.Object getObject()`", but not "`float getFloat()`",
+ nor "`java.lang.Object[] getObjects()`".
+
+- 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.
+
+- 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 `!` specifies that the
+ corresponding access flag should be unset.
+
+ Combining multiple flags is allowed (e.g. `public static`). It means
+ that both access flags have to be set (e.g. `public` *and*
+ `static`), except when they are conflicting, in which case at least
+ one of them has to be set (e.g. at least `public` *or* `protected`).
+
+ ProGuard supports the additional modifiers `synthetic`, `bridge`,
+ and `varargs`, which may be set by compilers.
+
+- With the option [`-assumevalues`](#assumevalues), fields and methods
+ with primitive return types can have *values* or *ranges of values*.
+ The assignment keyword is `=` or `return`, interchangeably. For
+ example, "`boolean flag = true;`" or "`int method() return 5;`".
+ Ranges of values are separated by `..`, for example,
+ "`int f = 100..200;`". A range includes its begin value and
+ end value.
diff --git a/proguard/docs/manual/feedback.md b/proguard/docs/manual/feedback.md
new file mode 100644
index 0000000..270a80c
--- /dev/null
+++ b/proguard/docs/manual/feedback.md
@@ -0,0 +1,40 @@
+By now, we've invested an enormous amount of time in **ProGuard**. You can
+help by providing feedback! If you have problems, bugs, bug fixes, ideas,
+encouragements, etc., please let us know.
+
+At [Guardsquare](http://www.guardsquare.com/), we develop ProGuard and its
+professional siblings DexGuard (for Android) and iXGuard (for iOS). If you
+find ProGuard useful and you are interested in more features or professional
+support, this is the place to go.
+
+ProGuard is currently hosted on GitHub:
+
+- You can report issues on our
+ [issue tracker](https://github.com/Guardsquare/proguard/issues).
+
+- You can clone the
+ [source code](https://github.com/Guardsquare/proguard) yourself and create
+ [pull requests](https://github.com/Guardsquare/proguard/pulls).
+
+!!! tip
+ The [***Guardsquare Community***](https://community.guardsquare.com/) is the place to be for all your ProGuard-related questions and feedback.
+
+You may also find answers on
+[Stack Overflow](http://stackoverflow.com/questions/tagged/proguard).
+
+ProGuard used to be hosted on Sourceforge:
+
+- You can still read answers in the [help
+ forum](https://sourceforge.net/projects/proguard/forums/forum/182456).
+
+- You can still find discussions in the [open discussion
+ forum](https://sourceforge.net/projects/proguard/forums/forum/182455).
+
+- We still have reports on the
+ [bug tracking page](http://sourceforge.net/p/proguard/bugs/).
+
+- We still have new ideas on the the
+ [feature request page](http://sourceforge.net/p/proguard/feature-requests/).
+
+- You can still find all earlier versions in the
+ [download section](https://sourceforge.net/projects/proguard/files/).
diff --git a/proguard/docs/manual/home.md b/proguard/docs/manual/home.md
new file mode 100644
index 0000000..033df10
--- /dev/null
+++ b/proguard/docs/manual/home.md
@@ -0,0 +1,126 @@
+Welcome to the manual for **ProGuard** version 7.3 ([what's new?](releasenotes.md)).
+
+ProGuard is an open-sourced Java class file shrinker, optimizer, obfuscator, and
+preverifier. As a result, ProGuard processed applications and libraries are smaller and faster.
+
+- The ***shrinking step*** detects and removes unused classes, fields, methods, and
+attributes.
+- The ***optimizer step*** optimizes bytecode and removes unused instructions.
+- The ***name obfuscation step*** renames the remaining classes, fields, and methods using short meaningless names.
+- The final ***preverification step*** adds preverification information to the classes, which is required for Java Micro Edition and for Java 6 and higher.
+
+The default Android shrinker, R8, is compatible with ProGuard [configuration](configuration/usage.md).
+
+If you are getting started with ProGuard, please follow the [Quick Start](building.md) guide in order to arrive at a basic setup for your application or library as quickly as possible.
+
+Experienced users can directly consult the [Configuration section](configuration/usage.md) where all features are described.
+
+If during the process you run into any issues, please make sure to check the [Troubleshooting section](troubleshooting/troubleshooting.md).
+
+## How it works
+
+
+
+ReTrace can read an obfuscated stack trace and restore it to what it
+would look like without obfuscation. The restoration is based on the
+mapping file that an obfuscator (like ProGuard, DexGuard or R8) can write out while obfuscating. The mapping
+file links the original class names and class member names to their
+obfuscated names.
+
+## Usage {: #usage }
+
+You can find the ReTrace jar in the `lib` directory of the ProGuard
+distribution. To run ReTrace, just type:
+
+`java -jar retrace.jar `\[*options...*\] *mapping\_file*
+\[*stacktrace\_file*\]
+
+Alternatively, the `bin` directory contains some short Linux and Windows
+scripts containing this command. These are the arguments:
+
+*mapping\_file*
+: Specifies the name of the mapping file.
+
+*stacktrace\_file*
+: 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. The
+ stack trace must be encoded with UTF-8 encoding. Blank lines and
+ unrecognized lines are ignored.
+
+The following options are supported:
+
+`-verbose`
+: Specifies to print out more informative stack traces that include not only
+ method names, but also method return types and arguments.
+
+`-regex` *regular\_expression*
+
+: 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. A relatively
+ simple expression like this works for basic stack trace formats:
+
+ (?:.*? at %c\.%m\(%s(?::%l)?\))|(?:(?:.*?[:"] +)?%c(?::.*)?)
+
+ It for instance matches the following lines:
+
+ Exception in thread "main" myapplication.MyException: Some message
+ at com.example.MyClass.myMethod(MyClass.java:123)
+
+ The regular expression is a Java regular expression (cfr. the
+ documentation of `java.util.regex.Pattern`), with a few additional
+ wildcards:
+
+ | Wildcard | Description | Example
+ |----------|--------------------------------------------|-------------------------------------------
+ | `%c` | matches a class name | `com.example.MyClass`
+ | `%C` | matches a class name with slashes | `com/example/MyClass`
+ | `%t` | matches a field type or method return type | `com.example.MyClass[]`
+ | `%f` | matches a field name | `myField`
+ | `%m` | matches a method name | `myMethod`
+ | `%a` | matches a list of method arguments | `boolean,int`
+ | `%s` | matches a source file name | `MyClass.java`
+ | `%l` | matches a line number inside a method | `123`
+
+ 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: `(?:`...`)`
+
+ You can print out the default regular expression by running ReTrace without
+ arguments. It also matches more complex stack traces.
+
+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:
+
+- If all line numbers have been preserved while obfuscating the
+ application, ReTrace will be able to restore the stack
+ trace completely.
+- 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.
+
+Source file names are currently restored based on the names of the
+outer-most classes. If you prefer to keep the obfuscated name, you can
+replace `%s` in the default regular expression by `.*`
+
+Unobfuscated elements and obfuscated elements for which no mapping is
+available will be left unchanged.
+
+
+## Examples {: #examples }
+
+### Restoring a stack trace with line numbers {: #with}
+
+Assume for instance an application has been obfuscated using the
+following extra options:
+
+ -printmapping mapping.txt
+
+ -renamesourcefileattribute MyApplication
+ -keepattributes SourceFile,LineNumberTable
+
+Now assume the processed application throws an exception:
+
+ java.io.IOException: Can't read [dummy.jar] (No such file or directory)
+ at proguard.y.a(MyApplication:188)
+ at proguard.y.a(MyApplication:158)
+ at proguard.y.a(MyApplication:136)
+ at proguard.y.a(MyApplication:66)
+ at proguard.ProGuard.c(MyApplication:218)
+ at proguard.ProGuard.a(MyApplication:82)
+ at proguard.ProGuard.main(MyApplication:538)
+ Caused by: java.io.IOException: No such file or directory
+ at proguard.d.q.a(MyApplication:50)
+ at proguard.y.a(MyApplication:184)
+ ... 6 more
+
+If we have saved the stack trace in a file `stacktrace.txt`, we can use
+the following command to recover the stack trace:
+
+ retrace mapping.txt stacktrace.txt
+
+The output will correspond to the original stack trace:
+
+ java.io.IOException: Can't read [dummy.jar] (No such file or directory)
+ at proguard.InputReader.readInput(InputReader.java:188)
+ at proguard.InputReader.readInput(InputReader.java:158)
+ at proguard.InputReader.readInput(InputReader.java:136)
+ at proguard.InputReader.execute(InputReader.java:66)
+ at proguard.ProGuard.readInput(ProGuard.java:218)
+ at proguard.ProGuard.execute(ProGuard.java:82)
+ at proguard.ProGuard.main(ProGuard.java:538)
+ Caused by: java.io.IOException: No such file or directory
+ at proguard.io.DirectoryPump.pumpDataEntries(DirectoryPump.java:50)
+ at proguard.InputReader.readInput(InputReader.java:184)
+ ... 6 more
+
+### Restoring a stack trace with line numbers (verbose) {: #withverbose}
+
+In the previous example, we could also use the verbose flag:
+
+ java -jar retrace.jar -verbose mapping.txt stacktrace.txt
+
+The output will then look as follows:
+
+ java.io.IOException: Can't read [dummy.jar] (No such file or directory)
+ at proguard.InputReader.void readInput(java.lang.String,proguard.ClassPathEntry,proguard.io.DataEntryReader)(InputReader.java:188)
+ at proguard.InputReader.void readInput(java.lang.String,proguard.ClassPath,int,int,proguard.io.DataEntryReader)(InputReader.java:158)
+ at proguard.InputReader.void readInput(java.lang.String,proguard.ClassPath,proguard.io.DataEntryReader)(InputReader.java:136)
+ at proguard.InputReader.void execute(proguard.classfile.ClassPool,proguard.classfile.ClassPool)(InputReader.java:66)
+ at proguard.ProGuard.void readInput()(ProGuard.java:218)
+ at proguard.ProGuard.void execute()(ProGuard.java:82)
+ at proguard.ProGuard.void main(java.lang.String[])(ProGuard.java:538)
+ Caused by: java.io.IOException: No such file or directory
+ at proguard.io.DirectoryPump.void pumpDataEntries(proguard.io.DataEntryReader)(DirectoryPump.java:50)
+ at proguard.InputReader.void readInput(java.lang.String,proguard.ClassPathEntry,proguard.io.DataEntryReader)(InputReader.java:184)
+ ... 6 more
+
+### Restoring a stack trace without line numbers {: #without}
+
+Assume for instance the application has been obfuscated using
+the following extra options, this time without preserving the line
+number tables:
+
+ -printmapping mapping.txt
+
+A stack trace `stacktrace.txt` will then lack line number information,
+showing "Unknown source" instead:
+
+ java.io.IOException: Can't read [dummy.jar] (No such file or directory)
+ at proguard.y.a(Unknown Source)
+ at proguard.y.a(Unknown Source)
+ at proguard.y.a(Unknown Source)
+ at proguard.y.a(Unknown Source)
+ at proguard.ProGuard.c(Unknown Source)
+ at proguard.ProGuard.a(Unknown Source)
+ at proguard.ProGuard.main(Unknown Source)
+ Caused by: java.io.IOException: No such file or directory
+ at proguard.d.q.a(Unknown Source)
+ ... 7 more
+
+We can still use the same command to recover the stack trace:
+
+ java -jar retrace.jar mapping.txt stacktrace.txt
+
+The output will now list all alternative original method names for each
+ambiguous obfuscated method name:
+
+ java.io.IOException: Can't read [dummy.jar] (No such file or directory)
+ at proguard.InputReader.execute(InputReader.java)
+ readInput(InputReader.java)
+ at proguard.InputReader.execute(InputReader.java)
+ readInput(InputReader.java)
+ at proguard.InputReader.execute(InputReader.java)
+ readInput(InputReader.java)
+ at proguard.InputReader.execute(InputReader.java)
+ readInput(InputReader.java)
+ at proguard.ProGuard.readInput(ProGuard.java)
+ at proguard.ProGuard.execute(ProGuard.java)
+ optimize(ProGuard.java)
+ createPrintStream(ProGuard.java)
+ closePrintStream(ProGuard.java)
+ fileName(ProGuard.java)
+ at proguard.ProGuard.main(ProGuard.java)
+ Caused by: java.io.IOException: No such file or directory
+ at proguard.io.DirectoryPump.pumpDataEntries(DirectoryPump.java)
+ readFiles(DirectoryPump.java)
+
+For instance, ReTrace can't tell if the method `a` corresponds to
+`execute` or to `readInput`, so it lists both. You need to figure it out
+based on your knowledge of the application. Having line numbers and
+unambiguous names clearly is a lot easier, so you should consider
+[preserving the line numbers](../configuration/examples.md#stacktrace) when you
+obfuscate your application.
+
+
+## Specifications {: #specifications }
+
+A mapping file contains the original names and the obfuscated names of
+classes, fields, and methods. ProGuard can write out such a file while
+obfuscating an application or a library, with the option
+[`-printmapping`](../configuration/usage.md#printmapping). ReTrace requires the mapping file
+to restore obfuscated stack traces to more readable versions. It is a readable
+file with UTF-8 encoding, so you can also look up names in an ordinary text
+viewer. The format is pretty self-explanatory, but we describe its details
+here.
+
+A mapping file contains a sequence of records of the following form:
+
+ classline
+ fieldline *
+ methodline *
+
+A `classline`, with a trailing colon, specifies a class and its obfuscated
+name:
+
+ originalclassname -> obfuscatedclassname:
+
+A `fieldline`, with 4 leading spaces, specifies a field and its obfuscated
+name:
+
+ originalfieldtype originalfieldname -> obfuscatedfieldname
+
+A `methodline`, with 4 leading spaces, specifies a method and its obfuscated
+name:
+
+ [startline:endline:]originalreturntype [originalclassname.]originalmethodname(originalargumenttype,...)[:originalstartline[:originalendline]] -> obfuscatedmethodname
+
+- An asterisk "*" means the line may occur any number of times.
+- Square brackets "\[\]" mean that their contents are optional.
+- Ellipsis dots "..." mean that any number of the preceding items may be specified.
+- The colon ":", the separator ".", and the arrow "->" are literal tokens.
+
+### Example
+
+The following snippet gives an impression of the structure of a mapping file:
+
+ com example.application.ArgumentWordReader -> com.example.a.a:
+ java.lang.String[] arguments -> a
+ int index -> a
+ 36:57:void