Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
horst_keller
Product and Topic Expert
Product and Topic Expert


The ABAP compiler was improved in the following ways. The improvements are backward compatible. You don't have to do anything with your programs but can simply benefit from the improvements.

Multi Pass Compiler

You might have not noticed it, but the ABAP compiler up to Release 7.01 has some flaws. Before the dawn of ABAP Objects it operated with one pass processing only. With the introduction of ABAP Objects, a restricted two pass processing was introduced, Nevertheless, when developers started to create complicated relations between classes and interfaces it was found that some correct programs do not compile. In fact, this can be shown by a rather simple example of two public classes with cross references:

CLASS cl_test_1 DEFINITION PUBLIC.
PUBLIC SECTION.
TYPES type11
TYPE cl_test_2=>type22.
TYPES type12
TYPE i.
ENDCLASS.


CLASS cl_test_2 DEFINITION PUBLIC.
PUBLIC SECTION.
TYPES type21
TYPE cl_test_1=>type12.
TYPES type22
TYPE i.
ENDCLASS.


In Release 7.01 there are syntax errors in both classes (even after activating them)!

This is solved in Release 7.02. After the introduction of a robust multi pass processing for global classes, global interfaces and type pools, the syntax errors do not occurr any more.

Load on Demand

Up to Release 7.01, the ABAP compiler could only load external definitions (e.g. TYPE-POOLs, classes and interfaces) at certain times. The definitions were loaded as soon as possible to minimize compilation errors. If definitions refer to other definitions, further definitions had to be loaded in the same moment. As a consequence, a significant amount of definition were loaded that were not needed. Further consequences were a costly dependency administration, a high recompilation frequency (e.g. changes of dictionary types affected many ABAP loads that didn't really use the type), and code instability (syntax errors in definitions "far away" affected many programs that didn't really need these definitions). Workarounds that avoided such dependencies were dynamic techniques and usage of unsafe types, e.g. parameters typed REF TO OBJECT. Those techniques bypassed static checks and negatively affected code robustness and maintainability.

This issues are solved in Release 7.02, because external definitions are only loaded when actually required (i.e. on demand). Example:

DATA: obj TYPE REF TO iface.  "Definition of iface not loaded
...
var = iface=>const.           "Definition of iface loaded
...


As an interesting consequence for ABAP developers there is no need for some explicit usage declarations any more and the following statements became obsolete:

  • TYPE-POOLS

  • CLASS ... DEFINITION LOAD

  • INTERFACE ... LOAD


These statements are ignored by the ABAP Compiler as of Release 7.02 and can be deleted (no need of TYPE-POOLS statement any more, see http://help.sap.com/abapdocu_702/en/index.htm?url=abaptype-pools.htm).

Performancce

Even if you never stumbled over syntax errors as shown above or you don't care about load on demand, you will benefit from the new ABAP compiler which is more robust, economic and - last but not least - fast: Compilation times are reduced by 60%!

13 Comments