Examples
The examples below show only the command line parameters for Crema. These parameters must be inserted in the appropriate command to run Crema.
The first few times you may want to use the -v parameter to see what is going on.
For most applets (like all of the JDK demos except SortDemo and ImageMap) the following parameter suffices:
*.class
If you want a more aggressive obfuscation and do not mind a slight increase in the size of your .class files, add the -max parameter:
-max *.class
In both cases you will get one or more .crema files that you should rename to .class after you move them to your web site. If you prefer you can do that with one command:
-e .class -d /my/web/directory *.class
If an applet (such as SortDemo or ImageMap) loads classes by name, the names of those classes should not be obfuscated. Crema will warn you about this situation, but you have to manually indicate which classes are involved. For SortDemo these classes are BubbleSortAlgorithm, BidirBubbleSortAlgorithm and QSortAlgorithm:
-xc BubbleSortAlgorithm -xc BidirBubbleSortAlgorithm -xc QSortAlgorithm *.class
To avoid exceedingly long command lines and the associated typos, the use of a parameter file is recommended in these cases.
Note: If your main applet class (the one derived from java.applet.Applet) is renamed by Crema, you have forgotten to declare it public. Fix that, then recompile and reobfuscate.
Applications are usually loaded from the local file system and not verified by default. This enables a more aggressive obfuscation strategy which you can request with the following parameters:
-ill -max *.class
Unless you can be certain that your library package will never be used in applets, you should obfuscate it just like an applet. In particular, you should not use the -ill parameter.
You can get even better protection by requiring of your licensees that they obfuscate their entire project, including your package, with the -pub parameter as described below. Such a policy ensures that your package can only be used by your licensees (not by their customers). If you adopt such a policy you can distribute your package either obfuscated or unobfuscated to your licensees.
If your applet, application or library package includes (sub)packages you can list the .classes explicitly, or you can take advantage of recursive wildcard expansion:
-r *.class
By default, Crema excludes public classes and members. That is convenient, as it will automatically prevent obfuscation of the main class of applications and applets, the main() method of applications, and the API of library classes. But in complex projects with subpackages there are often more public items than you want to expose. In those cases you can use the -pub parameter to tell Crema to obfuscate public items as well. At the same time you must manually (with the -xc and -xm parameters) specify which classes and members should not be obfuscated:
-pub -xc MyApp -xm MyApp.main -r *.class
In such cases it is best to create a parameter file.
To get the smallest possible .class files, use as many of the following parameters as your project allows:
-nomsg -nobomb -pub -ill
Note that -ill is not suitable for applets, and that the use of -pub usually requires that you explicitly exclude classes and members using -xc and -xm.
Try to avoid the following parameters:
-msg -lnt -max
Finally, including (sub)packages in the obfuscation process (combined with the -pub parameter, as explained in the previous section) helps reduce .class file size.
<< | Copyright © 1996 Hanpeter van Vliet | >> |