This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Guardrail #4: Avoiding Java steps in activities

 This presentation is part of the Designing and Building for Performance Self-Study Course.



Java code warrants a warning because the code itself may be poor performing, difficult to maintain, or simply used for debugging, as it is in this case.  This warning pertains to guardrail #4 "Limit Hand-Coded Java". 

Often times, programmers who are very familiar with Java tend to resort to Java steps instead of using the preferred, and easier to maintain, PRPC equivalent of out-of-the-box methods that do the same thing.

Verbose logging may seem innocuous, but it can have a noticeable impact on performance for a few reasons:

  • Using println() in this case synchronously attempts to write to sysout, which can create a bottleneck.
  • Using the PRPC Log-Message method is a better approach that uses the Log4J facility instead, which is asynchronous and more efficient.
  • Also, note how the string being written is made up of a concatenated set of sub-strings and tokens.  This process can also throw off garbage in the JVM as the string concatenation can be inefficient from a memory management perspective.  The token generated from the call to getXML() can be quite large depending on the size of that object and can also be memory intensive.
  • Instead of reverting to Java, a better practice is to use the PRPC OOTB method Log-Message, which accomplishes the same goal without resorting to more complex Java coding syntax.
  • As a debugging aid, unconditional logging can be useful, but is not production-worthy code.
Did you find this content helpful?

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.