Well, the problem is stuffing a variable into the statement. The origin of the variable is important: when it was read from a config file, or from a list of known columns, it won't be a problem. However, all to often these variables can be traced back to input parameters that arrived "somewhere from the web" (or other untrusted source). In this case, a malicious user might alter the input parameters and put parts of SQL commands into them which, when combined with the rest of the statement, will change its meaning. I'm no expert on SQL injection so I won't provide an example for this particular case, but it should be easily searchable.
Sometimes the SQL injection vulnerability is (wrongly) understood as just stuffing the parameters into the SQL string. Actually, putting anything from untrusted source into an SQL text constitutes SQL injection vulnerability.
There are also more arcane forms of SQL injection too. One is caused by implicit conversions (ie. from date to String), where an attacker who would be able to alter the session format string might use that to execute malicious code. It is also good to remember that SQL injection vulnerability might be present in stored procedures too. In these two cases, the problem might not be identifiable from the Java code only.