First, the 'cd' command can't be executed by Runtime.exec() in the first place (see How to use "cd" command using Java runtime?). You should be able to just set the working directory for the process when you call exec (see below).

Second, running 'cmd.exe /c' to execute your process isn't what you want here. You won't be able to get the results of your process running, because that is returned to the command window -- which eats the error and then closes without passing the error along to you.

Your exec command should look more like this:

CopyProcess p = Runtime.getRuntime().exec(
    command, null, "C:\Users\Eric\Documents\COSC\ecj");

Where 'command' looks like this:

CopyString command = "java ec.Evolve -file ec\app\tutorial5\tutorial5.params"

Edit: For reading error messages, try this:

CopyString error = "";
try (InputStream is = proc.getErrorStream()) {
    error = IOUtils.toString(is, "UTF-8");
}
int exit = proc.waitFor();
if (exit != 0) {
    System.out.println(error);
} else {
    System.out.println("Success!");
}

I ran your program, linked to a checkfileindirectory.sh that looks like this:

#!/bin/bash

echo $1 > param1.txt
echo $2 > param2.txt

As a test, I changed "<file_to_find>" to "<file_to_find>;touch MikeWasHere.txt"

String[] cmdArr = { "bash", "checkfileindirectory.sh", "<directory_to_search>", "<file_to_find>;touch MikeWasHere.txt" };

And I get this output:

➜  /tmp javac FindFileInDir.java
➜  /tmp java FindFileInDir 
➜  /tmp cat param1.txt 
<directory_to_search>
➜  /tmp cat param2.txt 
<file_to_find>;touch MikeWasHere.txt
➜  /tmp ls MikeWasHere.txt
ls: cannot access 'MikeWasHere.txt': No such file or directory

So it looks like java's rt.exec() is injection-safe.

OWASP's page on command injection has a paragraph about java's exec (emphasis mine):

C’s system function passes its arguments to the shell (/bin/sh) to be parsed, whereas Runtime.exec tries to split the string into an array of words, then executes the first word in the array with the rest of the words as parameters. Runtime.exec does NOT try to invoke the shell at any point. The key difference is that much of the functionality provided by the shell that could be used for mischief (chaining commands using “&”, “&&”, “|”, “||”, etc, redirecting input and output) would simply end up as a parameter being passed to the first command

That seems consistent with our experiment that java's rt.exec() is injection-safe.