Entry Points are primarily the parts of your software that you expect to be accessed from outside your software, which generally must not be removed or renamed if they are to operate correctly. You may additionally want to designate classes and members that are accessed via reflection as entry points, as PreEmptive Protection™ DashO™ may not otherwise be able to detect their usage. See Renaming or Removal for details.
Note: In Android Mode, DashO expects renaming and removal to be handled by R8; in this case, Entry Points are ignored.
Some examples of entry points that you may want to configure include:
- Classes or members that are expected to be a part of a public API.
-
public static void main(String[])methods that you want to be executable. - A method that is accessed via reflection.
- An Android activity referred to in an Android manifest (when Post-processing an APK)
Default Behavior
If there are no Entry Points defined in your DashO configuration, then DashO will attempt to detect Entry Points by analyzing the manifests of all input jars (looking for, e.g., Main-Class headers), if any are present. DashO will also look for public static void main(String[]) methods. If DashO fails to find any Entry Points in this manner, then it will treat all inputs as Library Entry Points, excluding all public and protected members of public classes from renaming and removal.
Methods and Fields
You can specify methods and classes that you would like to be entry points on the Entry Points - Methods and Fields page of the DashO GUI. These methods and fields will be excluded from both removal and renaming by default, and DashO will analyze the methods specified as entry points to determine which classes and members are unused.
If you like, you can allow classes, methods, and/or fields on the Entry Points - Methods and Fields page to be renamed. Generally, entry points should not be renamed because they are presumably accessed from outside the application. However, in some cases they can be safely renamed. If a class is referenced by a Main-Class attribute in a JAR manifest, for instance, DashO can update the manifest to use the updated name.
Libraries
You can specify a directory, JAR file, WAR file, ZIP file, or APK file as a Library Entry Point on the Inputs page of the DashO GUI. As the name suggests, Library Entry Points are primarily used when you would like to distribute a library with a public API, or you otherwise require other software to be able to interoperate extensively with the library.
By default, all public classes and their public members in a Library Entry Point are effectively entry points, and are excluded from removal and renaming. You can configure this to include protected members as well.
Library Entry Points are automatically considered inputs to DashO and are combined with the input list to determine the classes to be processed - you do not need to include them on the Input - Jars and Classes as well.
Special Classes
A Special Class entry point allows you to specify special rules for a class that go beyond simple method/field entry points. Many of the types of special classes are designed for classes that extend one of a set of classes or implement one of a set of interfaces, typically ones defined by frameworks such as Spring or Android. The names of these classes may be specified as an exact match, a pattern, or a regular expression.
| Type | Functionality | Project File Element |
|---|---|---|
| Android |
Used for classes that extend
|
<android> |
| Applets | Used for classes that extend java.applet.Applet. The classes themselves may be renamed. |
<applet> |
| Class all fields/methods | Marks all fields and methods in the matched classes as entry points. The classes and their members will not be renamed. | <unconditional> |
| Class public fields/methods | Marks all public fields and methods in the matched classes as entry points. The classes and their members will not be removed. | <publics> |
| Enterprise JavaBeans (EJBs) | Used for classes that extend any of the interfaces in the javax.ejb package, including the bean's home and key classes. |
<ejb> |
| iAppli | Used for classes that extend the com.nttdocomo.ui.IApplication class used in NTT DoCoMo's iAppli framework. The classes themselves may be renamed. |
<iappli> |
| Midlet | Used for classes that extend javax.microedition.midlet.Midlet directly or indirectly. The classes themselves may be renamed. |
<midlet> |
| Servlets | Used for classes that extend javax.servlet.Servlet. The classes themselves may be renamed. |
<servlet> |
| SpringBean | Used for Spring Beans. See below for more details. | <springbean> |
Spring Beans
SpringBean entry points are used to identify classes as Spring Beans (referenced in your Spring XML configuration files). By default, property methods of SpringBean classes (i.e., those following getFoo(), setFoo(), isBar() conventions) are excluded from renaming and removal. You can designate Additional Entry Points as well, such as methods referred to by init-method and destroy-method attributes in your Spring XML configuration files.
You can control which of these members can be renamed with the following settings:
-
Rename Property Methods - If enabled, then property methods can be renamed in a way that doesn't break their property conventions (e.g.,
getFoo()might be renamed togetA()). - Rename Entry Points - If enabled, specified Additional Entry Points can be renamed.
- Rename Other Members - If enabled, non-property members that haven't been specified as Additional Entry Points may be renamed.
See the <springbean> and Spring Framework sections for additional details.