O comportamento de funções nessa categoria varia de acordo com o sistema operacional e, às vezes, até mesmo com a versão do sistema operacional. Diferenças de implementação podem incluir:

- Pequenas diferenças em como os parâmetros são interpretados, provocando resultados inconsistentes.

- Algumas implementações da função contêm riscos de segurança significativos.

- A função não pode ser definida em todas as plataformas.

Diferentes sistemas operacionais usam diferentes caracteres como separadores de arquivo. Por exemplo, os sistemas Microsoft Windows usam "\", enquanto os sistemas UNIX usam "/". Quando os aplicativos precisam ser executados em plataformas diferentes, o uso de separadores de arquivo inseridos em código fixo pode resultar na execução incorreta da lógica do aplicativo e, potencialmente, em uma negação de serviço.

Exemplo 1: O seguinte código usa um separador de arquivo inserido em código fixo para abrir um arquivo:

...
File file = new File(directoryName + "\\" + fileName);
...

Ao comparar dados que pode ser dependentes de localidade, uma localidade apropriada deve ser especificada.

Exemplo 1: O exemplo a seguir tenta realizar uma validação para determinar se a entrada do usuário inclui uma tag <script>.

  ...
  public String tagProcessor(String tag){
    if (tag.toUpperCase().equals("SCRIPT")){
      return null;
    }
    //does not contain SCRIPT tag, keep processing input
    ...
  }
  ...

O problema com o Example 1 é que java.lang.String.toUpperCase(), quando usado sem uma localidade, aplica as regras da localidade padrão. O uso da localidade turca "title".toUpperCase() retorna "T\u0130TLE", onde "\u0130" é o caractere "LATIN CAPITAL LETTER I WITH DOT ABOVE". Isso pode provocar resultados inesperados, como no Example 1, em que isso impedirá que a palavra "script" seja capturada por essa validação, podendo causar uma vulnerabilidade de Cross-Site Scripting.

Os sistemas SAP são projetados para serem independentes de plataforma. Open SQL, o dialeto SQL portátil do SAP, torna os aplicativos independentes do driver JDBC de um fornecedor de banco de dados específico. A utilização do Open SQL abstrai os meandros do banco de dados subjacente e fornece uma interface comum para programas de aplicativo para todas as operações de banco de dados. No entanto, o SQL nativo é específico do banco de dados subjacente e, portanto, o uso dele em outras plataformas pode provocar a execução incorreta da lógica do aplicativo e, potencialmente, uma negação de serviço.
Exemplo 1: O seguinte código usa SQL nativo:

...
import java.sql.PreparedStatement;
import com.sap.sql.NativeSQLAccess;

String mssOnlyStmt = "...";
// variant 1
  PreparedStatement ps =
  NativeSQLAccess.prepareNativeStatement(
    conn, mssOnlyStmt);
  . . .
// variant 2
  Statement stmt =
  NativeSQLAccess.createNativeStatement(conn);
  int result = stmt.execute(mssOnlyStmt);
  . . .
// variant 3
  CallableStatement cs =
  NativeSQLAccess.prepareNativeCall(
  conn, mssOnlyStmt);
  . . .