Show TOC Start of Content Area

Background documentation Web Dynpro Class File Minimizer  Locate the document in its SAP Library structure

Web Dynpro for Java automatically generates a lot of Java code to simplify access to otherwise generic structures (like contexts or models) and to enable typesafe access to data or Web Dynpro structures. On the positive side, this provides a higher level of safety at compile time and reduces the number of errors caused by typing mistakes. On the negative side, it often leads to a lot of classes that are used only partially (not every attribute in a context node is accessed via application code). However, as all classes are internally referenced by the application, they must all be loaded into the Java Virtual Machine (JVM) at runtime. On some JVMs, this might lead to an unnecessarily high memory consumption, especially when the memory for classes is restricted (for example, Perm Space in SUN JVMs).

To leverage this problem, the build of Web Dynpro applications has been enhanced with the so called Class File Minimizer, which enables the automatic analysis and reduction of generated code.

Caution

The Class File Minimizer is only available for the Development Component Build (DC Build), as it requires information about public parts that is only available during the DC build. Therefore, the Class File Minimizer can only be used with Web Dynpro projects that are development component projects.

Concept

First of all, it is important to know that the Class File Minimizer always analyzes a complete project, not just parts of it. All class files that are part of a Web Dynpro project are analyzed to detect and remove unused methods or fields.

Conceptually, the class path is separated into two parts: Firstly, a project part that contains the classes that are to be analyzed and reduced; secondly, an external part that contains all the classes referenced by the project classes (JDK, imported libs, public parts of used DCs, and so on).

To keep the reduced code functional, the following code is always assumed to be called:

·        Code in the external class path

·        Any implementation of external interfaces (as external code might call the interface)

·        Methods that override methods of external base classes (same as above)

·        Classes that are part of a DC Public Part

·        Constructors/methods that Web Dynpro calls via reflection (mainly constructors of controllers)

The Class File Minimizer iterates over all project classes, determines the entry points for each class from the above definition, and recursively visits any reached method or field (avoiding cycles, of course). The information about all reached classes, fields, and methods is collected.

If the iteration finally stops, there will - hopefully - be a set of methods and fields that is not reachable in the sense of the above definition and can thus be safely removed.

Using the Class File Minimizer

For usage of the Class File Minimizer, proceed as following:

       1.      In the Web Dynpro Explorer, expand the Web Dynpro DC.

       2.      From the context menu, choose Properties.

       3.      Choose the list item Web Dynpro Generation on the left.

       4.      From the dropdown list minimize byte code, select the entry auto.

Currently, only the two settings no and auto are available, with nomeaning that the Class File Minimizer is not to be run, and autothat the Class File Minimizer automatically determines in which mode to run.

If problems occur during the build of dependant DCs or at runtime, the Class File Minimizer can be disabled for a project at any time. Note that this requires a change in the definition of the development component (.dcdef file) and as such must be part of an open DTR Activity.

Restrictions

As explained in the concept section, the Class File Minimizer has some ”built-in“ knowledge about what code is always reachable by the framework (via reflection). If these restrictions are not met by a specific project (as it uses a framework with different reflection strategies or as the project uses reflection itself), the Class File Minimizer obviously cannot correctly determine the set of reachable code and the mistakenly reduced classes will most likely fail at runtime (typically with a NoSuchFieldError or NoSuchMethodError during class loading), maybe even at compile time.

End of Content Area