Important note: finding old code in and debugging compatibility

[GoodSign2017]

To be able to debug vanilla incompatibilitites, the D_DoomLoop and all that is called by it that relates to the Loop itself, the ticks, game object modifications, mode changes and so on, MUST be preceded by a label, containing original underscored naming of the method in Doom Source Code.

Do not make labeled blocks inside the methods of your-written library classes, completely new functionality, only mark the place where you replaced or can replace something in future in the existing code.

It would have absolutely no impact on performance, the only limitation is local variable visibility. The variables declared inside the labeled block will not be accessible outside directly, however you can, if you need, declare the variable outside of the labeled block.

Example of labeled block:

M_CheckParm: {
  ... your precious new code doing some work of old...
}

Remember the label blocks will retain their name even in case of automated refactoring.

Consider the situation with old code:
I_InitGraphics ();

After translation to Java:
VI.InitGraphics();

After automated refactoring:
view = sceneRenderer.getView();

And if we use the underscored-named labels:

I_InitGraphics: {
  I_InitGraphics ();
}

After an automated refactoring:

I_InitGraphics: {
  view = sceneRenderer.getView();
}

Thus if you rename some method and update it throughout the whole codebase, the named label will still be named the same underscored original method name.

Do it the most verbose way you can - preserving both, or all brackets of all blocks containing and contained in the label and the brackets of the label itself, with one exception:

If there is no more function to do the task was given to the function in original Doom Source Code, the label stull MUST be present, just type a semicolon to end it without actions.

Right way (some obsolete original method):
I_StartFrame:;

Right way (replaced way the part of method work):

M_CheckParm: {
   if (cVarManager.bool(CommandVariable.DEBUGFILE)) {
     ...new code...
   }
}

Right way (look into future, prevent name changes to break search for old code):

if (advancedemo) {
   D_DoAdvanceDemo: {
      DoAdvanceDemo();
   }
}

Right way:

D_ProcessEvents: {
   ProcessEvents();
}

Right way is unambiguous, readable and easily distinguishable. The syntax is short (but verbose) and is easy to understand. Remember, Java is a verbose language and that makes it strong.
In contrary to it:

Wrong way - easy to miss the labeled block:

if (advancedemo) D_DoAdvanceDemo: {
   DoAdvanceDemo();
}

Wrong way - ambiguous:
D_ProcessEvents: ProcessEvents();

Wrong way - unambiguous, but easy to miss end of labeled block:

M_CheckParm:
   if (cVarManager.bool(CommandVariable.DEBUGFILE)) {
     ...new code...
   }

Wrong way - original block inheritance messed up:

if (cVarManager.bool(CommandVariable.DEBUGFILE)) M_CheckParm: {
  ...new code...
}

For the methods declarations themselves, it is better to use @annotations, like:

@D_Main.C(D_DoomLoop)
public void DoomLoop() throws IOException {
   ...
}