Stepping through OT/J code

The byte code into which OT/J programs are translated has some significant differences to the original source code. In order to hide some generated code and to provide convenient stepping even through declarative method bindings, the debug view has been enhanced for OT/J.

Filtering infrastructure code

By default the debugger is configured to filter certain packages in order to hide the Object Teams Runtime Environment (OTRE) and its libraries. This means that the debugger will not show stack frames corresponding to the OTRE while stepping through code. This filtering can be disabled on the preference page at Object Teams — Debug

Callin bindings

In order to realize the runtime dispatch for callin bindings, additional dispatch code is generated and woven into the byte code of bound base classes. Most of this dispatch code is hidden by the debugger, but an abstract view of it is presented in order to support different paths of stepping into/through/over callin bindings.

Typical stepping paths will be explained using the example OTSample-Flightbonus which can be installed using the wizard at

After the example has been installed and configured for running with the team GUIConnector activated (see the example's documentation), assume a new passenger has been registered and subscribed for the bonus system. Also assume a line breakpoint has been set somewhere in method Segment#book(). When the lastly added passenger books a flight, this line breakpoint is triggered.

From here on stepping proceeds as follows:
  • Step (F6) out of method book() until the debugger jumps to role class Item in file FlightBonus.java:
Hitting a callin binding:
At this point the debug view signals that some dispatch is pending for method book. The editor shows the corresponding callin binding that causes this dispatch.
You now have two options:
  • If at this point F7 is pressed the debugger skips over all dispatching and proceeds in the base program.
  • By pressing F5 you enter the callin binding:
Entering a callin binding:
While still seeing the callin binding in the editor the debug view displays a new faked stack frame labeled with the callin binding: [Item.earnCredit<-book].
After pressing once more F6 (this should actually not be needed, we hope to fix this in a future release) you again have a choice:
  • F5 takes you into the generated lifting method (see below).
  • F6 performs lifting without any change in debug view or editor.

Lifting:
The above screenshot shows the debugger while lifting is being performed. The Debug view signals this by the faked stack frame labeled {{Lift to Item}}. Since no real source code exists for the lifting method the editor highlights the playedBy declaration from the class header. This declaration tells you that the current lifting operation will translate a Segment into an Item. You'll normally want to just leave the lifting method:
  1. F7 takes you out off the lifting method and an additional F5 takes you back to the callin binding.
  2. Once more pressing F5 finally steps into the bound base method. If a guard predicate were present, the guard would be entered here, before finally proceeding to the role method. Of course, entering a guard predicate can be skipped by pressing F6 at this point.
Entering the role method:

Stack frame coloring

In the above screenshots you see some stack frames printed in colors. While the exact colors to use can be configured in the preference page shown above, the meaning of colors is as follows:
light purple
Dispatch code with no direct correspondence in the source code.
green
Callin binding declarations and base-calls